How a growing multi-location retailer built an AnyDB operations layer around Shopify POS — and eliminated the workflow chaos that was costing them every week.
Ridgeline Outfitters (name changed for confidentiality) had spent the better part of two years doing the right thing on the commerce side. They migrated to Shopify, deployed Shopify POS across all nine of their locations, and built a respectable online channel that contributed roughly a third of total revenue. By any external measure, they looked like a well-run omnichannel retailer.
Internally, it was a different story. Everything behind the commerce layer — every purchase order, every vendor conversation, every receiving event, every inventory discrepancy, every approval — was running on a combination of Excel workbooks, Google Sheets, email threads, and Slack messages that people had stopped trusting because they were so frequently out of date.
The ops team had a shared Google Drive folder with 47 spreadsheets in it. Eleven of them were titled some version of "PO Tracker." When asked which one was current, the operations director said: "It depends on the day, and honestly, sometimes none of them."
Shopify was not the problem. Shopify POS was running well at every location. The problem was that Shopify ends at the transaction. Everything that happens before a product reaches the shelf — and everything that goes wrong after it does — was still living in tools that were never designed for operational workflow management at this scale.
"Shopify is clean. Our ops are not. We have 38 vendors, nine stores, and a buying team that spends half its time in email threads trying to figure out what was actually received versus what was ordered."
— Operations Director, Ridgeline Outfitters
The Blueprint diagnostic mapped the full operational picture across the business. What looked like a single "messy ops" problem was actually four distinct failures, each expensive on its own, and compounding each other.
Onboarding a new vendor meant emailing a PDF form, waiting for it to come back, extracting the data manually, and entering it into a spreadsheet that one person maintained. When that person went on leave, the process stopped. There was no vendor master record — just a spreadsheet that a lot of people thought was authoritative but wasn't. Compliance documents, certificates, and insurance records lived in email attachments that no one could reliably find.
POs were built in Excel, emailed to vendors, and then effectively invisible until something went wrong. There was no workflow — no status tracking, no confirmation loop, no visibility into which POs were outstanding, overdue, or partially delivered. The buying team kept a mental model of outstanding orders. When staff turned over, that mental model left with them. The operations director estimated that at any given moment, the business had 15–25 open POs it could not accurately account for.
When a delivery arrived, the receiving team printed the relevant PO from email, walked the delivery, noted discrepancies on paper, and then — if they remembered — updated the Excel tracker later that day. If the discrepancy was significant, they would email purchasing. Purchasing would email the vendor. The vendor would respond in three to five days.
The lag between a delivery arriving and accurate inventory appearing in Shopify POS was three to four days on average. During peak season, it stretched to a week. Associates were selling products that weren't in stock, and turning away customers for products that were.
When a count discrepancy surfaced in Shopify POS — a variant showing negative, a location count that didn't match the physical shelf, a barcode scan returning no result — the process for investigating it was: someone added a note to a spreadsheet, or sent a Slack message, or both, and hoped someone would follow up.
There was no owner, no timeline, no status, and no resolution record. The same discrepancies appeared month after month because they were never properly resolved — they were just adjusted and noted.
The buying team spent an estimated 12–14 hours per week across two people managing PO status in email and spreadsheets.
The receiving team's 3–4 day lag was creating 2–3 customer service failures per week during high-velocity periods.
Unresolved inventory discrepancies had accumulated to a variance of roughly 4.2% across active SKUs — enough to materially affect replenishment decisions and in-store customer experience.
The engagement began with architecture, not with software setup. The first deliverable from the Blueprint was a system ownership map — a clear statement of which system owns which domain, what the boundaries are, and where AnyDB sits in relation to Shopify POS.
| Domain | System Owner | What This Solved |
|---|---|---|
| In-store transactions | Shopify POS | Commerce execution stays in the commerce layer |
| Product catalog & pricing | Shopify | Single source of truth for sellable products, variants, and pricing |
| Customer records | Shopify | Cross-channel customer identity, purchase history, loyalty context |
| Vendor master records | AnyDB | Stable vendor profiles, compliance docs, contacts, terms |
| Purchase order workflow | AnyDB | PO status visible to all stakeholders; no more email-as-status-system |
| Receiving & QA | AnyDB | Receiving events with inspection records and discrepancy escalation paths |
| Inventory discrepancies | AnyDB | Structured investigation cases tied to Shopify POS locations |
| Approvals & escalations | AnyDB | Workflow-gated decisions with audit trail |
The first AnyDB object built was the Vendor master record — a single, canonical profile for every supplier that the buying team, operations, and finance would all reference. This replaced the eleven PO Tracker spreadsheets, three vendor contact lists, and two different "authoritative" supplier directories.
Each Vendor record holds: contact hierarchy, trading terms, lead times, minimum order values, payment terms, compliance document status, and a linked history of every PO and receiving event. Compliance documents are attached directly to the vendor record with expiry date fields and automated flags when documents approach renewal.
Vendor onboarding moved from a PDF email attachment to a public-facing AnyDB intake form. New vendors submit their information through a structured portal. The submission creates a Vendor Onboarding Request record, triggers a review workflow, notifies the buying team, and creates a compliance document checklist.
POs moved from Excel files emailed into the void to AnyDB workflow records with full lifecycle status. Each PO record is linked to the relevant Vendor master record, carries line items as child records, and moves through a defined status pipeline: Draft → Submitted → Vendor Confirmed → Partially Received → Fully Received → Closed.
Every status transition is visible to the full buying and operations team in real time. The buying team no longer needs to email purchasing to ask what's outstanding — they have a live view that answers the question before it's asked.
Receiving was the workflow with the most immediate operational impact. Before AnyDB, a delivery's journey from loading dock to accurate Shopify POS inventory took three to four days. After the build, it took less than one.
Each delivery creates a Receiving Event record in AnyDB, linked to the relevant PO. The receiving team uses AnyDB on a tablet at the dock. For each line item, they create an Inspection Record recording quantity delivered, quantity accepted, condition notes, and photo attachments for damaged items.
When discrepancies or damage are found, an exception path triggers automatically: quantity shortfalls create Discrepancy Cases assigned to the buying team, damaged goods create Damage Records with photos, and wrong SKUs open Mismatch Cases with vendor notification.
One of the highest-value design decisions was the handoff between Shopify POS and AnyDB. Shopify POS is where inventory discrepancies surface, but it is not where they get investigated or resolved. That work belongs in AnyDB.
Kaizen designed an explicit exception handoff protocol. Associates flag discrepancies through the store's AnyDB Inventory Discrepancy view. A Discrepancy Case record is created, pre-populated with location, SKU, and variance data. The ops team investigates, records the root cause, and closes the case with a classification.
For the first time, Ridgeline had a record of every inventory discrepancy — not just the ones that someone remembered to note in a spreadsheet column.
"We onboarded three new vendors in the first month after go-live. All three were cleaner and faster than any onboarding we'd done in the previous year. The information was there when we needed it, not buried in someone's sent folder."
— Senior Buyer, Ridgeline Outfitters
One back office. Visible, structured, and under control.
Ridgeline went from 38 vendors managed across disconnected spreadsheets and email folders to 38 vendor records in AnyDB with full contact history, compliance status, trading terms, and a linked record of every PO and receiving event. The buying team can pull up any vendor profile and know, in under 30 seconds, every outstanding order, every recent delivery, and whether their compliance documents are current.
The buying team reclaimed approximately 14 hours per week that had previously been consumed by manually chasing PO status across email and spreadsheets. That time went back into buying decisions, vendor relationships, and the category planning work that actually moves the business.
In the first month after the receiving workflow went live, Ridgeline logged 94 receiving events across all nine locations. Three discrepancy cases were opened. All three were resolved within 48 hours with documented root causes. Previously, the receiving team estimated that one in four deliveries had some form of discrepancy that went either unresolved or unrecorded.
The Shopify POS–to–AnyDB exception handoff closed the loop that had been open for years. Every resolved case carries a root cause classification — receiving error, vendor short-ship, system entry error, or theft — visible at the aggregate level for the first time. In the three months after go-live, the inventory variance rate across active SKUs dropped from 4.2% to 0.8%.
The most important decision was made before any AnyDB record was built: establishing which system owns which domain and not allowing that boundary to blur. Shopify POS owns commerce. AnyDB owns operational workflow. Clean boundaries made every individual workflow simpler to build, simpler to maintain, and simpler for staff to use.
Three months after the back-office workflows were live, Ridgeline returned with the next layer of operational friction.
The merchandising team was running seasonal planogram changes through email approvals and WhatsApp messages to store managers. Store task management was being coordinated through a group chat with no assignment, no status, and no accountability.
Phase 2 extended the AnyDB model into two new domains: a Merchandising Request workflow with a defined approval chain, and a Store Task management system with due dates, completion confirmation, and escalation logic.
Within six weeks of Phase 2 go-live, the 14 outstanding planogram change requests that had been sitting in email for an average of 23 days were all resolved.
Shopify is not supposed to manage vendor relationships, purchasing approvals, receiving QA, or inventory investigations. It is a commerce engine. The right question is not "how do we get Shopify to do this" — it is "what system should own this, and how does it connect to Shopify cleanly."
Every retailer using spreadsheets for operations is not using them because spreadsheets are good at this. They are using them because nothing with the right structure was ever built. The cost of that gap is mostly invisible — it shows up in coordination time, in receiving errors, in inventory variances, and in staff frustration.
Vendor master first. Then PO workflow. Then receiving and QA. Then exception management. Each layer depends on the one before it. Trying to build everything at once is the fastest path to a system no one uses.
* Client name and identifying details have been changed for confidentiality. All operational outcomes and metrics reflect actual engagement results. This case study is a composite informed by multiple Kaizen Commerce back-office delivery engagements and represents outcomes achievable with structured implementation discipline.