WhatsApp + AI = the back-office Zomato will never give you

We've been having the same conversation with Indian restaurant owners for a year, and it almost always ends the same way. Somewhere around the third coffee, the owner says — half a joke, half not — "If only Zomato would just send me my customer list." And every time, we have to gently say the thing they already know: Zomato is never going to send you your customer list. Not next quarter, not next year. Not because the people at Zomato are bad people. Because Zomato giving you that list is the exact moment the Zomato business model stops working.

This is the part of the conversation we want to write down, because it changes what an owner should build next.

The aggregator can't be your back-office. It's a structural problem, not a roadmap problem.

If you wait for Swiggy or Zomato to ship the operational layer your restaurant actually needs, you will wait forever. Not because they are slow. Because what you need and what they sell are pulling in opposite directions.

Look at what an Indian restaurant owner genuinely needs every week:

• The customer's phone number, so the owner can WhatsApp them a Diwali pre-order.
• A line-by-line settlement audit, so the owner can dispute the ₹12,400 "packaging adjustment" that wasn't in the contract.
• A direct-channel option that pays 0% commission, so a regular doesn't have to be re-purchased every Friday at 22%.
• A GSTR-3B draft that knows Table 3.1.1 has to net-out the Section 9(5) supply on aggregator orders.

Now look at what Swiggy and Zomato sell. Their entire business is the customer relationship — the demand they aggregated, the phone numbers they hold, the search bar the customer opens on Friday evening. If they hand the owner the back-office that makes those things cheaper to do without them, they have just shipped the feature that lets a restaurant un-rent its own customers. That's not a product roadmap question. That's an existence question. Companies do not ship features that end them.

So the back-office layer — the one every restaurant in India needs — is not "delayed" inside Zomato. It is structurally outside Zomato. It has to be built somewhere else, by someone who isn't paid by the commission on a re-acquired customer.

The one place the restaurant already owns is WhatsApp.

Here is the part that's lucky for everyone. The restaurant owner already has a piece of operational infrastructure that the aggregator does not own and cannot revoke. It is the WhatsApp number on the signboard. It is the number printed on the bill. It is the number the regular saves under "Joshi ji ka dhaba" on their phone.

WhatsApp is not just a messaging app for Indian SMBs — it is the operational layer. It is how the owner pings the chef, how the supplier confirms paneer delivery, how the CA sends the GSTR-3B draft, how the regular asks if you have Jain options for Tuesday. It is already the place where the restaurant runs. The aggregator has never been inside this layer. The aggregator never will be.

This is why the back-office Zomato will not give you can — and probably should — be built inside WhatsApp. Not because WhatsApp is fancy. Because it is the one piece of infra the aggregator does not get to take away when the contract renegotiates.

What does the back-office management look like, then?

When we sit with owners and sketch the back-office management layer that the aggregator structurally cannot ship, the same six jobs keep surfacing. None of them are exotic. All of them are work the owner is already doing or already failing to do.

One — a daily P&L brief at 9am. Not "Swiggy partner panel says ₹18,000." A unified picture: Swiggy plus Zomato plus Magicpin plus the UPI tap log plus the dine-in cash drawer, netted of the real commission, in one paragraph. This number does not exist anywhere in the aggregator app, by design.

Two — a weekly settlement audit, with the dispute already drafted. The line-item "packaging adjustment" that appeared mid-month gets flagged automatically, screenshot of the contract attached, sent back as a one-tap dispute. We have watched owners file these and get the money back inside two weeks. The aggregator's app will never run this audit on the owner's behalf. The audit's whole point is to find the aggregator's mistakes.

Three — a GSTR-3B draft on the 14th, with Table 3.1.1 already netted. Section 9(5) of the GST rules says Swiggy and Zomato pay GST on the restaurant's behalf for the orders they deliver. The restaurant has to report those at zero tax in Table 3.1.1(ii) — and almost no one gets this right the first time. The aggregator's app will not draft the GSTR-3B for the restaurant. The CA might, after an 18-day chase for documents. AI can do it in 30 seconds from the Petpooja day-end export, the moment Table 3.1.1 numbers stabilise.

Four — a customer winback to the people who haven't been back in 90 days. This requires the customer list. The customer list lives in the dine-in QR scan, the UPI tap, the Google reservation, and the WhatsApp opt-in. The list does not live in the Zomato app. The aggregator cannot ship this feature because shipping it would put the regular back on the dine-in chair instead of the delivery queue.

Five — kitchen translation. "Table 5 ke liye Jain — no onion, no garlic, no aloo." The owner WhatsApps the line in Hinglish. The kitchen reads it in Bengali, because that's the language the line cook speaks. We have watched the same instruction get lost in three-way kitchen telephone often enough that this turned out to be a real job — not a toy use case.

Six — a DPDP-compliant broadcast to the customers the owner actually owns. This is where it matters that the back-office is built by someone who thinks about the DPDP Act 2023 ahead of the 2026-2027 compliance window. The broadcast list gets pre-filtered against consent state. Numbers without explicit marketing consent get a consent-collection message first. The owner does not have to think about Rule 88D-style notices later because the consent log was kept from day one.

None of these are "AI features." They are operational jobs the restaurant has always had to do. AI is just what makes it economic for a single-outlet restaurant to have them done at all.

Why "the aggregator might build this someday" is not the right hope to have.

Owners sometimes ask us a fair question: what if Swiggy adds a back-office tool? What if Zomato launches a partner dashboard that does this stuff?

Our honest answer: even if they do, you would not want to put the back-office layer there. Because the moment the back-office runs inside the aggregator's app, the aggregator owns the audit, the GSTR draft, the customer list, the broadcast log, and the dispute history. You would be handing the auditor's notes to the company being audited. We have not seen the version of that movie where the restaurant wins.

The back-office has to be built by someone whose business model does not depend on holding the restaurant's customer hostage. That is the test. If the answer to "would shipping this break my business model" is yes, the platform structurally cannot ship it. Apply that test to Swiggy. Apply it to Zomato. Apply it to any partner-panel feature you are waiting on. You will save yourself the wait.

So what now

If your back-office is currently the Zomato partner panel, the Petpooja day-end, a WhatsApp group with your CA, and a Notes app on your phone — you already have all the pieces. The work is connecting them in the one place that's yours: your WhatsApp number. AI is what makes the connecting cheap enough to actually do.

That is what we built SideKyk for — a WhatsApp-native back-office team that runs all six of these jobs from your existing number, without you ever opening a partner panel. Aapka kaam aapka, paperwork hum dekh lenge. If you want this running by next morning's briefing, drop your number at sidekyk.ai/restaurants and we will WhatsApp you when your slot opens.