RetailOps

RetailOps (retail operations) is the discipline of running stores and their sales channels day to day so that the product a customer wants is on the shelf or ready for pickup, at the right price, with enough trained people on the floor, at a cost the business can sustain. Its raw material is the store as an operating unit: deliveries, backroom, shelves, tills, people, pickup orders and returns, and the records that are supposed to describe all of them.

It sounds simple and is not. Thousands of items pass through hands-on processes, largely run by part-time staff, that update the records ordering, pricing and online availability rely on. When record and shelf disagree, the store orders the wrong thing, promises stock it does not have and loses sales nobody sees.

Written for beginners, store and area managers, retail operations and merchandising teams, analysts and engineers who build store systems, and leaders who set labour budgets and omnichannel promises. Sources were last verified on 2026-10-23.

“Retail operations” is a recognised field with stable roles and definitions. England’s government-approved Level 4 apprenticeship standard for a Retail manager (ST0325, approved in 2016, version 1.2 from 2023) lists what the job covers: sales targets and customer experience, team leadership, financial performance across the retail calendar, merchandising, stock control that minimises damage and loss, technology, and legal duties such as age-restricted sales and weights and measures.^[1] Operations-management research has studied store execution for more than two decades,^[2][3] and industry bodies publish identification and data standards for stores (GS1, and the ARTS standards now managed by the Object Management Group).^[4][5]

The one-word “RetailOps” is not a recognised discipline name. It is also a product brand: in June 2023 Flowspace announced it had acquired RetailOps, which it described as a San Diego-based software company for omnichannel brands’ supply chain operations.^[6] This page is about the practice, not that product.

• Not supply chain planning. Forecasting, safety stock and network inventory are on SupplyChainOps. RetailOps owns whether the stock that arrived is recorded correctly, reaches the shelf and stays findable.
• Not merchandising strategy. Choosing the assortment and the price is a merchandising and pricing decision. RetailOps executes the planogram and the price change, and reports when they cannot be executed.
• Not loss prevention alone. Theft matters, but much shrink is process error: miscounts, unrecorded damage, scanning mistakes. A store that treats every variance as theft will not fix its receiving process.
• Not e-commerce. The website and app are run on WebOps. RetailOps owns the store side of an online order: picking, staging, handover and the inventory promise behind it.
• Not only physical stores. The same disciplines apply to a dark store, a pickup locker bank or a concession inside another retailer.

Retailers have invested heavily in planning systems, yet the best-documented failures are failures of execution. Raman, DeHoratius and Ton described two of them in 2001: inventory records that do not match what is in the store, and products that are in the store but cannot be found. At one leading retailer, 65% of inventory records were inaccurate; at another, misplaced products kept one in six customers who asked for help from finding what they wanted. They estimated that such problems “reduce profits by more than 10%”, and found large differences between stores of the same chain running identical systems.^[2]

Availability research tells the same story from the customer’s side. Gruen and Corsten’s industry-funded guide put the average out-of-stock rate for fast-moving consumer goods at 8.3% and, summarising their 2002 worldwide study, attributed about 75% of out-of-stocks to retail store practices rather than upstream supply.^[7] When the item is missing, many shoppers do not wait: in that study 31% bought the item at another store and 9% did not buy it at all.^[7]

The table below is a composite of common failure patterns, not a report about one company.

Four changes shaped the modern discipline. The milestones are documented; the thread linking them is this Atlas’s reading.

1. The scanned barcode (1974). The first product scanned at a checkout was a 10-pack of Wrigley’s Juicy Fruit gum, on 26 June 1974, in a Marsh supermarket in Troy, Ohio.^[8][9] Scanning made item-level sales data cheap, and that data later fed perpetual inventory and automatic ordering.
2. Perpetual inventory and automatic ordering. Once every sale decremented a running count, stores could reorder automatically, and a wrong count began to drive the order.
3. The execution research of the 2000s. Studies showed how often store inventory records were wrong,^[3] and FMCG out-of-stock studies traced most out-of-stocks to retail store practices rather than upstream supply.^[7]
4. RFID and omnichannel. GS1’s EPC “Gen2” air interface for passive UHF tags was first published by EPCglobal in 2004, with Gen2v2 in 2013 and a Gen2v3 update since.^[10] As stores began fulfilling online orders, the inventory record became a customer promise: Target, for example, reports that its stores fulfil the majority of its digitally originated sales (see Use cases).

The next change is already scheduled: GS1 US describes Sunrise 2027 as a transition from 1D UPC barcodes to 2D barcodes such as QR codes, asking retailers to make sure their point-of-sale scanners can read them and extract the product number (GTIN).^[11]

Mental model: four flows that must agree. A store is the meeting point of four flows: goods (deliveries, shelves, returns, losses), information (item master, prices, PI, orders, promises made online), people (hours, skills, tasks) and money (sales, payments, margin). Most RetailOps failures are a disagreement between two flows: goods and information disagree (phantom stock), people and goods disagree (cases not worked to the shelf), information and money disagree (shelf price differs from the till). The job is to detect those disagreements early and fix the process that created them, not just the number.

flowchart TB
  PR["ProcurementOps: buying"] -->|items, terms| SC["SupplyChainOps: network, DC stock"]
  SC -->|deliveries| RO
  WO["WebOps: site and app"] -->|online orders| RO
  FT["FinTechOps: payments"] -->|card acceptance| RO
  PE["PeopleOps: staff and pay"] -->|people, policy| RO
  RO["RetailOps: the store as an operating unit"]
  RO -->|experience| CX["CXOps: journey design"]
  RO -->|store data| AN["AnalyticsOps: metrics"]
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
  class RO core
  class SC,PR,CX,WO,AN,FT,PE neutral

The following charter is this Atlas’s proposal; no standards body publishes a RetailOps charter.

Mission. Make every store a place where the promised product is available at the promised price, served by enough trained people, with records the rest of the business can trust.

Principles.

1. The shelf is the truth; the record is a claim. Treat perpetual inventory as an estimate to be tested, not a fact. Design processes that test it where it matters most.
2. Fix the process, not the number. Correcting a count without finding why it drifted guarantees the next variance.
3. Store first, then channel. Do not promise online what the store cannot reliably find on the shelf.
4. Labour is a lever, not only a cost. Model hours from traffic and tasks by store and hour; protect the hours that sell.
5. Standards are few, written and measured. A store can execute ten standards well, not a hundred.
6. Measure with explicit denominators. Every rate states what is counted, over what, and when.
7. Close the loop with the stores. Headquarters requests are capacity: every task sent to stores carries a time estimate and an owner.

Invariants (what must stay true). Every sale, receipt, transfer, return and write-off updates the record once and only once. Every price shown to a customer matches the price charged, or the customer is protected. No customer is promised a pickup the store cannot fill without the promise being measured.

A store’s operating system has seven building blocks. Each can be strong or weak independently, which is why the same software performs differently in different stores.

Titles vary; the table shows a common pattern, not a standard structure. Large stores often add an inventory or stock controller (counts, adjustments, backroom), and store systems and analytics teams own POS, PI, workforce tools and the scorecard. R = responsible, A = accountable, C = consulted, I = informed.

Two lifecycles overlap. A store has a life: site selection, build and opening, a ramp-up of several months, steady state, remodels and resets, and eventually relocation or closure. Inside each year runs the retail calendar: seasonal plans, sets and resets, peaks (in many markets the year-end holidays), markdowns and clearance, then the physical inventory count that closes the books.

flowchart TB
  A["Site and format decision"] --> B["Build, fit-out and systems install"]
  B --> C["Pre-opening: hire, train, stock, test tills"]
  C --> D["Opening and ramp-up"]
  D --> E["Steady state"]
  E --> F["Season plan and floor set"]
  F --> G["Sell, replenish, count"]
  G --> H["Peak trading"]
  H --> I["Markdown and clearance"]
  I --> J["Physical inventory and review"]
  J --> F
  E --> K["Remodel or relocation"]
  K --> E
  E --> L["Closure: sell-down, transfer, decommission"]
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  class E,F,G,H,I,J core
  class A,K decision
  class L risk

Each stage has its own risk. Pre-opening is the cheapest time to fix item and price errors: scan-test every fixture. Ramp-up stores lack sales history, so ordering and labour need manual parameters. Resets move thousands of items and create location and capacity errors (see the runbook). Closures concentrate shrink risk in transfers and write-offs.

Store operations works on a fixed rhythm. The cadences below are a common pattern; adapt them to format and size.

Controls that keep the model honest. Head-office tasks carry a time estimate and a weekly cap, with completion evidence that audits sample. Large inventory adjustments need a second person. Price changes are audited by sample, using the same logic weights-and-measures inspectors use (see price accuracy). Escalation is explicit: a process defect that recurs in three stores becomes a head-office problem, not a store’s.

The architecture below is a logical map, not a product recommendation; real retailers merge some boxes and split others. What matters is which system is the source of truth for each fact, and where physical work updates it.

flowchart TB
  IM["Item and price master"] -->|items, prices| POS["POS and self-checkout"]
  IM -->|case packs| PI
  SP["Space planning"] -->|shelf capacity| PI
  POS -->|sales, returns| PI["Perpetual inventory by location"]
  HH["Handhelds"] -->|scans| PI
  PI -->|on hand by location| OMS["Order management"]
  OMS -->|pick tasks| HH
  WFM["Workforce and tasks"] -->|tasks| HH
  PI -->|store orders| SC["Replenishment"]
  PI -->|sales, variances| DW["Data platform, scorecard"]
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef neutral fill:#f1f4f6,stroke:#5b7a87,color:#122029
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  class PI risk
  class POS,WFM,HH core
  class IM,SP,OMS,SC,DW neutral

Three design decisions matter more than vendor choice:

1. Inventory by location, not by store. A store that records only “units in store” cannot separate store OOS from shelf OOS. Record at least shelf, backroom and pickup staging.
2. One writer per fact. Prices should be changed in one system and pushed everywhere; inventory adjustments should be made through one audited path. Every “quick fix” path (a manager override screen, a spreadsheet upload) becomes a source of untraceable variance.
3. Available-to-promise is a policy, not a copy. What the website shows should be PI minus a buffer that depends on how accurate that item’s record is, minus stock already promised. Lab 4 shows the trade-off.

Standards cover parts of this map: the ARTS Operational Data Model (133 subject areas, now maintained by the Object Management Group) and OMG’s UnifiedPOS interfaces to scanners, printers and scales.^[13][5] Use them as a checklist even if you buy rather than build.

Online orders collected in store are the clearest example of RetailOps in an omnichannel world, because every step crosses a boundary between record and reality.

sequenceDiagram
  autonumber
  participant C as Customer
  participant O as Order system
  participant A as Associate
  participant P as Inventory record
  C->>O: Places pickup order
  Note over O: ATP = on hand - buffer - reserved
  O-->>C: Confirmed if ATP is 1 or more
  O->>A: Pick task, due time
  A->>P: Look up locations
  P-->>A: Shelf, backroom, staging
  alt Found
    A->>P: Scan item, stage it
    A->>O: Order ready
    O-->>C: Ready message
    C->>O: Arrives, checks in
    O->>A: Customer waiting
    Note over A: Hands over at counter
    A->>O: Handover scanned
  else Not found
    A->>P: Record zero, count location
    A->>O: Short pick
    O-->>C: Substitute or refund
  end

The exception path is where RetailOps earns its keep. A “not found” is direct evidence of phantom inventory. A well-run process counts or zeroes the record at once, so the next customer is not promised the same missing unit and replenishment resumes; a poor one cancels the line and leaves the record unchanged.

The promise itself changes behaviour. After one retailer launched buy-online-pick-up-in-store, Gallino and Moreno found that online sales fell while store sales and traffic rose, which they attribute to pickup customers buying more in the store and to shoppers who researched online and bought in the store.^[14] Reliable availability shown online moves demand into the store, so the store has to be ready for it.

This part is the centre of the page: most of the decisions that make or break a store depend on whether its records describe reality.

Every movement of goods should update the record exactly once. In practice, errors enter at many points. Gruen and Corsten list, among others: an item scanned at the till as a similar item (one record too low, another too high), unrecorded damage or theft, store staff able to change on-hand figures, incorrect audits, product lost in the backroom, mislabelled cases from the distribution centre and poor master data for promotional items.^[7] In DeHoratius and Raman’s study of nearly 370,000 records from 37 stores of one retailer, 65% of records were inaccurate. Far more of the variation lay between product categories (26.4%) than between stores (2.7%), which leaves most of it at the level of individual items. Inventory auditing practices reduced inaccuracy, while complex store environments and the distribution structure increased it.^[3] That is one reason to target counts at items rather than run store-wide counting campaigns.

The dangerous error is phantom inventory, because it switches off its own detection: the record says there is stock, so the automatic order does not fire, the shelf stays empty, nothing sells, and nothing in the sales data looks wrong.

flowchart TB
  A["Unrecorded loss or mis-scan"] --> B["Record shows 4, shelf has 0"]
  B --> C["Order logic sees enough stock"]
  C --> D["No replenishment ordered"]
  D --> E["Shelf stays empty"]
  E --> F["No sales recorded"]
  F --> G["Record never decreases"]
  G --> B
  E --> H["Detect: no sale for an unusually long time"]
  H --> I["Targeted count corrects record"]
  I --> J["Order fires, shelf refilled"]
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  class A,B,C,D,E,F,G risk
  class H decision
  class I,J core

Gruen and Corsten found the effect in audit data: for one US retailer, items whose record matched the physical count had an out-of-stock rate of 4.1%, against 8.9% for items whose record did not, about 2.2 times higher.^[7]

Inventory record accuracy is measured by counting a sample of records and comparing each count with the record at the same moment (after freezing or adjusting for sales during the count).

• Exact-match IRA = records where counted = recorded ÷ records counted.
• Tolerance IRA = records within a tolerance (for example ±1 unit, or ±5% for high-volume items) ÷ records counted.
• Absolute variance at cost = Σ |counted − recorded| × unit cost. Net variance = Σ (counted − recorded) × unit cost.

Report exact-match and absolute figures. Net variance flatters a store: phantom and hidden errors cancel in money, yet phantom stock stops replenishment and hidden stock ties up space and cash. The audits Gruen and Corsten report show how far reality can be from assumptions: exact-match accuracy of 32% to 45% across four studies, and, in one audit of 166 items in 121 stores, 45.4% exact, 18.8% off by one unit and 25.8% off by three or more.^[7] Those were individual retailers in the 2000s; measure your own.

Where to count. Counting everything continuously is too expensive, so count where errors are likely and costly: items with no sales for an improbably long time given their usual rate (Lab 2 computes this), items with a recent “not found” at pick, high-value or high-theft items, items after a planogram change, and items with frequent manual adjustments. Random counts are still needed to estimate accuracy honestly, because targeted counts are biased towards errors.

Gruen and Corsten distinguish three out-of-stock types from a retailer’s perspective: distribution centre, store (the store has no inventory, from ordering, forecasting or supply mistakes) and shelf (inventory is in the store but not on the shelf, usually from store processes such as shelf space, restocking frequency and monitoring).^[7] Different people fix them: store OOS through ordering and record accuracy, shelf OOS through space, replenishment labour and the backroom.

There are three ways to measure availability, and each measures something different:^[7]

A practical programme combines them: POS-based alerts for fast movers, a daily walk for the planogram’s critical items, and counts triggered by both. The fast movers deserve most of the attention: in Gruen and Corsten’s data, high-demand items had almost six times the out-of-stock lost sales of low-demand items.^[7]

Shelf capacity and delivery frequency. A frequent cause of shelf OOS is a shelf too small for a fast mover’s demand between deliveries, combined with a case pack larger than the space left. Gruen and Corsten found that most shelf space was allocated by case pack rather than demand, and recommended demand-based planograms and matching delivery schedules to shelf demand instead of holding backstock, which they found positively related to out-of-stocks.^[7] They also report that in one study, better shelf discipline (no “covering holes” with neighbouring products, no hidden product, accurate shelf tags) reduced out-of-stocks by about 40%, and that a 10% change in planogram compliance went with a 1% change in out-of-stock level.^[7] Treat those as one programme’s results, not a law.

“Shrink” usually means the difference between the inventory the books say you should have and what a physical count finds, at cost or at retail. It is not a standardised measure. A study for the Retail Industry Leaders Association by Adrian Beck of the University of Leicester, released in 2016, found no consensus on how to define and measure retail losses and proposed a broader concept of total retail loss with a typology of retail costs and retail losses.^[15] An inventory-services firm’s summary of the ECR total-retail-loss research separates the normal costs of retailing from losses, and notes that shrinkage has no universally agreed definition and that its root causes are typically unknown.^[16]

Published averages are survey-based. The US National Retail Federation’s 2023 National Retail Security Survey reported an average shrink rate of 1.6% for fiscal 2022 (up from 1.4%), from 177 retail brands answering through senior loss-prevention executives, with internal and external theft accounting for 65% of shrink; it also noted that shrink varies significantly by sector.^[17] Treat such figures with care: Retail Dive reported in January 2024 that NRF had withdrawn a widely repeated estimate about organised retail crime from one of its reports, and that NRF acknowledged the difficulty of gathering agreed data.^[18]

What this means for operations:

• Classify before you act. Split known losses (recorded damage, spoilage, return fraud, cash variances) from unknown losses (the residual at count), which mix theft and process error in unknown proportions.
• Compare like with like. Same basis, denominator, markdown treatment and period (the worked calculation shows how far they move the figure).
• Separate stock loss from record error. Some “shrink” is phantom stock created by mis-scans; fixing the scan process reduces reported loss without catching anyone.
• Measure new technology’s effect. Self-checkout, scan-and-go and pickup lockers change both theft and honest error; compare matched stores before and after rather than relying on vendor or advocacy figures.

A price that differs between shelf and till costs money either way: overcharges create legal and reputational risk, and undercharges leak margin. In the United States, many weights-and-measures authorities use the Examination Procedure for Price Verification in NIST Handbook 130, developed from 1993 and adopted by the National Conference on Weights and Measures in 1995, which applies to all retail stores. An inspector samples items and compares the charged price with the lowest advertised, posted or marked price. A store passes a single inspection at 98% accuracy or better: in a 100-item sample, at most two errors. Both overcharges and undercharges count as errors for lower-level enforcement, but higher levels of enforcement, such as fines or penalties, rest on overcharges alone. A ratio of overcharges to undercharges of 2 to 1 or 3 to 1 may indicate systematic problems, and the handbook applies that ratio once at least 10 errors have been found, over several inspections or in one large sample.^[19] Each state decides whether and how to adopt the procedure.

In the European Union, announced price reductions are regulated: in September 2024 the Court of Justice held, in a case about a discounter’s weekly brochures, that a reduction announced as a percentage or as a promotional statement must be calculated from the lowest price the trader applied in at least the 30 days before the reduction.^[20] The directive lets member states set different rules for goods liable to deteriorate or expire rapidly (most perishables), a shorter period for products on the market for less than 30 days, and a different reference for progressively increasing reductions,^[21][22] so check the national transposition. For store operations that means the price history behind each shelf-edge “was/now” label must be retained and checked, not only the current price.

Operationally, price integrity rests on four controls: changes made in one system and pushed to tills and labels; labels changed on the effective day, with evidence; a weekly sample audit using the inspectors’ arithmetic; and a till rule that protects the customer when shelf and till disagree.

Receiving. Phantom and hidden stock are often born at the back door: a case recorded but not delivered, or delivered but never received. Compare delivery documents with what is unloaded for a sample every day, and treat suppliers’ shipment notices as claims to verify, with stricter checks for direct-store-delivery vendors, whose goods bypass the distribution centre’s checks.

Cycle counting. A daily targeted list (Artefact 2) fixes errors; a weekly random sample estimates accuracy. Reason codes make patterns visible: negative adjustments after deliveries point to receiving; after promotions, to mis-scans.

Backroom to shelf. The backroom should hold only what does not fit on the shelf, organised by location so that it can be found. A backroom full of partial cases is a sign of a planogram that is too small for the case pack, or of deliveries that are too large or too frequent for the shelf (see shelf capacity).

Returns. Returns are a large flow that stores must process: in a survey of 249 professionals at large US retailers (revenue above $500 million), released in December 2024, retailers estimated that 16.9% of their 2024 sales would be returned.^[23] Each return creates a record decision (sellable, damaged, return to vendor, fraud review), and each wrong decision creates a record error or a loss.

Labour is the largest cost a store manager controls: the Stable Scheduling Study cites an estimate that it accounts for 85% of controllable costs in retail stores.^[24] That makes it the first lever pulled when a quarter looks weak.

• Labour drives execution, and execution drives profit. In a large retailer’s stores, Ton found that more labour went with higher profitability through conformance quality (processes done correctly), not service quality, and warned that a corporate focus on payroll can push managers to understaff.^[25]
• One ratio does not fit all stores. Fisher, Gallino and Netessine estimated each store’s revenue response to labour from random gaps between planned and actual staffing. Applied in 168 stores for six months, the method raised revenue by 4.5% and profit by nearly $7.4 million a year; stores with high potential demand, nearby competitors and experienced managers gained most.^[26]
• Stability is not the enemy of productivity. In an experiment in 28 Gap stores (19 treatment, 9 control; stores were randomly assigned, except three pretest stores that stayed in treatment), a bundle of five practices raised median sales by 7% and labour productivity by 5%. The bundle included extra staffing hours, funded outside the store budget, in 13 of the 19 treatment stores; the authors attribute the gain to stable scheduling. Only 30% of the variability in weekly payroll hours was explained by changes in traffic, so most instability was not forced by customers.^[24]

These are single-chain studies, and none tested a cut. They do not prove every store is understaffed; they show that labour’s revenue effect is real and differs between stores, so budgets should be tested, not cut by a flat percentage.

Building a labour model. A defensible model has three layers:

1. Fixed hours: opening, closing, cash, minimum safe staffing.
2. Variable selling hours: driven by forecast traffic or transactions by hour (Lab 3 uses visitors per associate).
3. Task hours: driven by workload, with engineered or measured time standards (cases received, labels changed, pickup orders picked, returns processed).

The model sets the budget; the schedule assigns people. Schedules should then be published early and changed rarely, both for the reasons above and because several jurisdictions require it. As of October 2026, New York City’s Fair Workweek law requires retail employers to give workers their schedules 72 hours before the first shift, bans on-call shifts, and bars cancelling a shift with less than 72 hours’ notice;^[27] Oregon requires large retail, hospitality and food-service employers to post schedules at least 14 calendar days in advance and to pay extra for many changes made without that notice.^[28] Rules differ by city, state and country, and thresholds and exemptions matter; check the rule that applies to each store with counsel.

When stores fulfil online orders, they take on warehouse work in a building designed for shoppers. Target is a documented example of stores used as fulfilment hubs (see Use cases).

The choice between them is a decision about where the stock and the labour already are; the decision tree in Deciding and adopting helps.

Mandatory rules and voluntary standards are mixed in retail; know which is which.

Categories first; brand names change faster than jobs to be done. The selection criteria are what last.

Automation helps most where the store repeats the same judgement thousands of times: ordering, counting priorities, scheduling, gap detection. It fails where it acts on a record the store has not verified.

• Automatic ordering beats manual overrides on average. Gruen and Corsten report that store staff who adjusted computer-suggested order quantities did worse than even imperfect computer forecasts.^[7] Measure overrides; do not ban them blindly, because local knowledge (a local event, a broken freezer) matters.
• RFID speeds up counting for tagged items: GS1 notes that RAIN RFID tags can be read at very high rates and at distances well over 10 metres without line of sight, which can increase inventory accuracy.^[29] Run your own pilot with a control group before a chain-wide business case.
• Machine learning and computer vision can rank items to count, detect empty facings and forecast traffic. They need ground truth (counts, audits) to be trained and checked, and inherit every bias in the records they learn from.
• Generative AI assistants can answer “how do I” questions from the written standards; keep them away from prices and inventory adjustments without human confirmation.

Human approval should remain for large inventory adjustments, price overrides, schedule changes inside the legal notice window, and anything that accuses a person of theft.

The artefacts below are for a fictional mid-size chain, “ExampleMart” (120 stores, general merchandise and grocery, pickup in every store). They are this Atlas’s templates, meant to be copied and adapted; numbers are illustrative.

A store can execute a short list well. ExampleMart’s ten, each measured on the scorecard (Template 1):

1. Every delivery received and recorded the same day.
2. Availability walk of critical items before opening.
3. Targeted count list completed daily.
4. Every “not found” at pick counted within two hours.
5. Price changes worked on the effective date.
6. Planogram resets done by the due date, with photo evidence and updated locations.
7. Backroom organised by location; no unlocated cases.
8. Pickup orders ready by the promised time.
9. Schedule published by the policy date; changes logged with reason.
10. Payment terminals inspected on schedule; device list current.

Example status: operating template, not executed.

SOP-INV-03  Targeted cycle counts                         Version 1.2
Purpose     Correct the inventory records most likely to be wrong.
Scope       All sales-floor and backroom locations. Excludes pharmacy.
Owner       Stock controller (R); store manager (A).
Trigger     Daily exception list at 06:00 from the inventory system:
            - silent items (P(no sale) < 1% given usual sales rate)
            - every "not found" at pick in the last 24 hours
            - items reset in the last 7 days
            - high-value items on the weekly rotation
Steps       1. Print or open the list on a handheld; count before 10:00.
            2. Count shelf, backroom location and pickup staging.
            3. Enter the count; the system freezes sales during entry.
            4. If |counted - record| > 5 units or > $200 at cost,
               a second person recounts before posting.
            5. Choose a reason code for every adjustment.
            6. Fill the shelf from any hidden stock found.
Acceptance  100% of the list counted by 14:00; recounts documented.
Rollback    Adjustments posted in error are reversed with code R99
            and a note; never by editing the count.
Records     Count files kept 2 years; weekly summary to area manager.

Example status: operating template, not executed.

OPENING HUDDLE (10 min)                     Store 042   Date ________
1. Yesterday: sales vs plan ____  conversion ____  pickups ____
2. Pickup failures yesterday ____  all counted?  Y / N
3. Today's deliveries: time ____  cases ____  receiving owner ____
4. Gaps from the availability walk: top 5 items and owners
5. Head-office tasks due today (with time estimate): ____ hours
6. Labour: scheduled hours ____  vs model ____  gaps at ____
7. One safety or customer note

Head office competes for store hours. ExampleMart requires every task sent to stores to arrive through this form, and the retail operations team rejects requests without a time estimate or with a due date inside five working days. The form is YAML so that the task tool can validate it.

Example status: syntax-checked (YAML), not executed.

task_request:
  id: TR-2026-0412
  title: "Move seasonal candles to front table, bays 1-2"
  requester: "Merchandising, home category"
  business_reason: "Q4 seasonal plan; planogram POG-HOME-0412 attached"
  stores: "all formats A and B (94 stores)"
  due_date: "2026-11-09"
  time_estimate_minutes_per_store: 45
  skill_required: "visual merchandising"
  evidence_required: "photo of both bays after set"
  success_measure: "sell-through of candle line vs plan at week 4"
  affects_pickup_inventory: true   # locations change: counts needed
  approved_by_retail_ops: null     # filled in by retail operations

Which items can be promised for pickup, and with what buffer, should be a written policy that the order system applies. This example sets a buffer by record-accuracy class (from count history) and by sales rate.

Example status: syntax-checked (YAML), not executed.

pickup_promise_policy:
  version: 3
  owner: "Retail operations (A), e-commerce product (C)"
  default_buffer_units: 1
  accuracy_classes:            # from the last 90 days of counts
    A: {exact_match_min: 0.90, buffer_units: 0}
    B: {exact_match_min: 0.70, buffer_units: 1}
    C: {exact_match_min: 0.00, buffer_units: 2}
  fast_mover_extra_buffer:     # high rate means the shelf changes quickly
    daily_units_above: 20
    extra_units: 1
  never_promise:
    - "items with a not-found at pick in the last 7 days and no count"
    - "items counted zero in the last 24 hours"
  review: "monthly, using pick-failure rate and promised-but-filled rate"

Four labs on synthetic data: Python 3.8 or later and a shell, standard library only, no accounts and no cost. Each lab was run on 2026-10-23 exactly as printed (Python 3.8.10, Ubuntu Linux); the expected outputs are copied from those runs.

Objective. Compute the core store KPIs from daily totals and see why denominators matter. Prerequisites. Python 3.8+. Time. 20 minutes. Risk. None.

1. Create a folder and the data file.

Example status: verified by execution on 2026-10-23 (bash, Linux).

mkdir -p ~/retailops-labs/lab1 && cd ~/retailops-labs/lab1
cat > week.csv <<'CSV'
date,traffic,transactions,units,net_sales,cogs,labour_hours
2026-09-07,1180,342,861,21540.00,12710.00,182
2026-09-08,1095,318,790,19870.00,11720.00,176
2026-09-09,1120,331,805,20410.00,12040.00,178
2026-09-10,1210,350,884,22300.00,13160.00,184
2026-09-11,1650,446,1172,29180.00,17220.00,214
2026-09-12,2240,571,1559,38920.00,22960.00,248
2026-09-13,1890,494,1301,32470.00,19160.00,226
CSV

2. Save the script as scorecard.py.

Example status: verified by execution on 2026-10-23 (Python 3.8.10).

"""Weekly store scorecard from daily totals (standard library only)."""
import csv

SELLING_SQFT = 12000            # sales floor only
GROSS_SQFT = 15000              # including stockroom, fitting rooms, office
AVG_INVENTORY_AT_COST = 410000  # average of 13 month-end balances, last 12 months
TRAILING_GROSS_MARGIN = 1012000 # gross margin dollars, same 12 months
SEASON_RECEIVED = 2400          # units of the autumn jacket line received
SEASON_SOLD = 1530              # units sold since the line was set

with open("week.csv", newline="") as f:
    days = list(csv.DictReader(f))

traffic = sum(int(d["traffic"]) for d in days)
txns = sum(int(d["transactions"]) for d in days)
units = sum(int(d["units"]) for d in days)
sales = sum(float(d["net_sales"]) for d in days)
cogs = sum(float(d["cogs"]) for d in days)
hours = sum(float(d["labour_hours"]) for d in days)

print(f"Week: {days[0]['date']} to {days[-1]['date']} ({len(days)} days)")
print(f"Net sales           {sales:12,.2f}")
print(f"Conversion          {100 * txns / traffic:12.1f} %  ({txns} / {traffic})")
print(f"Avg transaction     {sales / txns:12.2f}")
print(f"Units per txn       {units / txns:12.2f}")
print(f"Gross margin rate   {100 * (sales - cogs) / sales:12.1f} %")
print(f"Sales / labour hr   {sales / hours:12.2f}")
print(f"Sales / sq ft (wk)  {sales / SELLING_SQFT:12.2f}  selling area")
print(f"Sales / sq ft (wk)  {sales / GROSS_SQFT:12.2f}  gross area")
print(f"GMROI (12 months)   {TRAILING_GROSS_MARGIN / AVG_INVENTORY_AT_COST:12.2f}")
print(f"Sell-through        {100 * SEASON_SOLD / SEASON_RECEIVED:12.1f} %  jacket line")
best = max(days, key=lambda d: int(d["transactions"]) / int(d["traffic"]))
worst = min(days, key=lambda d: int(d["transactions"]) / int(d["traffic"]))
for label, d in (("Best conversion ", best), ("Worst conversion", worst)):
    rate = 100 * int(d["transactions"]) / int(d["traffic"])
    per_hr = int(d["traffic"]) / float(d["labour_hours"])
    print(f"{label}    {d['date']}  {rate:.1f} %  visitors/labour hr {per_hr:.1f}")

3. Run python3 scorecard.py.

Expected output.

Week: 2026-09-07 to 2026-09-13 (7 days)
Net sales             184,690.00
Conversion                  27.5 %  (2852 / 10385)
Avg transaction            64.76
Units per txn               2.58
Gross margin rate           41.0 %
Sales / labour hr         131.17
Sales / sq ft (wk)         15.39  selling area
Sales / sq ft (wk)         12.31  gross area
GMROI (12 months)           2.47
Sell-through                63.8 %  jacket line
Best conversion     2026-09-09  29.6 %  visitors/labour hr 6.3
Worst conversion    2026-09-12  25.5 %  visitors/labour hr 9.0

Validation. Check two numbers by hand: conversion 2,852 ÷ 10,385 = 27.5%; GMROI 1,012,000 ÷ 410,000 = 2.47. What to notice. The busiest day converted worst while each labour hour faced the most visitors: a hypothesis for the labour model to test, not proof. Sales per square foot differs by 25% depending on which area you divide by, so state the area every time. Troubleshooting. KeyError means the CSV header was changed; ZeroDivisionError means a day with zero traffic. Teardown. rm -r ~/retailops-labs/lab1.

Objective. Compute exact and tolerance IRA from a cycle count, see why net variance misleads, and rank uncounted items by how surprising their silence is. Prerequisites. Lab 1 setup. Time. 30 minutes. Risk. None.

1. Create the count results and the list of uncounted items.

Example status: verified by execution on 2026-10-23 (bash, Linux).

mkdir -p ~/retailops-labs/lab2 && cd ~/retailops-labs/lab2
cat > counts.csv <<'CSV'
sku,system_oh,counted_oh,unit_cost
100231,12,12,3.10
100232,6,0,4.25
100233,24,23,1.80
100234,0,4,6.40
100235,8,8,12.00
100236,15,9,2.20
100237,3,3,25.00
100238,40,46,0.95
100239,5,2,8.75
100240,9,9,5.50
100241,2,0,31.00
100242,18,18,2.60
CSV
cat > on_hand.csv <<'CSV'
sku,system_oh,avg_daily_units,days_since_last_sale
200101,7,2.10,4
200102,3,0.05,30
200103,11,0.90,9
200104,5,1.60,1
200105,2,0.30,12
200106,14,3.40,2
200107,6,0.70,3
CSV

2. Save the script as ira.py.

Example status: verified by execution on 2026-10-23 (Python 3.8.10).

"""Inventory record accuracy from a cycle count, plus phantom-stock suspects."""
import csv
import math

with open("counts.csv", newline="") as f:
    rows = list(csv.DictReader(f))

n = len(rows)
exact = within_one = phantom = hidden = 0
net_value = abs_value = 0.0
for r in rows:
    diff = int(r["counted_oh"]) - int(r["system_oh"])   # + means more on the shelf
    exact += diff == 0
    within_one += abs(diff) <= 1
    phantom += diff < 0
    hidden += diff > 0
    net_value += diff * float(r["unit_cost"])
    abs_value += abs(diff) * float(r["unit_cost"])

print(f"Records counted            {n}")
print(f"Exact-match accuracy       {100 * exact / n:.1f} %")
print(f"Within +/-1 unit           {100 * within_one / n:.1f} %")
print(f"Phantom (system > shelf)   {phantom}")
print(f"Hidden  (shelf > system)   {hidden}")
print(f"Net variance at cost       {net_value:9.2f}")
print(f"Absolute variance at cost  {abs_value:9.2f}")

# Items not yet counted: how surprising is the run of days without a sale?
ALERT = 0.01
print("\nCount next (P(no sale) below 1 %):")
with open("on_hand.csv", newline="") as f:
    for r in csv.DictReader(f):
        oh = int(r["system_oh"])
        rate = float(r["avg_daily_units"])
        days = int(r["days_since_last_sale"])
        p_zero = math.exp(-rate * days)    # Poisson chance of zero sales
        if oh > 0 and p_zero < ALERT:
            print(f"  {r['sku']}  on hand {oh:>2}  {days:>2} days silent  P={p_zero:.4f}")

3. Run python3 ira.py.

Expected output.

Records counted            12
Exact-match accuracy       41.7 %
Within +/-1 unit           50.0 %
Phantom (system > shelf)   5
Hidden  (shelf > system)   2
Net variance at cost          -97.45
Absolute variance at cost     160.05

Count next (P(no sale) below 1 %):
  200101  on hand  7   4 days silent  P=0.0002
  200103  on hand 11   9 days silent  P=0.0003
  200106  on hand 14   2 days silent  P=0.0011

Validation. 5 of 12 records match exactly (41.7%). Item 200106 normally sells 3.4 a day, so two silent days have a probability of e^(−6.8) ≈ 0.0011 if it were really on the shelf: count it. Item 200102 sells so slowly that 30 silent days are unremarkable (P ≈ 0.22). What to notice. The absolute variance ($160.05) is 64% larger than the net figure suggests, because $31.30 of hidden stock offsets $128.75 of phantom loss in the net figure. The Poisson model assumes independent sales at a steady rate; promotions, seasonality and items sold in multiples break it, so use it to rank counts, not to declare stock missing. Troubleshooting. No suspects printed: check that days_since_last_sale is in days, not weeks. Teardown. rm -r ~/retailops-labs/lab2.

Objective. Convert an hourly traffic and pickup forecast into required staff, compare it with a schedule, and flag changes made inside a notice window. Prerequisites. Python 3.8+. Time. 30 minutes. Risk. None; the notice rule is a parameter, not legal advice.

1. Create the forecast, the shifts and the change log.

Example status: verified by execution on 2026-10-23 (bash, Linux).

mkdir -p ~/retailops-labs/lab3 && cd ~/retailops-labs/lab3
cat > forecast.csv <<'CSV'
hour,visitors,pickup_orders
9,60,4
10,110,6
11,170,5
12,240,7
13,260,6
14,230,5
15,210,6
16,250,8
17,290,9
18,240,7
19,150,4
20,90,2
CSV
cat > shifts.csv <<'CSV'
associate,start,end
A,9,17
B,9,15
C,10,18
D,12,20
E,13,21
F,15,21
G,16,21
CSV
cat > changes.csv <<'CSV'
associate,shift_date,changed_on,change
B,2026-10-17,2026-10-01,extended by 2 hours
D,2026-10-17,2026-10-12,start moved 12:00 to 14:00
G,2026-10-17,2026-10-16,shift cancelled
CSV

2. Save the script as coverage.py.

Example status: verified by execution on 2026-10-23 (Python 3.8.10).

"""Hourly floor coverage versus need, and a schedule-change notice check."""
import csv
import math
from datetime import date

VISITORS_PER_ASSOCIATE = 60  # floor standard set by the retailer (assumption)
MINUTES_PER_PICKUP = 6       # pick, pack and stage one pickup order
MIN_STAFF = 2                # safety and opening rule
NOTICE_DAYS = 14             # set to the rule that applies where the store is

with open("forecast.csv", newline="") as f:
    hours = list(csv.DictReader(f))
with open("shifts.csv", newline="") as f:
    shifts = list(csv.DictReader(f))

print("hour need have gap")
short = over = 0
for h in hours:
    hr = int(h["hour"])
    floor = math.ceil(int(h["visitors"]) / VISITORS_PER_ASSOCIATE)
    picks = int(h["pickup_orders"]) * MINUTES_PER_PICKUP / 60
    need = max(MIN_STAFF, math.ceil(floor + picks))
    have = sum(int(s["start"]) <= hr < int(s["end"]) for s in shifts)
    gap = have - need
    short += -gap if gap < 0 else 0
    over += gap if gap > 0 else 0
    flag = "  SHORT" if gap < 0 else ("  over" if gap > 0 else "")
    print(f"{hr:>4} {need:>4} {have:>4} {gap:>+4}{flag}")
print(f"Understaffed associate-hours: {short}; overstaffed: {over}")

print(f"\nChanges made with less than {NOTICE_DAYS} days' notice:")
with open("changes.csv", newline="") as f:
    for c in csv.DictReader(f):
        notice = (date.fromisoformat(c["shift_date"])
                  - date.fromisoformat(c["changed_on"])).days
        if notice < NOTICE_DAYS:
            print(f"  {c['associate']}: {c['change']} (notice: {notice} d) -> review")

3. Run python3 coverage.py.

Expected output.

hour need have gap
   9    2    2   +0
  10    3    3   +0
  11    4    3   -1  SHORT
  12    5    4   -1  SHORT
  13    6    5   -1  SHORT
  14    5    5   +0
  15    5    5   +0
  16    6    6   +0
  17    6    5   -1  SHORT
  18    5    4   -1  SHORT
  19    4    4   +0
  20    3    3   +0
Understaffed associate-hours: 5; overstaffed: 0

Changes made with less than 14 days' notice:
  D: start moved 12:00 to 14:00 (notice: 5 d) -> review
  G: shift cancelled (notice: 1 d) -> review

Validation. At 13:00, 260 visitors need ⌈260 ÷ 60⌉ = 5 floor staff plus 6 orders × 6 minutes = 0.6 staff, so 6 in total; associates A to E are on, so the store is one short. What to notice. The gaps sit at the lunch and after-work peaks, and the two late changes (moving D later, cancelling G) would worsen the 12:00–13:00 and 17:00–18:00 gaps and open new ones at 16:00, 19:00 and 20:00: understaffed associate-hours would rise from 5 to 12. To see it, edit shifts.csv (D starts at 14, delete G) and re-run. The fix is to reshape shifts, not to add hours everywhere. Troubleshooting. Shifts ending at 21 cover the 20:00 hour because the comparison is start ≤ hour < end; an off-by-one here is the most common bug in coverage code. Teardown. rm -r ~/retailops-labs/lab3.

Objective. Simulate pickup promises made from inaccurate records and find the buffer that balances failed picks against promises not made. Prerequisites. Python 3.8+. Time. 30 minutes. Risk. None.

1. Create the folder with mkdir -p ~/retailops-labs/lab4 && cd ~/retailops-labs/lab4, then save the script as buffer.py.

Example status: verified by execution on 2026-10-23 (Python 3.8.10).

"""Pickup promises against inaccurate store records: how big a buffer?"""
import random

rng = random.Random(42)
SKUS = 2000
ORDER_PROB = 0.3   # chance a shown-available SKU receives a pickup order today

def true_on_hand(record):
    """Record error model (assumption): 60 % exact, otherwise skewed to phantom."""
    if rng.random() < 0.60:
        return record
    error = rng.choice([-3, -2, -2, -1, -1, -1, 1, 1, 2])
    return max(0, record + error)

items = []
for _ in range(SKUS):
    record = rng.choice([0, 1, 1, 2, 2, 3, 4, 5, 6, 8, 10, 12])
    items.append((record, true_on_hand(record)))
order_draws = [rng.random() for _ in range(SKUS)]   # same customers for every buffer

print("buffer shown orders failed fail% orders_lost_vs_0")
base_orders = None
for buffer in range(4):
    shown = orders = failed = 0
    for (record, actual), draw in zip(items, order_draws):
        if record - buffer >= 1:
            shown += 1
            if draw < ORDER_PROB:
                orders += 1
                failed += actual == 0
    base_orders = orders if base_orders is None else base_orders
    rate = 100 * failed / orders
    print(f"{buffer:>6} {shown:>5} {orders:>6} {failed:>6} {rate:>5.1f} "
          f"{base_orders - orders:>16}")

2. Run python3 buffer.py.

Expected output.

buffer shown orders failed fail% orders_lost_vs_0
     0  1860    552     40   7.2                0
     1  1530    447     14   3.1              105
     2  1206    349      2   0.6              203
     3  1040    303      0   0.0              249

Validation. The seed is fixed, so the output is identical on every run with the same Python random generator. With no buffer, 40 of 552 orders (7.2%) fail at the shelf; a one-unit buffer cuts failures to 14 but stops 105 promises. What to notice. A single chain-wide buffer is a blunt tool: most of the failures come from low-record items with phantom errors. Artefact 5’s per-class buffer applies a large buffer only where records are unreliable. “Orders lost” is an upper bound: some of those customers would buy for delivery or in the store. Troubleshooting. Different numbers usually mean the error list or the seed was edited. Teardown. rm -r ~/retailops-labs/lab4.

Two cases below are documented by public sources and labelled as such; the others are illustrative scenarios invented for teaching.

1. Stores as fulfilment hubs (sourced). Context: in its annual report for fiscal 2025 (the year ended 31 January 2026), Target reported that digitally originated sales were 20.6% of merchandise sales, that its stores fulfil the majority of them, and that two-thirds of digital sales were fulfilled through same-day options (Order Pickup, Drive Up and Same-Day Delivery). Its headline figure that stores fulfilled 97.6% of merchandise sales includes ordinary in-store purchases, so it says little about online orders on its own.^[31] Implications (this Atlas’s reading): store records become customer promises, pick labour is planned with selling labour, and the backroom must make room for staging. Success measures: on-time-ready rate, pick-failure rate, and store OSA not falling as online volume grows. Pitfall: treating fulfilment as an add-on task for selling staff during peaks.

2. Stable scheduling at a specialty apparel chain (sourced). Context: Gap Inc. and university researchers ran an experiment in 28 stores from November 2015 to August 2016 (25 randomly assigned, three pretest stores kept in treatment; see Labour), combining shift swapping by app, consistent shift times, core scheduling, a soft guarantee of 20 or more hours for a core group of part-time staff, and targeted additional staffing. Result reported: median sales up 7% and labour productivity up 5% in treatment stores; some managers struggled with instability that came from head office and from associates.^[24] Trade-off: the soft hour guarantee reduces the slack a manager can cut. Lesson: test schedule changes against controls.

3. Grocery availability programme (illustrative scenario). Context: a 60-store grocer’s complaints about empty shelves rise while distribution-centre fill rates are 98%. Method: a four-week audit of 300 critical items separates store OOS from shelf OOS; then a daily silent-item count list (Lab 2), demand-based space for fast movers and delivery days matched to shelf capacity. Success criteria: critical-item OSA from 93% to 97% and exact-match IRA up ten points in 12 weeks. Pitfall: stopping measurement after the project, so availability drifts back.

4. RFID pilot in apparel (illustrative scenario). Method: a fashion retailer tags two categories in eight stores with eight matched controls and compares IRA, size-run OSA, count labour and sales for 12 weeks. Success criteria, set in advance: for example, exact-match IRA ≥ 95% in pilot categories and payback under two years. Pitfall: comparing pilot stores with their own past rather than with controls.

Store metrics are easy to compute and easy to compare wrongly. Each definition below names its denominator; where retailers use different conventions, pick one, write it down and never mix them in one league table.

Leading and lagging. Sales, margin and shrink lag. Process measures lead: targeted counts completed, “not found” picks counted within two hours, price audit accuracy, schedules published on time, deliveries received the same day. When they slip, the lagging measures usually follow weeks later.

Worked calculation (illustrative store, one quarter).

• Shrink: book inventory at cost at quarter end $612,000; counted $598,500; net sales $2,450,000 at a 41% gross margin, so cost of sales is $1,445,500. Shrink at cost = 13,500. Keep numerator and denominator on the same basis: at cost, 13,500 ÷ 1,445,500 = 0.93%; at retail, the loss is 13,500 ÷ 0.59 ≈ 22,881, and 22,881 ÷ 2,450,000 = 0.93% too, because the margin is uniform. Dividing the loss at cost by sales at retail gives 0.55%, a mixed-basis ratio that understates the loss by about 40%. Real differences come from elsewhere. If the whole loss sat in a 55%-margin department, its retail value would be 13,500 ÷ 0.45 = 30,000, or 1.22% of sales at retail against 0.93% at cost. Against book inventory rather than sales, the same loss is 13,500 ÷ 612,000 = 2.2%. Markdowns not recorded in the books, and whether known losses are included, move the figure again. Say which basis, denominator and period you report.
• IRA: a random sample of 400 records finds 236 exact matches: 236 ÷ 400 = 59.0%. A 95% confidence interval by the normal approximation is 59.0% ± 1.96 × √(0.59 × 0.41 ÷ 400) ≈ ±4.8 points, so a later sample showing 62% is not yet evidence of improvement.
• OSA: an audit of 1,000 planned critical items finds 962 on the shelf: 96.2%; of the 38 gaps, 14 had stock in the backroom (shelf OOS) and 24 had none in the building (store OOS). The 14 point to replenishment labour and backroom discipline; the 24 point to ordering and records.
• Pick failures: 11,400 lines picked, 296 not found: 2.6%. Of the 296 locations counted afterwards, 241 counted zero (phantom stock confirmed) and 55 found stock elsewhere in the store (a location problem, not an inventory problem).

Target setting. Set targets from your own baseline and best stores, not from published survey averages. Improve the worst quartile first; chain averages hide it. Avoid targets that invite gaming, such as IRA on self-selected counts or sales per labour hour alone.

Store compliance is local. The table names what typically applies; check each store’s jurisdiction.

A documented case: the 2013 Target breach. According to the US Senate Commerce Committee staff report “A ‘Kill Chain’ Analysis of the 2013 Target Data Breach”, as summarised by a law firm in March 2014, attackers probably used credentials stolen from an HVAC contractor with remote access to a vendor-facing part of Target’s network, then installed malware on point-of-sale systems that captured card data; 70 to 110 million customer records were taken, shortly after Target had been certified PCI DSS compliant.^[35] Some details were unconfirmed. The lessons are about boundaries, not only compliance: vendor access paths, separating store support systems from payment systems, and an owner for alerts. Security operations in depth are on SecOps and endpoint hardening of tills on EndpointOps.

Cost drivers. The controllable costs are labour, shrink, inventory carrying cost and markdowns; rent and energy are largely fixed in the short run. GMROI rises with faster selling, less inventory or better margin, and each lever has a cost: thin inventory raises out-of-stocks; deep markdowns clear stock but cut margin.

Capacity. Plan three capacities: space (shelf, backroom, pickup staging), labour (by hour) and service points (tills, pickup counters, parking bays). Pickup demand often peaks with shopper traffic, so pick in quieter hours against promised windows.

Unit economics of a pickup order (template). Cost per order = pick minutes × loaded wage per minute + staging and handover minutes × wage + packaging + failed-pick handling (refunds, customer contact) + any substitution margin given away. Compare it with delivery from a distribution centre and with the extra in-store purchases pickup customers make, which Gallino and Moreno observed at one retailer.^[14] Measure it per store; small, busy stores and large, quiet stores differ.

Returns. Returns are a capacity and cost problem as much as a customer-service one. With large US retailers estimating that 16.9% of 2024 sales would be returned, and 93% of those surveyed calling fraud and other exploitative behaviour a significant issue,^[23] the store needs a fast path back to the shelf for sellable items and clear rules for the rest.

Sustainability. For food retailers, waste is material: the UN Environment Programme’s Food Waste Index Report 2024 estimated that 1.05 billion tonnes of food were wasted in 2022 across retail, food service and households, of which retail accounted for 131 million tonnes.^[36] Store levers: accurate ordering of perishables, markdowns before expiry, donation where legal, and recording waste by cause. In grocery, refrigerant leaks are another material impact; the US EPA’s GreenChill partnership works with food retailers on refrigerant management.^[37] Carbon accounting method is on GreenOps.

How does a retail operations team know its model works, rather than that its dashboards look green?

• Independent audits on a sample. Area managers or an audit team re-check a random sample of each store’s standards monthly: a recount of ten counted items, a price sample, a reset photo against the planogram, a schedule against the publication rule.
• Exception monitoring and risk indicators. Adjustments clustered just before physical inventory, items adjusted up and down repeatedly, perfect IRA with high pick failures, widened pickup windows, rising backroom stock, falling count completion, more overcharges than undercharges, more late schedule changes.
• Store voice. Count head-office task hours sent to stores weekly; an uncontrolled task calendar is a hidden labour cut.
• Closed loop. Every audit finding gets an owner and a due date; repeated findings across stores go to head office as a process defect.

Detection. The daily pick-failure report flags department rates above three times the chain norm for two consecutive days.

Triage (first two hours). The pickup lead suspends pickup eligibility for the department in store 042 (a per-store, per-department switch) so no new promises are made, and informs customers with open orders.

Diagnosis. Use the tree below. It starts from the evidence collected at each “not found”.

flowchart TB
  A["Not found at pick"] --> B{"Counted location: any stock in the store?"}
  B -->|No| C{"Did the record show stock?"}
  C -->|Yes| D["Phantom stock: correct record, find the source"]
  C -->|No| E["Order logic promised zero stock: system defect"]
  B -->|Yes| F{"Stock at the planogram location?"}
  F -->|"No, elsewhere"| G["Location error: reset or backroom not updated"]
  F -->|"Yes, at location"| H["Picker process: training or handheld issue"]
  D --> I["Check receiving, scanning, damage records"]
  G --> J["Update location data and capacities"]
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  class A risk
  class B,C,F decision
  class D,E,G,H,I,J core

Of the 31 not-found locations counted, 22 had stock elsewhere in the aisle (moved in the reset, location data not updated), 6 had no stock and a positive record (phantom stock, mostly items discontinued in the reset but never written off), and 3 were picker errors.

Remediation. Update location data from the reset planogram; write off discontinued items with the reset reason code; re-count the whole aisle; re-enable pickup for the department once a sample of 20 picks succeeds.

Verification. Department pick-failure rate back under 3% for three consecutive days; no repeat not-founds on the corrected items.

Prevention (the actual fix). Make “locations and capacities updated” and “discontinued items written off” completion criteria of the reset SOP, and suspend a department’s pickup eligibility automatically after a reset until the count is done. Warn every store with the same reset scheduled.

Post-incident review. Blameless: the store followed the reset instructions it was given; the instructions were incomplete.

• “The system says we have it.” Treating the perpetual record as fact. Instead: count where it matters and measure accuracy.
• Fixing the number, not the process. Posting adjustments without reason codes. Instead: classify every adjustment and attack the top cause.
• Labour cut by a flat percentage. The same cut harms stores where labour drives sales most.^[26] Instead: model by store and test changes.
• End-of-quarter hour cuts. Cutting hours in the last weeks of a quarter moves cost, not efficiency, if conformance and sales fall.^[25]
• Promising everything online. Making every SKU in every store available for pickup from raw records. Instead: an eligibility policy and buffers by accuracy.
• Head office as an unmetered task source. Hundreds of tasks without time estimates. Instead: an intake form and a weekly hours cap.
• Shrink league tables with mixed definitions. Comparing stores or retailers whose shrink is measured differently.^[15]
• Myth: “Out-of-stocks are a supply chain problem.” In the FMCG studies Gruen and Corsten summarise, most out-of-stocks were traced to store practices (The problem it solves).
• Myth: “More backstock means fewer gaps.” Backroom inventory rose with out-of-stocks, not against them (shelf capacity).
• Myth: “Technology X will fix accuracy.” RFID, cameras and AI make measurement cheaper; they do not change the process that creates errors unless the process changes too.

Every retailer with stores does retail operations; the question is how formal to make it. A dedicated function (standards, labour model, task governance, accuracy programme) pays off when:

• You run several stores and want them to perform alike; with one store, the owner is the operating model.
• Stores use automatic ordering or promise stock online, so record errors turn directly into lost sales or failed orders.
• Labour is a large share of store cost and is budgeted centrally.
• Stores serve as fulfilment nodes (pickup, ship-from-store, returns for online purchases).
• You face inspections or rules on prices, schedules or payment devices across many sites.

Keep it light, or do not build it yet, when:

• You run one or two stores: a written opening and closing routine, a weekly count of fast movers and a simple schedule are enough. Spend the time on the shop floor, not on a scorecard.
• You sell online only: your operations live in fulfilment and the website (SupplyChainOps, WebOps).
• Stores are operated by franchisees or concession partners under their own systems: write standards into the contract and audit them, rather than running their operations.
• Records are so poor that omnichannel promises would fail: fix accuracy first; do not launch pickup to “force” it.

Hidden responsibilities. Maintaining the labour model, policing the task calendar, running random counts that look unproductive, and refusing promises the stores cannot keep.

Two decisions recur: where to start improving store operations, and which fulfilment model a store should take on. The tree below covers the first; it is this Atlas’s heuristic, not a standard.

flowchart TB
  A["Customers report gaps or failed pickups"] --> B{"OSA and IRA measured in last 3 months?"}
  B -->|No| C["Measure first: random counts and a shelf audit"]
  B -->|Yes| D{"Most gaps: stock in the building?"}
  D -->|Yes| E["Shelf OOS: replenishment labour, backroom, space"]
  D -->|No| F{"Record showed stock?"}
  F -->|Yes| G["Phantom stock: targeted counts, receiving, scanning"]
  F -->|No| H["Store OOS: ordering parameters, shelf capacity, supply"]
  E --> I{"Hourly labour model exists?"}
  I -->|No| J["Build labour model before adding tasks"]
  I -->|Yes| K["Fix space and delivery cadence"]
  G --> L{"Pickup live on these items?"}
  L -->|Yes| M["Add buffers or remove eligibility until fixed"]
  L -->|No| N["Count programme and process fixes"]
  classDef decision fill:#fdf3e3,stroke:#c9800f,color:#122029
  classDef core fill:#e8f3f2,stroke:#16756f,color:#122029
  classDef risk fill:#fbeceb,stroke:#b4332b,color:#122029
  class B,D,F,I,L decision
  class C,E,G,H,J,K,N core
  class A,M risk

Choosing a fulfilment model: a weighted comparison. Weights and scores below are an illustrative starting point for a general-merchandise chain with a dense store network; replace them with your own. Scores run from 1 (poor) to 5 (strong); every criterion is worded so that a higher score is more favourable.

Arithmetic for pickup: 0.25×5 + 0.20×4 + 0.20×3 + 0.15×2 + 0.20×5 = 1.25 + 0.80 + 0.60 + 0.30 + 1.00 = 3.95. With low record accuracy and high online volume, the weights shift and a dedicated site can win; the matrix makes that assumption explicit. To set your own weights, start from last year’s failures and costs (missed promises, pick hours, capital limits), fix the weights before scoring, and check whether the ranking flips when any weight moves ten points; if it does, measure that criterion first.

This five-level model is this Atlas’s proposal, not an industry standard. Use it to find the next step, not to grade stores.

A plan for a new head of retail operations in a chain of 20–200 stores. Adapt the cadence for larger chains, where each phase may take a quarter.

Risks: stores read measurement as blame (focus on process defects); head office resists the task cap (show the hours); finance wants an immediate labour saving (agree a test-and-learn design).

Quick start: a new store manager’s first week

• Walk the store at opening, at peak and at close; note gaps, queues and backroom state.
• Read the store’s last four scorecards and the last physical inventory result.
• Check that the payment-device list matches the devices on the counters.
• Count ten fast movers yourself and compare with the record.
• Ask each department lead for the one process that most often fails.

Daily operating readiness (before opening)

• Tills and terminals working; float and cash procedures done.
• Availability walk of critical items done; gaps assigned.
• Price changes effective today worked and spot-checked.
• Deliveries expected today have a receiving owner and time.
• Pickup staging area clear; today’s pick windows staffed.
• Targeted count list printed or loaded.

Monthly governance review (area or head office)

• Random-count IRA, OSA, pick-failure and price-audit results by store, with denominators.
• Head-office task hours sent to stores vs cap.
• Schedules published on time; late changes and reasons.
• Adjustment patterns flagged by exception monitoring reviewed.
• Repeated audit findings converted into head-office defects with owners.

Security and compliance audit (per store, quarterly)

• Terminal inspection log complete; vendor and technician access logged and verified.
• Price-accuracy sample at or above the applicable standard; scheduling change log complete.
• Recall close-outs confirmed; age-restricted refusals logged; CCTV notices and retention per policy.

Template 1: store scorecard (one page, weekly). Targets are examples; set your own from your baseline.

STORE SCORECARD          Store ____   Week ending ________   Format ____
Sales and customers               Actual   Plan/target   Trend (4 wk)
  Net sales                       ______   ______        ___
  Conversion (txns / visitors)    ______   ______        ___
  Avg transaction; units per txn  ______   ______        ___
Availability and accuracy
  OSA, critical items (audit)     ______   >= 97 %       ___
  Exact-match IRA (random sample) ______   +10 pts / yr  ___
  Targeted counts completed       ______   >= 95 %       ___
Omnichannel
  Pick-failure rate (lines)       ______   <= 3 %        ___
  On-time-ready rate (orders)     ______   >= 95 %       ___
Labour
  Hours vs labour model           ______   +/- 2 %       ___
  Schedule published on time      ______   100 %         ___
  Shifts changed after publish    ______   <= 5 %        ___
Integrity
  Price audit accuracy            ______   >= 98 %       ___
  Terminal inspections on time    ______   100 %         ___
Top 2 actions this week: 1) __________________ 2) __________________

Template 2: store operating standard (one page).

STANDARD  STD-__  Title: _________________________  Version __  Date ____
Why it matters (customer or business outcome): ______________________
Scope (formats, departments, exclusions): ___________________________
Owner in store (R) ________  Accountable (A) ________
Trigger / frequency: _________   Time allowed (minutes): ______
Steps (max 7):
  1. ____________________________________________
  2. ____________________________________________
Done means (acceptance criteria): ___________________________________
Evidence (photo, count file, log): _________________________________
Measure on scorecard: ____________   Audit sample: ________________
Exceptions and escalation: __________________________________________

Template 3: decision record for a store technology investment.

DECISION RECORD  DR-__   Title: ______________________   Date ________
Problem (measured baseline): ________________________________________
Options considered: A) ______  B) ______  C) do nothing / process fix
Pilot design: stores ____ vs matched controls ____, weeks ____
Success criteria set before the pilot: _____________________________
Result (pilot vs control, with uncertainty): ________________________
Process changes required to keep the benefit: _______________________
Decision: adopt / extend pilot / stop     Owner ______  Review ______

The neighbour pages and their boundaries are compared in How RetailOps relates to other Ops. The comparison below is about operating models inside retail.

Store-led versus central-led operating models.

Is “RetailOps” a job title? Rarely as one word. Common titles are store manager, area or district manager and retail operations manager or director. Search for “retail operations” when looking for roles or literature.

What is the single most useful number to start with? Exact-match inventory record accuracy from a random sample, with its sample size. It tells you how far you can trust automatic ordering and online availability, and it is rarely measured honestly.

Our physical inventory shows low shrink, so our records must be fine. True? No. Shrink is a net, financial figure; phantom and hidden errors can cancel in value while many individual records are wrong. Lab 2 shows a net variance of −$97 hiding $160 of absolute error.

Should every store item be available for pickup? Only items whose records you trust, with buffers that reflect accuracy and sales rate. A failed pickup costs more goodwill than an item shown as “not available for pickup”.

Will RFID solve inventory accuracy? It makes counting tagged items much faster, which makes frequent counts affordable. Accuracy still depends on processes such as receiving, returns and write-offs. Pilot with control stores.

How do scheduling laws affect the labour model? They constrain when schedules can change. A model that needs frequent late changes breaks the rule or pays premiums; keep core schedules stable and take flexibility from voluntary swaps and standby lists where the law allows them.^[28]

Established capability. POS-based out-of-stock detection, silent-item count lists, hourly workforce management and per-store pickup eligibility.

Active practice with evidence still accumulating.

• Probabilistic inventory records: each record treated as a distribution of true stock, updated by sales, counts and not-founds, and used for ordering and promises.
• Store-specific labour response models, as in Fisher, Gallino and Netessine’s implementation.^[26]
• Item-level RFID beyond apparel, with GS1’s Gen2v3 adding features to the air interface.^[10]
• 2D barcodes at POS (GS1 Sunrise 2027), which can carry product variants and production or expiry dates and so enable expiry-aware markdowns at the till.^[11]

Speculative or vendor-led. Autonomous stores and AI agents that re-plan the store day: judge them by controlled pilots on your own fixtures, not demonstrations.

Leaders short of time can read the executive recap and the judgement call.

Situation (illustrative). It is week 10 of 13. A 150-store chain is 2% behind its profit plan. Finance proposes cutting 6% of store labour hours for the last three weeks, which would close most of the gap on paper. The head of retail operations is asked to agree.

Option A: cut 6% across all stores. Certain, immediate saving; easy to administer.

Option B: protect selling hours, cut elsewhere. Drop non-essential head-office tasks for three weeks, defer two resets, cut only where the labour model shows overstaffing, and accept a smaller saving.

Evidence and assumptions. The labour studies come from single chains: none measured this chain, and none tested a three-week cut. Assume, for the decision, that the cut would reduce availability-related work first (replenishment, counts), because selling cover is visible and gets protected.

Reasoning. Option A’s saving is certain and its cost invisible: lost sales appear on no report, and errors from skipped counts surface next quarter. Option B saves less but keeps the processes that protect availability and records. If finance insists on a fixed number, cut by store according to the model and keep matched stores uncut to measure OSA, pick failures and conversion.

Why the attractive choice can be wrong. Option A looks prudent because its benefit is measured and its cost is not. That asymmetry is the trap, not the arithmetic.

Uncertainty. If the chain is genuinely overstaffed across the board (for example after a traffic decline the model has not caught up with), Option A’s cost may be small. The way to know is the measurement, not the argument.

After this page you should be able to explain the difference between store and shelf out-of-stocks and why phantom stock is self-hiding; calculate IRA, OSA, conversion, GMROI, shrink and pick-failure rates with explicit denominators; design a count programme, a labour model by hour and a pickup eligibility policy; diagnose availability and pickup failures with evidence; and evaluate technology and labour decisions with control groups.

Retail operations is where a retailer’s plans meet physical reality, and reality keeps a different set of books. The shelf, the backroom and the pickup counter hold the truth; the records hold claims about it. Most of what goes wrong in stores is a gap between those two, widened by too little labour in the wrong hours and by head-office requests that nobody costed.

The disciplines that close the gap are unglamorous: receive accurately, count where errors are likely, keep the backroom findable, model labour by store and hour, publish schedules early, and promise online only what the records support. Technology makes each cheaper; it does not replace them. A useful test: when a customer is told an item is ready for pickup, how often is it really there, and does the business know?

All sources were opened on 2026-10-23. Legal and regulatory sources are for orientation only; check the official text that applies to each store before relying on them.

Further reading

• Why “Good Jobs” Are Good for Retailers — Z. Ton, HBR, 2012.
• Retail Trade, NAICS 44-45 — US BLS (15.5 million jobs, September 2026).
• E-commerce share of US retail sales — Census via FRED (17.1%, Q2 2026).

Changelog

• 2026-10-23: first version (research, ledger research/retailops-ledger.md, draft, eight diagrams, four executed labs).
• 2026-10-23: revision after independent review r1 (shrink basis worked example corrected; DeHoratius variance figures; Target figures moved to the fiscal 2025 10-K with the in-store-purchase caveat; Stable Scheduling Study design; NIST enforcement and ratio rules; EU Article 6a national options; pickup sequence diagram redrawn; Lab 2 and Lab 3 notes; attribution, title and precision fixes; repetition cut; low-value maturity chain figure removed, now seven diagrams).
• 2026-10-23, post-score polish (reviews/retailops-polish.md): use case 2 states the pretest stores (re-checked in the report); ATV pitfall labelled as an inference; guidance for setting matrix weights; shorter decision labels in Figure 7.