A useful restaurant database is a governed record of customers, orders, preferences and service history. It is not a collection of every detail available from every channel.
Define the database purposes
| Purpose | Typical data | Control |
|---|---|---|
| Fulfil an order | Contact, address, items, status and payment reference | Retention and access linked to operation |
| Customer support | Order history, complaint and remedy | Audit and limited staff roles |
| Loyalty | Account, earning, redemption and liability | Accuracy, fraud and deletion workflow |
| Direct marketing | Contact, permission, suppression and segment fields | PECR and direct-marketing governance |
| Analytics | Order and channel measures | Minimise identifiers and document aggregation |
Keep one identity model without forcing one identity
Customers may order as guests, use several emails or share a household number. Deduplication should not merge people merely because details look similar. Preserve source, confidence and conflict history, especially where marketing preferences differ.
Collect less, but record provenance
- Why the field is needed.
- Which system created it.
- Whether it came directly from the customer.
- Which location or channel it relates to.
- Who can edit it.
- How long it is retained.
- Whether it can be exported or deleted.
Build preference and suppression controls
Store email, SMS and push choices separately where required. Keep service-contact needs distinct. Apply objections and opt-outs across every marketing system and retain minimal suppression records so a later import does not reverse the preference.
Control access and suppliers
Use named accounts, role-based permissions, strong authentication and audit logs. Review agencies, app suppliers, email platforms and analytics services as part of the data flow. Remove access promptly when roles change.
Maintain quality and retention
Correct inaccurate details, remove obsolete data and review inactive records against documented retention periods. Avoid intrusive attempts to find new contact details. Export and restore data periodically so supplier lock-in does not become a continuity risk.
Prepare for rights and complaints
- Access and portable export where applicable.
- Correction of inaccurate records.
- Marketing objection and suppression.
- Consent withdrawal.
- Account and erasure requests.
- Data-protection complaint route.
- Incident and breach assessment.
Practical next step
Create a data map from checkout, marketplace, app, loyalty, POS, email and SMS systems. Mark owner, purpose, lawful route, retention, export and deletion for each data flow before creating new segments.
Run data-quality controls
Track duplicate rate, missing source, conflicting preferences, failed exports, unauthorised access and deletion backlog. Assign thresholds and owners. Quality should be measured as fitness for a defined purpose, not simply the number of populated fields.
Test supplier exit and recovery
Export customer, preference, suppression, loyalty and order-link data into documented formats. Restore a sample into a controlled environment or replacement tool. A backup that cannot recreate essential relationships is not a usable continuity control.
Use controlled segmentation
Every segment should have a documented purpose, input fields, owner, refresh schedule and exclusion logic. Avoid labels that imply facts the data does not support. Retire segments when the campaign ends and do not keep derived scores indefinitely without a continuing need.
Related guides
- Restaurant Marketing and Customer Retention — the main guide for the wider topic.
- Customer Data Consent for Restaurant Marketing — a detailed next step for putting this guidance into practice.
- Customer Segmentation for Takeaways — a detailed next step for putting this guidance into practice.
- Customer Acquisition — a closely related operational control to review alongside this page.
- Email Marketing for Takeaways — a closely related operational control to review alongside this page.
- Data Protection for Restaurant Customer Data — a connected decision that can change the recommended approach.
Sources and date checked
Guidance checked: 24 July 2026. Recheck current ICO, supplier and advertising guidance before acting.
