Write it for the person holding the order.

Restaurant marketing and restaurant technology meet at the order, and the order only works if everyone involved understands the same process. A customer expects the menu to be accurate and the transaction to go through. Behind that expectation, an ordering platform and a restaurant’s point-of-sale system need a shared understanding of the information they exchange, the steps they follow and what happens when something goes wrong. Clear technical communication makes that relationship far easier to manage.

The experience record mentions point-of-sale technical documentation for an international pizza chain, produced within our founder’s work at a food-ordering platform. It does not describe a consumer advertising account or any responsibility for the chain’s brand. So this note stays where the record does: integration documentation and the operational communication around it. Where we describe method, we are describing how we run this kind of work, not claiming every step was documented at the time.

Start with who has to act on the document

We begin by identifying who needs the documentation and what each person has to do with it. Those audiences need different formats. Giving everyone the same technical document feels consistent but usually creates confusion: the operations user drowns in field definitions, and the manager cannot find the one open risk buried on page fourteen. Our job is to organise the information so each reader can carry out their task while all of them refer back to one shared account of the integration.

This is the core of task-based editorial and documentation. The useful test is whether this person can find the action they need and do it correctly. Checking that everything is in there produces a very different, and usually worse, document.

A quick audit of any existing document shows which kind you have. Pick a common task, such as handling an order that has not reached the kitchen, and count how many pages someone must read before they reach the first instruction. Then ask whether the instruction tells them what to do or only describes how the system works. Descriptions are necessary for specialists. People running a busy restaurant shift need the action first and the explanation one click away.

Write around the process people follow

Technical documentation should follow the process it supports. We structure material around the relevant flow, the information exchanged at each point and the questions likely to arise. Terminology stays consistent from start to finish; if the document calls something an order reference in one section, it does not become a transaction ID two pages later. Examples help readers understand a procedure, but they must never imply functionality that has not been confirmed.

This is where editorial discipline earns its keep. An unclear sentence in a promotional asset costs some response. An unclear sentence in an integration document can lead two teams to build incompatible assumptions. The writing has to be precise enough to support implementation and readable enough for someone to use during a busy evening service.

A good document also makes its assumptions visible. If a step depends on a confirmed system behaviour, that dependency belongs in the text. Reviewers can then see exactly where specialist validation is needed, and operations teams are less likely to treat an unconfirmed detail as an instruction.

Exceptions deserve more space than most writers give them. The normal flow is usually understood after a day or two of use. What people return to the document for is the unusual case: an item the restaurant system does not recognise, a price that differs between the two sides, an order that arrives twice. Each exception should say how it shows up, what the person on shift should do first and when to stop and escalate. Escalation, in turn, should name a role and the information to send, so the person receiving the problem does not have to ask for it.

Connect technical detail to the live service

The broader experience behind this work includes restaurant content, customer-management systems and platform features. That context matters because an integration affects more than the integration. A technical change can alter how restaurant information is published or how a team investigates an order problem. We bring those consequences into the documentation discussion without inventing the underlying architecture. Our task is to ask the right questions and make the confirmed answers usable. Technical specialists remain responsible for validating the system details.

This is where a team with both marketing and product experience is useful. It can explain why a system detail matters commercially, for instance why a menu change made in one place must appear correctly in the other before a promotion goes live, without claiming to replace the engineering team. The result is a better conversation between the people responsible for implementation and the people responsible for customer-facing quality.

The customer stays in view even though the work is internal. The restaurant page and the ordering flow depend on accurate information and working processes. We encourage teams to review how a documented procedure supports that experience, rather than treating technical completion as the only goal. For the content side of the same platform, see our note on the restaurant content operation.

A document earns its place when the person holding the order can find the step they need.

Handover, training and keeping it true

Once documentation is approved, people need a practical way to learn the process. Training can introduce the normal workflow and show where to find more detail. A concise guide supports recurring tasks while the full document stays available for reference. This is communication that helps teams use a process, and it decides whether good documentation is used or ignored.

Training works best when it mirrors the quick guides rather than the full reference. A short walkthrough of the handful of tasks people perform most often, followed by a demonstration of how to find the exceptions section, gives new users confidence quickly. The detailed reference then becomes something they consult rather than something they were expected to memorise.

A review session with intended users exposes unclear instructions before handover. Asking readers to locate a specific procedure tells you far more than asking whether the document looks complete. Watching where someone hesitates shows where the organisation, wording or context needs work. Preserving that kind of knowledge across a wider organisational change is the subject of our note on preserving knowledge across a platform transition.

Judging whether the documentation worked

The record provides no reduction in order errors, support tickets or integration time, and we will not manufacture one. A published figure would need original records that support both the attribution and the reporting period. What can be assessed is whether the communication did its job, which is a separate question from whether the system performed.

For restaurant and platform teams, the value is a clearer shared explanation of a process that sits right at the order. For the wider business, it means steadier coordination around a moment the customer notices immediately when it fails. If your teams keep asking the same questions about a process that is supposedly documented, the document is usually organised for its writer rather than its readers.

If you are planning an integration of your own, three steps will improve almost any documentation effort. Name the readers and the task each one must complete before anyone starts writing. Agree the vocabulary, including what each field and status is called, and hold every document to it. And schedule a review with real users before handover, while there is still time to fix what they struggle with. None of this needs a large budget; it needs someone who owns the reader’s point of view from the first draft to the final sign-off, and the authority to send a document back when it fails that reader.