At Zareen's the catering channel served Stanford, Google, Apple, Meta, LinkedIn, Salesforce, Cisco, Adobe, and Nvidia. When I inherited it, the "CRM" was a shared inbox and a Google Sheet that got out of date every Friday. Six months later, after replacing that mess with something that actually held, the same team was running roughly 3x the volume with fewer errors and better margin. The tool did not do the work. The right model of the relationship did.
This is what I have learned about building CRMs for corporate catering clients, mostly from watching what did not work first.
Enterprise catering is not a sales pipeline
Most CRM tools are built around a sales pipeline: lead, prospect, opportunity, deal, close. That model works for anything you sell once. It falls apart for anything you sell 40 times a year to the same buyer.
Enterprise catering is the second case. A Google office manager who orders lunch for the engineering team every Wednesday is not a "lead" being "worked" toward a "close." They are a repeat buyer whose next order lives on a cadence, and whose loyalty is earned by making the 41st order easier and better than the 40th.
When you force enterprise catering into a pipeline CRM, three things happen. The sales team spends 40 percent of their time on data entry that produces no revenue. The dietary and preference data lives on the wrong object and gets lost between orders. And nobody notices when a repeat buyer skips their cadence, because there is no "deal" to slip and no dashboard flagging it.
Fig. 1 · The relationship map that actually retains enterprise catering accounts.
Model the buyer and the account, not the deal
The data model that works looks like this. The Account is the parent object: the company, the standing dietary profile, the invoice information, the delivery address, the budget authority. The Buyer Contacts are children of the account: the office manager, the executive assistant, the finance contact, the head of the team the food is for.
Orders are children of the account, not children of the buyer. This matters. When an office manager leaves and a new one takes over, the account continues, the orders continue, the dietary profile continues. The buyer changes, the relationship does not.
Touches (calls, emails, notes) attach to both the buyer and the account. The account view shows every interaction across all buyers historically. That single view is what lets a new account manager pick up a departed colleague's relationship in an hour instead of a month.
Eight fields per order. Not fifty
The single biggest reason catering CRMs die is field creep. Every stakeholder wants their field. Marketing wants source attribution. Finance wants payment terms. Ops wants delivery instructions. Kitchen wants prep times. Six months later there are 47 fields on the order form and the sales team is filling in eight of them because that is all they have time for.
The pragmatic order object has exactly eight fields:
- Date and time of delivery
- Headcount and any variance range
- Dietary flags (vegan count, gluten-free count, allergens, restrictions), pre-populated from the account profile
- Delivery location, with building and floor if applicable
- On-site contact at delivery time, with phone number
- Invoice contact, defaulted from account
- Menu items ordered, either from a saved template or freeform
- Notes, freeform
Everything else lives on the Account object once, not on every order. Payment terms, tax status, standing dietary profile, standing delivery instructions, preferred packaging. Set once. Reused every time.
The 41st order should require typing four things: date, time, headcount, and menu. Everything else pre-fills from the account. If it does not, your CRM is losing you the relationship.
The dietary profile is the most valuable field in the system
This is the piece that most catering operations get wrong, and it is the piece that decides whether an account renews or slips away quietly.
A typical enterprise account (say, a 60-person engineering team at a tech company) has a stable dietary profile: three vegans, four gluten-free, two nut allergies, one shellfish allergy, one strict kosher, one dairy-free. That profile does not change week to week. It changes when someone joins or leaves the team.
The catering operation's job is to nail that profile on the first order, protect it in the CRM, pre-populate it on every subsequent order, and reconfirm it (not re-collect it) with the buyer. Every new order form shows the standing profile at the top, with the question "any changes for this order?" That single design choice is worth more than any menu variety or price competitiveness in the market.
When a buyer has to re-explain the dietary needs of their team every time they order, they leave. When they never have to explain it again after the first order, they stay for years.
The reorder trigger, at 5 days and 30 days
The single most valuable automation in a corporate catering CRM is the reorder trigger. Not the pipeline stage advance. Not the win-loss report. The reorder trigger.
Here is the mechanic. Five days after any completed catering order, the CRM sends an automated task to the account manager with three pieces of context: the account, the order that was completed, and the account's typical reorder cadence. The account manager sends a personal followup message. "Hope Wednesday's lunch landed well for the team. Want me to hold the same slot next week?" Not a survey. Not a marketing email. A one-line note from a human.
Thirty days after the same completed order, if no reorder has been placed, a second task fires. This one prompts the account manager to surface a menu variation. "We just added Korean bowls to the catering menu. Thought your team might like a change of pace."
That two-touch cadence, run automatically from the CRM, is worth more than any marketing spend. In one operation it lifted repeat rate from about 62 percent to about 84 percent inside two quarters.
Fig. 2 · The two-touch cadence that lifts repeat rate 20+ points.
Why Salesforce is usually the wrong tool
I have watched three catering operations try to run on Salesforce. All three eventually reverted to Airtable or a purpose-built tool. Salesforce is a great tool for the right shape of business. Enterprise catering is not that shape.
The problems, in order:
- The setup cost dwarfs the ROI. Salesforce with a catering configuration costs $10,000 to $40,000 in setup labor and $150+ per user per month. For a catering operation doing $3M to $8M in annual revenue with 4 to 8 users, that is a heavy tax.
- The workflow is deal-shaped. Salesforce wants to move records through stages: Prospect, Qualified, Proposal, Closed Won. Catering does not have those stages. Orders are placed, delivered, and either reordered or not. Forcing them into a pipeline creates data that describes nothing.
- Adoption dies in the field. The catering coordinator taking orders on a Tuesday morning is not going to click through five screens to log a $600 order. They will keep using email and update Salesforce on Friday, which means the data is always three days stale.
Where Salesforce works: catering operations that are properly sales-led, with a real BD function pursuing net new logos, closing multi-year contracts, and running enterprise agreements. That is a different business than the one most restaurant catering channels run.
The tools that actually work
My default stack for a mid-market catering operation, up to about $10M in catering revenue:
- Airtable as the CRM. Accounts, buyer contacts, orders, dietary profiles, touches. Adoption is high because the interface feels like a spreadsheet.
- Zapier or Make for the reorder trigger, order confirmation emails, and the sync between the CRM and the kitchen production system.
- Toast for the fulfillment and payment side. The CRM writes the order into Toast for kitchen production and payment collection.
- QuickBooks Enterprise for the invoicing and AR side, syncing from Toast.
Total monthly cost for a 6-user, 20-account catering operation: about $400 to $700 all in. Compared to a $2,500+ Salesforce bill, adoption is dramatically higher and the data is dramatically fresher.
For operations above $10M in catering, look at Tripleseat or Total Party Planner. Both are purpose-built for hospitality catering, both solve the ordering side well, and both need to be paired with a lighter CRM for the relationship side.
The mistake I made and would not repeat
The mistake I made early was building the CRM around the orders instead of around the accounts. The order object had 30 fields. The account object had four. Every time an account manager wanted to know the standing dietary profile of a repeat buyer, they had to open the last order and hope it was complete. The data was there, technically. But it was in the wrong place, and it made the 41st order harder than the 40th instead of easier.
The fix was moving standing information up to the account object and letting orders inherit it. That single restructure, done in a weekend, dropped average order entry time from about 6 minutes to about 90 seconds.
The point
A corporate catering CRM does not exist to track a pipeline. It exists to make repeat orders easier. That difference is the whole game.
Model the buyer and the account. Keep the order object thin. Live-fill the dietary profile from the account. Run the two-touch reorder trigger. Pick the tool that fits the shape of the work, not the tool with the most Gartner ink.
The catering operations that hold enterprise accounts for years do this. The ones that lose them do not. It is that simple, and it is the difference between a catering channel that carries the restaurant P&L and one that drags on it.