On a food-ordering platform, the menu is the product page, and nobody orders from a page they cannot read. To the customer the site looks simple: pick a restaurant, choose a dish, pay. Behind the screen it is anything but. Menus can arrive as photographs of printed cards, spreadsheets or typed notes. Prices change. Images range from studio shots to a phone held over a counter. New locations need to go live on time, and the customer still expects to choose quickly.
This note describes work our founder led at an Indian food-ordering platform that later moved into a larger international delivery organisation. The supporting record covers leadership of content writers, menu teams and backend operations, alongside campaigns, corporate communications and product improvements. We treat those responsibilities here as one connected growth and experience brief, because that is how the customer experienced them.
The publishing workflow
Each step has a distinct job. Receiving means collecting the restaurant’s information in whatever state it arrives. Structuring turns it into the platform’s agreed format. Review checks both words and images against a standard. Publishing makes the page live, and maintenance keeps it true as the restaurant changes. Most content problems on ordering platforms come from skipping the last step: a page that was right on launch day slowly drifts out of date.
Menus people can actually scan
We set content standards for restaurant pages and menus around one question: can a hungry person recognise the food, understand the choices and move through the page without deciphering inconsistent naming? Quality assurance covered written information and supporting images together, because a clear dish name next to a misleading photograph still produces a wrong order.
Menu organisation drew on how people scan choices in real life. Diners look for a category first, then a dish they recognise, then the details that decide between two options. That observation fed directly into feature discussions and filters. Our role was to bring customer behaviour into the product conversation, so that content structure and interface decisions supported the same task instead of competing for it.
The practical consequence for anyone running a menu-led catalogue is that structure decisions come before writing. Agree the levels a menu can have, the fields each level carries and the words customers use for each category. Then write. Teams that start with copy and add structure later end up rewriting hundreds of descriptions to fit a filter that arrived after them. A few hours spent on the hierarchy saves weeks of rework once the catalogue is large.
A menu information hierarchy Example
| Level | What it holds | Standard to apply |
|---|---|---|
| Category | A familiar grouping such as starters, mains or desserts | Use the customer’s words, not the kitchen’s internal codes |
| Dish name | The name a customer would say out loud | One spelling across the menu; no all-caps or decorative punctuation |
| Short description | Main ingredients and preparation | One line that helps choose between similar dishes |
| Options | Sizes, add-ons and variations | Listed under the dish they belong to, with prices visible |
| Markers | Vegetarian status, spice level, portion guidance | Shown only when the restaurant has confirmed them |
| Image | A photograph of the dish as served | Matches the description; rejected if it shows something else |
Quality that lives in the process
Scaling took more than good individual writers. The operation needed clear briefs, defined review stages and coordination between teams. Restaurant launches and chain rollouts had to pass through a repeatable process; otherwise every new page became its own small production crisis. We built the approach around practical standards: what information was needed, how it should be presented and what had to be checked before publication. Training material and documentation supported the people doing the work, so that quality stopped depending on someone remembering to intervene at the last moment.
This is what we mean by content operations and editorial standards. The standard lives in the process, written down and taught, rather than in one experienced person’s head. When that person is on leave, the menus should still go live correctly.
Three roles and the handovers between them
Writers
Turn raw restaurant information into clear names and descriptions to the agreed standard. They hand over finished copy with any unresolved questions flagged, not guessed.
Menu operations
Structure, price and publish menus in the content system, then keep them current. They hand back gaps to writers and report recurring tool problems upwards.
Product feedback
Collects what content teams and customers struggle with and turns it into evidence for product decisions. It hands requirements to product teams with real examples attached.
The handovers matter as much as the roles. A writer who silently fills a gap with a plausible guess creates an error that menu operations cannot see. A menu team that fixes the same tool problem by hand every day hides a cost that product teams never hear about. Naming what passes between roles, and in what state, is most of the work. Documenting those handovers well is a craft of its own, which we look at in a note on documenting restaurant integration.
Campaigns need a destination that works
Campaign activity included restaurant landing pages, search marketing, social advertising and content. Festival blogs and other editorial ideas gave people a reason to engage with the platform beyond a straightforward order prompt. The aim was to connect an audience’s interest with a relevant restaurant or ordering page.
The content still had to be useful once someone arrived. A campaign can attract attention, but the destination needs accurate restaurant details and a usable menu. Marketing cannot compensate for an unreliable page after the click. A festival campaign that sends people to a restaurant whose menu lists dishes it no longer makes does more harm than no campaign at all. When we work on e-commerce and ordering experiences, the destination is reviewed with the same care as the advertisement that points to it.
Timing adds a further constraint. Editorial ideas tied to festivals and seasons have a short life, so the restaurant pages they promote need checking before the campaign goes out, not after the first complaints arrive. We build that check into the campaign plan itself: the list of featured restaurants goes to menu operations with enough notice to confirm prices, availability and images. It is a small step that protects both the campaign and the restaurants named in it.
A higher click rate is of limited use if the page behind it cannot support an order.
Internal tools are part of the customer experience
The supporting record describes work on content-management and customer-management features, restaurant-page testing and cart development. We contributed observations from content operations and from user behaviour, which helped identify where a process or an interface made the customer’s task harder than it needed to be.
A small issue repeated across many pages becomes a substantial operational cost. A confusing field in the publishing system produces inconsistent customer-facing information, because each person who uses it reads it differently. We therefore treated internal tools as part of the experience chain: their design affected both the quality and the speed of the live product.
Internal and external communication ran alongside: mailers, presentations, documentation and training content that helped different teams understand the business and its processes. When the organisation moved towards migration into a larger delivery platform, the communication problem grew harder. Teams had to absorb changing requirements while keeping daily operations running. The record notes leadership of restaurant migration and rapid team expansion; we focus on the preparation and coordination involved rather than claiming an undocumented migration success rate. The wider adaptation is covered in our note on adapting the operating process for India.
Measuring what content contributes
The experience record provides no standalone order-growth or revenue figure for this platform, so we do not assign one. What we can describe is how this kind of operation should be judged. Campaign metrics only make sense alongside the quality of the destination, and content quality is measurable if you decide what to count before the work starts. The indicators below are the ones we would set up first for a menu-led platform, because each can be tracked from the publishing system and customer data most platforms already hold.
If you run an ordering platform, a marketplace or any business whose catalogue is supplied by partners, start by choosing two of these indicators and measuring them for a month before changing anything. The baseline usually surprises people. Pages that everyone assumed were complete turn out to be missing options or images, and the slowest step in the workflow is rarely the one the team complains about. That evidence is what earns content operations a proper seat in product and commercial planning.
Clear content standards also make expansion easier to discuss with restaurant partners. A plain explanation of the information required reduces back-and-forth and gives teams a basis for checking submissions. Partner communication and publishing quality become one process the business can improve. For any platform where several teams build what the customer sees as a single page, that connection is where content earns its place in the commercial plan.



