Case study · Enterprise SaaS · Multi-unit architecture
Helping restaurant groups manage their data in one place
Scale: 76 restaurant groups · 1,180 active locations
Timeline: Approximately 2022–2025, with a temporary shift toward accounting development.
My role: Product Manager leading research, strategy, prioritization, requirements, and rollout, alongside our president, principal architect, and lead designer.
The problem
Orderly, later known as Back Office, was restaurant food-cost management software built around individual locations. Groups with identical menus and ingredients had to repeat the same updates at every restaurant. It was our biggest customer complaint.
Through interviews and support feedback, we found that one person often managed the system for an entire group. They wanted to make changes once and control what happened across their restaurants.
How I approached it
I prioritized centralized ingredient management because ingredients supported inventory, recipes, accounting categorization, and food-cost reporting. Getting that foundation right would make the next capabilities possible.
We introduced a corporate account linked to individual restaurant locations, allowing users to manage ingredients centrally and distribute updates. We also built a Customer Success-only interface to configure these structures and reporting groups.
Customer demand then guided us toward centralized recipe management. After launch, feedback showed that locations missing an ingredient could reject updates, leaving recipes incomplete. I worked with our architect to prevent incomplete recipes by automatically creating missing ingredients at each location, and with design to explain that behavior to users.
As larger groups adopted the system, we had to balance consistent corporate data with flexibility for staff working in individual restaurants.
An acquisition temporarily shifted priorities toward accounting. When multi-unit work resumed in 2025, I focused on giving restaurant groups more flexibility through a policy system.
Counting-unit overrides allowed corporate users to choose between standardized inventory counting and local customization. Broader local ingredient management remained on the roadmap.
The result
The structure grew from 2 to 76 restaurant groups, encompassing 1,180 active locations. Each group had at least one corporate account configured and at least one active restaurant.
What I learned
The initial research pointed toward locking down data centrally. Working with larger groups showed us that governance also needed to accommodate local differences. My approach evolved from eliminating repeated work to giving customers a choice about where control belonged.