Case study · B2B SaaS · Inventory customization

Making inventory counting match how restaurants actually work

The problem

Back Office offered three fixed ways to count ingredients: case, pack, and unit of measure. Those labels were confusing, particularly when purchase pack sizes changed.

A case could represent 20 pounds one week and five pounds the next. Staff had to interpret what each field meant, and incorrect counts surfaced later as errors in reporting.

Through customer research and support feedback, we learned that restaurants had established counting practices. Staff counting steaks by the pound wanted a field labeled “LB,” rather than having to translate their count into purchasing terminology.

Some ingredients needed two or three counting units depending on where they were stored, and those practices differed across restaurants.

Defining the approach

I led research and product strategy, wrote the requirements, and partnered with our senior designer to translate those practices into a configurable counting experience. I carried the work through sprint planning, rollout, and post-launch analysis.

We gave customers the ability to select up to three counting units for each ingredient. They could choose an available unit of measure or provide a conversion when the unit they needed was not available.

For each inventory location, customers could decide which of those units appeared during counting. This allowed the fields to reflect how staff counted an ingredient in that storage location.

Customers could configure counting units while taking inventory or through ingredient management as they managed incoming purchases.

Supporting corporate standards and local practices

Multi-unit customers also needed to manage counting practices across their restaurants.

Corporate users could define up to three counting units for an ingredient and use policy settings to determine whether restaurants could override them. This supported organization-wide standards while allowing local differences where corporate permitted them.

Measuring adoption and corrections

The customization feature launched in March 2026. Within three months, it was adopted organically by 23% of 969 paying accounts.

Because counting errors were the primary customer complaint, we also compared completed-inventory reopen rates before and after launch. Customers reopened completed inventories to correct errors found in reporting, making reopen rate a relevant measure of inventories requiring correction.

The rate declined from 16.1% for inventories created before March 2026 to 12.4% for those created March–July 2026—a decrease of 3.7 percentage points.

The comparison showed fewer completed inventories requiring correction following the release. It did not isolate how much of that change was attributable to customization alone.

What we learned next

Customer feedback revealed another source of effort: applying the same configuration change across many ingredients.

For example, a customer might want to hide the third counting column across all ingredients rather than update each ingredient individually. That feedback identified bulk configuration as a next roadmap priority.

What I learned

Giving customers flexibility required understanding both how they counted ingredients and how they maintained the configuration behind that experience.

The release addressed the mismatch between fixed purchasing terminology and restaurant counting practices. Post-launch feedback then showed where we needed to simplify setup at scale, while adoption and correction data gave us evidence to assess the release.