This post is for operations and finance leads at multi-location businesses: chains, franchises, anyone whose outlets each run their own tills. It covers a data project we ran in 2021-2022 for a major Vietnamese coffee chain, during the pandemic. That project taught us more about organisational change than any management book has, and it still shapes how we run data work.
Where they started
The chain asked us for "better reports." It had grown past 200 outlets across Vietnam, and its systems had grown the way they usually do in a fast-scaling business, one urgent fix at a time with no master plan.
Once we looked closely, we found five different POS systems spread across different generations of outlets. Some stores ran software that hadn't been updated in years, others were on a current cloud POS, and none of them shared data. Different finance teams had set up several accounting databases at different times. Every Monday morning someone at head office spent hours copying outlet exports into a master spreadsheet, so by the time management read the report, the numbers were days old. Ask two departments about revenue and you got two different figures.
If you run more than a handful of locations in Southeast Asia, you probably recognise some of this.
What we did
Our first conversation was about data ownership: who generates each number, where it lives, and who answers for its accuracy. Dashboards and AI came much later. We still run every data engagement in that order, and it is the second step of how we work, "data before tools."
Data audit (2 weeks)
We mapped every system that produced transaction data, down to individual POS terminals, accounting tools and the spreadsheets people had built to bridge the gaps. Even the CTO hadn't seen the full picture before we drew it. Today this first step is our Lean Tech Audit.
Pipeline (6 weeks)
We built a pipeline that pulled from all five POS systems and the accounting databases into a single BigQuery data warehouse. Three decisions shaped it.
We chose BigQuery over a self-hosted warehouse. For a chain that size, the maintenance cost of running our own would have outweighed the cloud bill, and we didn't want the client hiring a DBA just to keep the warehouse up.
We synced incrementally instead of doing batch dumps. Plenty of outlets had unreliable internet, so the sync had to survive connection gaps without losing transactions.
We standardised the schema. Each POS named things its own way: a "discount" in one was a "promotion" in another and a "price adjustment" in a third. That mapping took more of our time than any other technical task.
Dashboards (3 weeks)
With clean data in one place, the dashboards were the quick part: real-time revenue across all 200+ locations, outlet-by-outlet comparisons, product mix and inventory velocity.
The day we remember is the Monday after launch. The team that used to do the manual consolidation watched the numbers update on their own and asked, "What do we do now?"
Results
Reporting time fell by 70%, and the Monday spreadsheet job went away. Management had real-time visibility across every location for the first time in the company's history. Store managers could see actual product movement, so stock adjustments went from a weekly cycle to a daily one. Outlet-level numbers also exposed underperforming stores that the aggregated reports had hidden, and acting on those saved money.
The change we valued most showed up in meetings. Strategy discussions used to open with "I think...", and afterwards they opened with "The data shows..."
Running it remotely during COVID
We delivered the whole project during lockdowns and never visited an outlet. Every integration happened over remote access to the POS systems, video calls with outlet managers and asynchronous coordination across time zones.
That constraint helped more than it hurt. With no hallway conversations, we wrote every decision down in a shared space. We couldn't touch a server, so we designed systems that didn't need on-site maintenance. Outlet staff learned the tools over video, which pushed us to make them simple enough that a 20-minute call was all the onboarding anyone needed.
We have kept those habits on every engagement since. If fixing a system means flying someone to a site, we haven't built it well enough.
What we would change today
We built rule-based alerts, for example notifying management when an outlet's daily revenue dropped more than 30%. Now we would add AI anomaly detection over the BigQuery data to catch patterns nobody would think to write a rule for. Our AI workflow automation work has matured enough that this is straightforward.
The team would also be smaller. With AI-assisted development, we estimate the same scope would take half the people and two-thirds of the time. That estimate comes from the shift in our own team structure over the last few years.
If this sounds like your business
Nobody posts about schema normalisation on LinkedIn, yet the dashboards and AI agents everyone wants depend on it. We now offer this as our Data & AI Solutions service: a BigQuery warehouse, ETL pipelines from your existing tools, and reports your team can run without us. When a business also needs someone to own the data strategy across vendors and departments, it sits inside our Fractional CTO package for SMEs.
If your outlets still run on disconnected systems and a Monday-morning spreadsheet, start with an audit before buying any AI tool. Our data-first framework works the same way whether you have 5 outlets or 500, and when you want a second pair of eyes on your own setup, tell us what you're running.