The food industry just experienced the biggest decade ever for customer-facing technology (point-of-sale, order-ahead apps etc.). Meanwhile, we kitchen and back-of-house folks are still living in the past, spending most of our days in tired spreadsheets and older software tools that make us grind our teeth.
But now there is a better way…
The fastest-growing food companies of today are realizing this industry-wide lack of investment into kitchen and back-of-house innovation has created a situation where the ability to sell often outpaces the ability to create, plan, and produce the food that’s sold—at least in a way that’s profitable and organized.
There’s a growing push to rethink the operating systems that underlie culinary and kitchen operations—and we’re seeing meaningful gains in profitability and scalability for those who do.
Let’s talk about the new Culinary OS.
Why the Typical Culinary OS Feels Like It’s From 1995
Running a kitchen is the most complicated and important part of any food business with dozens of tasks ranging from menu engineering, planning, food costing, inventory, procurement, making prep lists… the list goes on and on.
Food businesses can go one of three ways to manage all of these processes:
- Fire up the spreadsheets. Sheets are can be so flexible. But when you’re working with dozens to hundreds of recipes, thousands of ingredients, and dozens of regions, it’s not manageable. There’s too much room for error, access control, and changing/connecting spreadsheets is near-impossible. It’s no wonder why so many food brands we connect with use spreadsheets as estimated guesses, but not a source of definitive truth.
- Drudge through the “all-in-one” ERP. At a certain size, so many businesses to one of the big ERP players, and since they’re not easy to use, and can feel like they were designed for robots instead of people—these tools are only somewhat functional because they’re challenging to use. It’s why many on your team default back to spreadsheets and the backs of napkins instead.
- Find a different software for every function. Tracking nutritionals, food costs, allergens, recipes, and menu planning in five different tools? More common than you’d think. And since so many of these tools cannot share data and talk to each other, it’s really just back to the ole spreadsheet game.
Realistically, most food businesses we interact with use a mixture of all three options as if they’re programs running on a computer. For each task they must complete, they open a program, run some numbers, then close the program. Inventory and purchasing, for example, behave like two different programs that don’t talk to each other. Copy paste, rinse repeat, day-in-day-out. Errors, stress piling up constantly.
This makes food data (1) fragmented and incomplete, (2) difficult to share in-between teams and tools, and (3) a very manual process to find deeper insights into costs, operational efficiency, or new opportunities.
Back in 1995 we were lucky if it took only a day to put together a food cost report for finance or R&D teams because we had to open and close so many programs to jot down notes manually.
In so many ways, not much has changed.
Food Data Should Be More Like a Universal Language
The culinary operations status quo of today means people in supply chain, culinary R&D, demand planning, finance, and kitchen ops often speak different languages, and cannot communicate, or collaborate easily
Finance only speaks in actual food costs from the month before. R&D is all about theoretical food costs of upcoming menus. Meanwhile, your twenty Back of House Managers are trying to figure out which version of the PDF they’re supposed to use to plate dishes.
Connecting the dots is time-consuming. It’s not uncommon for leaders to spend half their day just collecting data and sending it to someone else (let alone make important business decisions). Sound familiar?
Food businesses are ditching this old methodology, for something different and new, as quickly as they can once they realize how much it’s holding them back, how much time they’re wasting, how much stress is created, and how frustrated teams really are.
The growing push is now for a Culinary OS that uses a universal language so food data can flow to any tool and team without the need for manual data pulling or interpretation.
We’ve written extensively about how the Open API opens the gates to a whole new world of flexible and interchangeable food data that works across any software (whether they formally integrate or not).
This shift in technology in the culinary world doesn’t just mean businesses can integrate software more cleverly to save time or reduce manual error. Those benefits are meaningful, but the deeper advantages of data clarity and smarter decision-making compound in a more significant way.
The New Paradigm for the Culinary OS
Standard old-style culinary operating systems are like running individual programs (spreadsheets, PDFs, reskinned accounting software) to accomplish individual tasks (menu planning, food prep, recipe costing), then having to compile reports manually from each program. The amount of time and effort it takes to pull the reports and format it so that they’re comparable is the biggest bottleneck to savvy management and growth.
The new Culinary OS paradigm works by leveraging a single, central hub of food data. You may still use ten programs, but instead of booting up with their own data silos, they connect to the food data hub, get the most recent updates, and then continue to update in real-time. One source of truth for cross-functional, collaborative food teams.
Here’s how this often looks practically:
- Food costing software automatically has this morning’s vendor pricing update
- Culinary R&D teams plug and play different ingredients to see real-time cost changes
- Menu planners drop newest recipes into a calendar to see expected profits over time
- Kitchen teams arrive to work with access to the latest recipe specs in their hub
- Purchasing software suggests optimized purchasing accounting for current inventory and spoilage forecasting
As long as a brand’s food data is centrally housed in one place with an Open API, all teams, locations, and software tools can access it, change it, and update each other in a moment’s notice.
This isn’t just about saving time or headache.
This paradigm shift represents a change in the fundamental speed and brilliance with which a team can operate. When a cross-department decision can be made in an hour, rather than a week, there’s a compounding effect that ripples through the entire business.
It’s how the Kebab Shop increased profits enough to pick up the pace of scale by reducing food waste and optimizing recipe margins.
It’s how a legacy restaurant chain overcame all operational odds to create a ghost kitchen effort that’s keeping the business on a growth trajectory.
It’s how we’ve seen dozens of food businesses that use Galley transform their operation to outsmart supply chain challenges, stay on top of quick-moving trends, and pivot to new concepts and business models.
Galley is a food data platform that’s leading the way toward the new Culinary OS, and food businesses you know (and probably compete against) are already seeing the benefits of adopting the new paradigm.
We’re giving brands like yours the power of real-time, flexible data via an Open API—it’s the path away from clunky old systems and toward a smarter and more profitable operation.
Want to see how Galley works? See our Culinary OS here
What’s a Rich Text element?
The rich text element allows you to create and format headings, paragraphs, blockquotes, images, and video all in one place instead of having to add and format them individually. Just double-click and easily create content.
Static and dynamic content editing
A rich text element can be used with static or dynamic content. For static content, just drop it into any page and begin editing. For dynamic content, add a rich text field to any collection and then connect a rich text element to that field in the settings panel. Voila!
How to customize formatting for each rich text
Headings, paragraphs, blockquotes, figures, images, and figure captions can all be styled after a class is added to the rich text element using the "When inside of" nested selector system.