TimeGuest
Ready for Service
Select a booking to view the guest intelligence brief.
Welcome to the central intelligence layer. Securely access live venue data, manage guest experiences, or review system architecture & compliance.
Four steps. Every visit. Invisible to the guest.
A reservation comes in through DinePlan or WhatsApp. GuestIQ automatically pulls the booking details and checks if this guest has visited before. If they’re new, a simple consent step captures their preferences. If they’re returning, their profile is already waiting.
Before service, every front-of-house team member sees a short, AI-generated brief for each guest arriving that day. It tells them what matters — preferred table, wine they loved last time, their anniversary is next week, they had a complaint two visits ago that was resolved. No digging through notes. It’s just there.
After the visit, staff type a quick note in plain English: “Loved the lamb, asked for the Cab Sav again, celebrating a promotion, sat at table 12 with four friends.” Claude reads that note and files everything into the right place automatically. No forms. No dropdowns. No training.
Next time that guest books, the cycle starts again — but now it’s richer. The system knows their favourite wine, their usual table, their birthday next month. The restaurant reaches out at the right moment with the right gesture, but only if the guest said that’s okay.
None of this works without the guest’s permission. South African law requires explicit consent before any preference tracking can begin — and rightly so. When a guest dines for the first time, they’re presented with a simple, friendly consent form on a tablet at the front desk. It takes under 30 seconds.
If they say yes, the system begins learning. If they decline, their name is stored for that visit only and automatically purged after 30 days. No pressure. No dark patterns. The guest is always in control.
The more guests who consent, the smarter the system becomes. At launch, intelligence will be limited — it grows naturally as returning guests opt in over the first 6–12 months. This is by design, not a flaw.
It’s invisible. Guests never see a system. Staff never fight with software. It just feels like the restaurant has an incredible memory.
GuestIQ is not a CRM. It is a private, AI-powered intelligence layer for a group of 4 venues. It solves the “Memory Loss” problem when staff leave and the “Silo Problem” between brands.
Gut Feel vs. Intelligence: Most restaurants rely on staff memory. GuestIQ creates permanent institutional intelligence that survives staff turnover.
Natural Input: Staff type natural notes. Claude AI structures it automatically. No forms, no dropdowns, no training required.
Cross-Venue: A guest known at one venue is no longer a stranger at another. Preferences and safety data travel with the guest.
Foundational Principle: The AI engine must never have access to personally identifiable information (PII). This is achieved via a strict Two-Database Split.
Claude AI reads exclusively from here
Guest data enters through four channels, passes through processing, then splits into two permanently separated databases.
Only information genuinely useful for improving future dining experiences. Data minimisation is enforced at the AI layer.
Subjective personality assessments are explicitly prohibited. Staff notes are limited to observable dining preferences and behaviour. No character judgements, no assumptions about lifestyle, religion (beyond dietary preference), or personal circumstances.
Claude AI powers the core intelligence. All API calls are server-side only. The AI reads exclusively from Database B — it never sees names, contact details, or any PII.
Staff type natural notes — AI structures into profile data automatically
Pre-service summaries for every guest arriving today
Birthday/anniversary detection with action recommendations
Personalised messages for manager review and approval
Loyalty, frequency, spend trends, and churn risk scoring
Track guest experience quality across visit history
Pattern analysis, flags overdue guests for follow-up
Unresolved issues surfaced when guest rebooks
AI-generated preference summary for other venues (no raw notes)
Gesture recommendations for guests with poor experiences
Intelligence transfer when preferred server leaves
Preference scores fade over time. Allergies never below 0.8
A preference confirmed last month scores 0.9. A preference from a year ago scores 0.1 (floored at 0.3). Allergies are the exception — they never drop below 0.8 because they are safety-critical.
When staff type a natural language note — e.g. “Mrs Johnson loved the Cabernet, asked for the corner booth, allergic to shellfish, here for anniversary” — the system strips the name via the PII stripping service. The sanitised note is sent to Claude with only the pseudonymous token. Claude structures it into categories: wine preference, seating preference, allergy (flagged for verification), and occasion. Each preference is stored with a confidence score that decays over time.
One guest, four venues. Preferences and safety data travel with the guest everywhere, but raw notes stay at the creating venue.
| Data Type | Visibility | Detail |
|---|---|---|
| Preferences | All Venues | Dietary, drink, seating, service style |
| Allergies | All Venues — Priority | Safety-critical — verified every visit |
| Special Dates | All Venues | Birthday, anniversary, celebration style |
| Visit History | Own Venue Full | Other venues see AI summary only |
| Staff Notes | Own Venue Only | Raw notes never cross venue boundaries |
| Complaints | Flagged Cross-Venue | Unresolved issues visible group-wide |
| Health Score | All Venues | Calculated at group level |
Three separate consent mechanisms under POPIA. Different processing purposes, cannot be bundled. Each timestamped and stored immutably.
Pre-filled from DinePlan where available
Plain language, POPIA Section 18(1) compliant, group disclosure
AI toggle (default OFF), email toggle (OFF), SMS/WhatsApp toggle (OFF)
Religious dietary toggle and medical allergy toggle (only if AI = YES)
Withdraw, access, correct, delete, object, complain to Information Regulator
Timestamp captured immutably
Walk-in guests are presented a minimal tablet form. Name is the only required field. Under 30 seconds. Guests who decline full consent have an automatic 30-day expiry. A daily cron job crypto-shreds expired walk-in records.
Defence in depth — seven distinct security layers. Security is the default, never optional, never retrofitted.
GCP Cape Town (africa-south1) • Zero cross-border transfer • South African jurisdiction
Every staff member has their own named Google account. No shared logins — ever. MFA mandatory. Instant revocation when staff leave.
Full system access • GCP management • All venues
Full cross-venue • All notes • All history
Own venue full • Cross-venue summary • Outreach approval
View profiles • Add notes • See phone/email
Designed for non-technical restaurant staff. Every interaction takes under 30 seconds. No complex forms, no dropdown menus, no training manuals.
Browser + Google account + MFA
Today’s reservations with AI briefs
Search name — full profile in seconds
Allergy alerts • VIP flags • Preferences visible
Type a natural note — AI structures it
Manager reviews occasions • Drafts outreach
Under 30 seconds from search to screen
South African law. Non-compliance carries fines up to R10 million or 10 years imprisonment. Every feature built with POPIA in mind from the start.
Designated Information Officer. Full compliance dashboard.
Data collected directly from guest. Lawfully, with consent.
Every data field has a documented purpose.
Data cannot be repurposed beyond stated use.
Records reviewed regularly. Guests can correct data.
Plain-language privacy notice at every capture point.
Encryption, IAP, audit logging. Access control.
Access, correction, deletion workflows built in.
Halaal/Kosher dietary requirements, allergy information, and health-related restrictions receive the highest encryption and most restricted access. Separate explicit consent required under Section 27(1)(a).
Five launch blockers must be resolved before any guest data is processed. No exceptions.
| ID | Blocker | POPIA |
|---|---|---|
| LB-1 | Information Officer registered with Information Regulator | S.55(2) |
| LB-2 | Written Operator Agreement signed (restaurant & UK developer) | S.21(1) |
| LB-3 | Consent form meets all 8 Section 18(1) requirements | S.18(1) |
| LB-4 | Separate explicit consent for special category data | S.27, S.32 |
| LB-5 | Deletion guarantees non-recoverability via crypto-shredding | S.14(5) |
| Stage | Phase | What Gets Built | Complexity |
|---|---|---|---|
| Stage 1: Foundations | |||
| 1A | Legal Foundations — IO registration | Low | |
| 1B | Operator Agreement — POPIA S.21 | Low | |
| 1C | Compliance Specifications | Medium | |
| Stage 2: Infrastructure | |||
| 2A | GCP Infrastructure + Database Schema | High | |
| 2B | Authentication + Google IAP | High | |
| 2C | Backend API — Node.js on Cloud Run | High | |
| Stage 3: Core Features | |||
| 3A | DinePlan Integration — live sync, dedup | High | |
| 3B | Frontend — profiles, dashboard, notes | High | |
| 3C | AI Intelligence Layer — Claude | High | |
| 3D | Consent + Walk-In Capture | Medium | |
| Stage 4: Compliance | |||
| 4A | Compliance Dashboard + Audit | Medium | |
| 4B | Guest Rights Workflows — SAR, correction, deletion | Medium | |
| 4C | Occasion Engine + Outreach | Medium | |
| Stage 5: Launch | |||
| 5A | Pre-Launch Verification Checklist | Low | |
A visual overview of every item standing between us and going live — compliance, cost, and risk.
This is the single most important action. They review the consent form, draft the operator agreement, and advise on cross-border access.
Check with the Information Regulator. If not registered, begin immediately.
With explicit POPIA S.72 cross-border provisions. Consider restricting UK access to infrastructure-only.
Accept partial intelligence at launch. Plan email/WhatsApp/on-arrival consent capture. Set realistic expectations: 6–12 months for meaningful coverage.
Mandatory human verification for all AI-detected allergies. Clear liability in the operator agreement.
R12,000–R14,000/month for the recommended setup. Confirm financial commitment before build begins.