KENYA · GUIDE 0582 · EDITION 4.7
Restaurant ordering site setup in Kenya: Risks and Launch Plan
Set the conditions for a safe commercial test
- Lost orders
- wrong prices
- unverified payment
The site creates costly confusion when it confirms an order that the kitchen never receives or accepts delivery beyond the restaurant's coverage.
A risk list is useful only when it changes a decision. For each risk, write the observable warning, who checks it and the response before the next commitment. Do not treat a reserve of money as permission to continue unsafe or unauthorized work.
Use a small, measurable pilot
Demonstrate a test order without accepting live money.
The pilot scope is: Set up ordering around the restaurant's real kitchen capacity, menu modifiers, collection windows, delivery boundaries, and payment-confirmation process before accepting orders.
| Gate | Evidence before continuing |
|---|---|
| Scope agreed | Set up ordering around the restaurant's real kitchen capacity, menu modifiers, collection windows, delivery boundaries, and payment-confirmation process before accepting orders. |
| Output acceptable | Place test orders with unavailable dishes, special instructions, and changed pickup times, ensuring kitchen staff can identify what they must fulfil. |
| Costs recorded | Include menu entry, modifier setup, payment integration where agreed, staff training, order testing, and support when menu availability changes during service. |
| Buyer response recorded | Log test orders, kitchen receipt times, modifier errors, availability changes, failed notifications, cancellations, and staff decisions about handling unfulfillable customer requests. |
Stage the launch around prerequisites
First confirm the buyer specification and activity requirements. Then compare suppliers, establish suitable facilities and prepare the operating record. Run the bounded trial when those prerequisites are in place. Review actual costs, quality failures and cash collected before increasing the commitment.
This sequence is not a promise that the complete business cycle fits into 30 days. Growing periods, qualifications, approvals, seasonal access and customer buying cycles can require longer. Revise the schedule when a prerequisite changes rather than skipping it to meet a launch date.
Choose continue, revise, pause or stop
Continue only when the scoped result is accepted and direct costs and payment timing are workable. Revise one part of the offer if the problem is identifiable and affordable to test again. Pause when required information, permission, skills or resources are missing. Stop the affected work when safety, consent or lawful authority is uncertain.
Keep a maximum test loss and unpaid-balance limit suited to your actual funds. A successful single delivery is useful evidence, but it does not establish year-round demand or justify committing every available resource.
Tie launch milestones to observable checks
| Risk signal | Evidence to inspect | Response to test |
|---|---|---|
| Kitchen gets fake test order | Check staging email/webhook destinations. | Stop tests, isolate integrations and inform authorised staff which references are fictional. |
| Customer sees paid before collection | Inspect offline payment/order-status mapping. | Use truthful status and require merchant confirmation of settlement. |
| Unavailable item still orderable | Check item status/cache and staff update process. | Correct and retest the unavailable-item fixture. |
Outstanding go / hold conditions
- Actual café rules, hosting/integrations and merchant tax settings unverified.
- No orders, payments or kitchen messages created.
Assign an owner, evidence reference and review date to each unresolved condition. Do not give every milestone a fixed calendar date when it depends on a crop, production, approval or competence cycle. Run only a suitable limited trial, reconcile accepted output and actual cash, and record whether the evidence supports holding, revising, proceeding within the limit or stopping.