#r06 — The CRM: guest identity, loyalty, marketing, privacy

Scope: guest CRM/loyalty/marketing layer of RestaurantBrain. The POS is treated here purely as the data-capture and redemption device. POS internals, payments, fiscalisation and hardware are covered in sibling docs; where a fiscal or payments constraint reshapes CRM design I call it out inline.

Bottom line: the CRM is the only part of this product that is defensible, and it is also the part where a small team can realistically out-build incumbents — but only because incumbents are weak at exactly two things: (1) loyalty that works correctly while the terminal is offline, and (2) holdout-based revenue attribution. Everything else in CRM is commodity. The CRM domain alone is ~55 engineer-months to a sellable v1. That number, combined with the POS build, is the single biggest argument against scenario S1 (bootstrapped) attempting both.

#1. Identity resolution

#1.1 The identifier inventory

Every identifier a restaurant can plausibly touch, with its real properties:

#1.2 Graph model, not a golden record

Store an identity graph, not a mutable "golden customer row":

guest_identity (id, kind, value_normalised, value_hash, first_seen, last_seen, source, tenant_id)
guest_edge     (id, identity_a, identity_b, rule_id, confidence, evidence_json, created_at,
                created_by, superseded_by, unmerged_at, unmerge_reason)
guest_cluster  (id, tenant_id, primary_identity, cluster_version, computed_at)
guest_profile  (guest_id -> cluster_id, display fields, consent snapshot ref)

Rules that follow from this shape and that most vendors get wrong:

• Merges must be reversible. A destructive merge of two guests is unrecoverable and the DSAR/erasure story becomes impossible ("delete me" from a wrongly-merged pair deletes a stranger's history). Merge = adding an edge; cluster membership is derived (union-find over edges above threshold) and recomputable.
• Cluster recompute must be deterministic and versioned, so a campaign audience is reproducible for audit ("who received this and why").
• Never inherit consent across a merge. Consent is attached to (identity, channel, purpose), not to the cluster. If phone A consented to SMS and email B did not consent to email, the merged guest is SMS-only. This is the #1 compliance bug in loyalty CDPs.

#1.3 Matching rules and confidence scoring

Deterministic tiers (auto-merge):

Probabilistic tiers (never auto-merge for marketing; may soft-link for analytics only):

Policy: score ≥ 0.90 → merge; 0.65–0.90 → review queue in the back office with a one-click merge/split; < 0.65 → separate. Expect 1–4 % of a mature base to sit in the review queue; if it exceeds 8 % your normalisation is broken (usually phone country codes or gmail aliasing).

Cost of getting it wrong is asymmetric and worth stating to the customer: a false merge shows guest A guest B's allergy notes and spend history — a reportable personal-data breach. A false split just splits points. Bias hard toward false splits, and give staff a manual merge tool with an audit trail.

#1.4 Household grouping

Households are a marketing convenience, never a legal identity.

• Signals: shared delivery address + different phones; same card PAR + different phones; repeated check-splitting between the same two guests; a "family" flag set explicitly in the app.
• Use it for: suppression (don't SMS both partners the same offer twice), CLV roll-up, family/kids campaigns.
• Do not use it for: showing one member another's transaction history, merging points balances without explicit action by both, or profiling one person from another's behaviour. A "family points pool" is a product feature requiring both parties to opt in, not an inference.

#1.5 The legal limits of card-token matching (read this twice)

Card-based identification is the highest-value and highest-risk mechanism.

1. Silent identification is unlawful in the EU. Fingerprinting a guest's card at the terminal and building a profile for a guest who never joined the programme has no workable lawful basis: not contract (no contract), not legitimate interest in practice (fails the balancing test — covert, unexpected, hard to object to), and Art. 14 transparency is unsatisfiable at a card terminal. [known]
2. The compliant pattern is pre-registration. The guest explicitly enrols a card ("link the card you usually pay with"), we store hash(PAR) or hash(PSP fingerprint) against their account, and thereafter a matching hash on a payment identifies them. That is consent-based (GDPR Art. 6(1)(a)), transparent, and revocable. Enrolment can happen in-app, in a post-visit SMS link, or via a customer-facing display flow.
3. PCI DSS scope. PAR itself is not account data and cannot be reverse-engineered to a PAN, and using it in place of PAN references can reduce PCI scope [verified]. But if you receive PAR by parsing an authorisation response inside your own app on the terminal, you are near the CDE and your assessor will care. Prefer PAR delivered by the PSP over a server-to-server webhook, out of band from the terminal.
4. Contractual limits. Acquirer and PSP agreements frequently restrict use of tokens/PAR to payment purposes, and PAR availability is inconsistent — some CEE acquirers do not surface it at all. Budget for a fallback per PSP. [estimate — must be confirmed per acquirer contract]
5. US: CPRA treats card-derived identifiers as personal information; a "financial incentive" notice is required if the loyalty discount is tied to that data (see 6.7).

Recommendation: ship card-linked identity in v1.1, not v1, gated behind explicit enrolment, with PAR-first and PSP-fingerprint fallback. Effort ~2.5 eng-months for two PSPs.

#2. Capture at the counter: the 4-second problem

The binding constraint is not software. It is that a cashier at a lunch rush will not spend more than ~3–5 seconds per transaction on anything that is not taking money, and will silently stop doing it within two weeks if it is not either (a) frictionless or (b) enforced by the order flow.

#2.1 Mechanism-by-mechanism, with honest capture rates

Capture rate = share of transactions that end with a usable, consented identifier. All figures [estimate] unless marked, drawn from patterns in retail/hospitality loyalty; treat as design inputs, not facts.

#2.2 Capture math a founder can quote

Take a 3-site coffee chain, 350 transactions/site/day, 1,050/day total, ~31,500/month.

The gap between row 1 and row 3 is the whole business case for owning the POS. Sell the POS as the CRM's capture device; do not sell the CRM as an add-on to someone else's POS — you will be capped at row 1.

#2.3 The consent/identity split (critical design decision)

Separate two things that every competitor conflates:

• Identity capture (getting a phone number to send a receipt) → lawful basis: contract/legitimate interest, ~4 seconds, ~25 % capture.
• Marketing consent (permission to send campaigns) → needs a real, evidenced, freely-given act, which cannot be done well at a busy counter.

Design: capture identity at the POS, then move the consent step to the guest's own device via the transactional SMS/email you just earned the right to send. "Here's your receipt. Tap to join Club — first coffee free." That link is where double opt-in, purpose granularity, and consent-text versioning happen — on a screen the guest controls, with a record we can defend. Expected join rate from a receipt SMS: 8–20 % [estimate].

#2.4 Wallet passes deserve their own line item

Apple PassKit + Google Wallet passes are underused by SMB restaurant CRMs and are cheap to build (~2 eng-months for both, including push updates via APNs pass updates and the Google Wallet REST API). Value: the pass updates its balance without an app; it can surface on the lock screen near the venue (relevance geofence, up to 10 locations per pass on iOS [known]); it survives phone changes; and it is the only "app-like" retention channel that does not require an app install. For SMB restaurants an actual native app is usually a waste — pass + web ordering beats a 2 %-install-rate app.

#3. Loyalty mechanics, and the offline constraint that defines the architecture

#3.1 Mechanic inventory

#3.2 Why offline is non-negotiable

A restaurant terminal loses connectivity: ISP outages, mobile-data dead zones in basements/courtyards, Wi-Fi contention at peak, router reboots by staff. Realistic per-terminal offline exposure: 5–90 minutes/month, p99 up to 4 hours [estimate]. During that window the POS must still take orders and take money — and if the loyalty layer fails open (everything free) or fails closed (nobody can redeem) you lose the account. Toast, Square and Lightspeed all degrade loyalty offline; incumbent loyalty specialists (Punchh, Paytronix, Como) are cloud-call-per-transaction and degrade worse because they sit behind a POS integration. This is the single most credible technical differentiator available to us.

#3.3 Signed offline-valid vouchers

Design:

Voucher token (CBOR/COSE_Sign1, Ed25519, ~140–200 bytes → QR or PDF417 on a wallet pass)
  vid    UUIDv7            voucher id (time-sortable → cheap expiry pruning)
  gid    guest id (opaque) 
  cid    campaign id
  val    {type: pct|abs|item|bogof, amount, currency, item_scope}
  scp    site/brand scope (bitmap or list)
  nbf    not-before  (epoch s)
  exp    not-after
  cnd    condition ref (rule bundle id + rule id)  // evaluated locally
  nonce  128-bit
  kid    signing key id

Terminal-side verification, in order:

1. Signature valid against a pinned public key set (JWKS-style, kid rotation; keys pushed with the menu bundle; terminal refuses tokens signed by keys it has never seen).
2. nbf/exp against a trusted clock: last successful server sync time + monotonic uptime. If now - last_sync > 72 h, refuse to redeem anything with an expiry inside the uncertainty window and warn the cashier. Staff do change terminal clocks.
3. Local spent-set: RocksDB/SQLite table of redeemed vids, plus a Bloom filter of recently-spent ids gossiped over the site LAN (mDNS peer discovery, ~1 KB/min) so two terminals in the same room cannot both burn the same voucher while the site is offline.
4. Condition evaluation via the portable rules evaluator (§3.6).
5. Mark spent locally with an idempotency key, apply the discount before fiscalisation (§3.7), enqueue for upload.

Residual risk: cross-site double spend while both sites are offline. Bound it, don't try to eliminate it.

Expected annual loss ≈ vouchers_issued × P(redeemed) × P(both sites offline simultaneously) × P(guest attempts fraud) × face_value

With 500k vouchers/yr, 12 % redemption, 0.3 % simultaneous-offline, 2 % fraud attempt, EUR 4 face value → ~EUR 14/year. It is a rounding error. Say this out loud in the sales deck; competitors handwave it and lose deals to "what if the internet goes down".

#3.4 Balance float for points/cashback/gift cards

Points and money balances cannot be signed into a token because they change. Use an escrow/float model, not a CRDT counter (a naive PN-Counter permits unbounded overdraw and cannot express "spend at most what you have"):

• Server grants each terminal (or site) a reservation: offline_allowance = min(balance, tier_cap) where tier_cap defaults to EUR 20 / 2,000 points, configurable per brand.
• The reservation carries a lease (expires_at, typically 24–72 h) and a monotonically increasing lease_seq.
• Reservations are refreshed on every online lookup of that guest — so the common case (guest visits their home site regularly, site is online 99.5 % of the time) always has a fresh float.
• On reconnect, the terminal replays burn events with idempotency keys; server applies them to the append-only ledger.
• Ledger of record: append-only loyalty_event(id, guest_id, type[earn|burn|adjust|expire|void], amount, currency_or_unit, source_terminal, check_id, idempotency_key, occurred_at, recorded_at, prev_hash). Balances are materialised views, never the source of truth. Hash-chaining prev_hash per guest gives cheap tamper evidence — useful for franchise disputes and for the "is my franchisee stealing points?" question.

Overdraw reconciliation policy (must be a per-brand setting, not a hardcoded behaviour):

Gift cards are different: never allow offline redemption above a hard cap (EUR 10–20) and never allow offline balance top-up. Gift-card fraud is organised and cheap.

#3.5 Regulatory landmines in stored value

• E-money licensing (EU): closed-loop, single-brand gift cards fall under the "limited network" exclusion of Directive 2009/110/EC Art. 3(k) [known]. The moment you operate a shared wallet across unaffiliated restaurants (the network effect everyone wants), you risk being an e-money issuer or a payment institution. There are national notification thresholds for limited-network operators under PSD2 Art. 37(2) (commonly cited as EUR 1 m/12 months of transactions) [known — confirm per NCA]. Design implication: v1 wallets must be per-brand, not cross-brand.
• US: CARD Act 2009 — gift-card funds cannot expire for 5 years [known]; state escheat/unclaimed-property law varies wildly (some states claim unredeemed balances). Do not ship US gift cards without counsel.
• UA: stored value and "certificates" sit under NBU payment services rules; get local counsel before shipping gift cards in Ukraine. [estimate]

#3.6 The promo/discount rules engine (the most underestimated component)

Requirements that make this hard:

1. Bit-identical evaluation on server (Go/TS/Kotlin) and terminal (Swift/Kotlin/TS). Two implementations will diverge; you will find out from a customer.
2. Deterministic, bounded evaluation — no unbounded loops on a EUR 200 Android terminal during a lunch rush. Budget ≤ 15 ms per check recompute.
3. Stacking is combinatorial. "Best deal for the guest" over N stackable promos is a knapsack-flavoured problem. Do not promise a global optimum. Ship: exclusivity groups + explicit priority + a bounded search over at most K=6 candidate combinations, and document that behaviour in the UI ("applied: 2 of 3 eligible offers").

Recommended shape: a declarative rule DSL authored in the back office, compiled server-side to a portable bytecode/AST (CEL-like or a restricted JSON-Logic) and shipped in a signed rule bundle alongside the menu. One evaluator implementation compiled to each platform (a Rust core with FFI/WASM bindings is the honest answer if you want one implementation; a hand-written interpreter in each language is faster to start and where the bugs live). Add a golden-test corpus of 500+ (cart, rules) → expected-discount fixtures run in CI against every platform build. Without that corpus this component will eat 2 extra engineer-months in production bugs.

Rule vocabulary v1: cart total thresholds, item/category quantity, time-of-day/day-of-week, site scope, channel (dine-in/takeaway/delivery), guest tier, first-visit, nth-visit, birthday window, voucher present, max uses per guest/per day/global, exclusivity group, "cheapest item free", "bundle price".

#3.7 The fiscal constraint that CEE founders discover too late

In Poland (kasy online), Ukraine (RRO/PRRO), Romania (AMEF), and other fiscalised markets, the discount must be present in the fiscal receipt at the moment it is issued. Consequences:

• Loyalty must be applied before the check is fiscalised — so identity capture must happen at order time or at payment time, not after.
• "Scan your receipt afterwards to claim points" works for earning but not for discounting.
• Post-hoc goodwill credits must be issued as a new voucher for the next visit, never as a retroactive adjustment of a closed fiscal document.
• Voids/refunds of loyalty-discounted checks need a matching loyalty reversal event tied to the fiscal correction document.

This is a hard architectural constraint. It also means "reward points redeemed" must map cleanly onto a discount line the fiscal printer accepts, with correct VAT treatment (a points redemption reducing the taxable base vs. a free item at 0 price have different VAT consequences — get a tax opinion per market; in several jurisdictions a "free" item is a supply requiring VAT on cost). [estimate — this is a genuine open legal question, flagged in §Open questions]

#4. Marketing: segmentation, automation, and the one feature that sells the product

#4.1 Segmentation and scoring

• Segment engine: a query builder over a columnar store (ClickHouse recommended — 500 venues × 1,000 checks/day = ~180 M rows/yr, trivial for a single 16-core node). Segments are stored as ASTs, materialised on a schedule + evaluated live for small audiences. Support both "static list snapshot" (needed for audit/campaign reproducibility) and "live segment" (needed for automation entry).
• RFM with venue-relative windows. A fixed "lapsed = 90 days" is wrong: a coffee shop's daily regular is lapsed at 10 days; a fine-dining guest is not lapsed at 120 days. Fit per-venue (and per-guest where n≥4) inter-visit interval distributions and define lapse as exceeding p80 of the guest's own interval, falling back to venue p80. This is a two-day statistics job that makes every winback flow 2–3× better.
• CLV: BG/NBD + Gamma-Gamma (standard non-contractual BTYD models) are appropriate and cheap to fit. Be honest with customers: they are junk with <6 months of history or <500 repeat guests. For the first year, ship "trailing 12-month spend + predicted 90-day retention" and label it as such.
• Useful derived attributes that competitors mostly lack because they don't own the POS: preferred daypart, preferred site, average party size, dine-in vs takeaway ratio, item affinity (top 5 SKUs), discount sensitivity (share of visits with a promo), price-tier drift, allergen/dietary inference from repeated item choices (careful: dietary choices can imply religion or health → Art. 9 special category. Do not build "halal/kosher/vegan" audiences from purchase inference. Only from explicitly self-declared preferences.)

#4.2 Channels: real costs

Cost-per-incremental-visit sanity check (coffee chain, PL): 20,000-member base, SMS to the 6,000 lapsed at EUR 0.042 = EUR 252. Offer: free pastry (COGS EUR 0.55). If holdout-measured incremental visits = 3.5 % of treated (210 visits) at EUR 6.80 average check and 68 % gross margin → EUR 971 gross profit − EUR 252 send − EUR 116 pastry COGS = EUR 603 net, 2.4× ROI. That arithmetic, computed automatically and shown per campaign, is the product.

#4.3 Automation flows (ship these six, in this order)

Guardrails that must be in the engine, not in a runbook: global frequency cap (default max 4 marketing messages/guest/month), quiet hours per locale (marketing SMS at 07:00 is a complaint generator; several jurisdictions restrict marketing calls/messages by hour — treat 21:00–09:00 local as forbidden by default), channel-priority fallback (push → wallet → email → SMS, cheapest capable channel first), and per-campaign spend caps in EUR.

#4.4 Closed-loop attribution: the mechanism (the killer feature)

Everyone claims "closed-loop attribution" and means "we counted coupon redemptions". Coupon counts overstate value massively — most redeemers would have visited anyway. The real mechanism, which is only possible because we own the POS:

1. Randomised holdout at audience-build time. When a campaign audience is materialised, deterministically assign bucket = hash(guest_id || campaign_id) mod 100; buckets 0–9 = holdout (configurable 5–20 %). Stratify by RFM decile and home site so treatment and control are balanced.
2. Freeze the audience (static snapshot rows: campaign_audience(campaign_id, guest_id, variant, bucket, rfm_decile, site_id, assigned_at)). Reproducible for audit and for DSAR ("why did I get this?").
3. Attribution window, default 14 days (configurable; 7 for coffee, 30 for fine dining).
4. Outcome = POS revenue, joined on guest_id from checks, not from clicks. Compute per-guest: visits, gross revenue, discount cost, gross margin (needs recipe costing — even a crude category-level margin table works).
5. Incremental revenue = (mean_margin_treated − mean_margin_holdout) × n_treated. Report with a bootstrapped 95 % CI and the net number after channel cost and discount cost.
6. Power check, shown in the UI before send. With a 6,000-person audience, 10 % holdout, typical per-guest spend variance in a coffee concept, you can detect roughly an 8–12 % relative lift [estimate — needs calibration on real variance]. Below ~1,500 treated guests, most campaigns are statistically undetectable. Say this in the product. "This campaign is too small to measure; we'll pool it with the next 3 sends into a rolling estimate" is a trust-building message, and no competitor ships it.
7. Rolling program-level incrementality: maintain a permanent 3–5 % global holdout that receives no marketing, to measure the whole programme's lift, not just individual campaigns. This is what lets you answer "is your loyalty programme worth its subscription fee?" with a number — the single strongest renewal argument in the category.

Engineering note: attribution joins must be resilient to late-arriving offline checks (a check from an offline terminal may land 4 hours late). Recompute attribution on a rolling 48-hour lag; never report final numbers before window_end + 48 h.

#4.5 A/B testing

Deterministic bucketing on hash(guest_id || experiment_id), minimum 2 variants + holdout, sequential-testing guardrail (don't let users peek and stop early — either fix the sample size up front or implement an always-valid sequential test). Test copy, offer value, send time, and channel. The highest-value experiments are offer value (does EUR 2 off beat a free pastry?) and send time — both trivially automatable and both worth real money to the customer.

#5. Reservations, guest profiles, feedback, reviews

#5.1 Reservations / waitlist / table management

This is a big, separate product (SevenRooms, OpenTable, TheFork, Resy) and a full build is ~6 eng-months on its own. Components: floor-plan editor, shift/service definitions, pacing rules (covers-per-15-min caps), table-combination logic, walk-in waitlist with SMS "your table is ready", no-show tracking and deposits (Stripe/Adyen holds), channel ingestion (own widget, Google "Reserve with Google", TheFork).

Recommendation: do not build this for v1. It is only needed for full-service, it competes with entrenched marketplaces that also send inbound demand (which we cannot), and it will not close a deal on its own. Build a minimal waitlist + walk-in SMS (≈1.5 eng-months) which is what most casual venues actually want, and integrate rather than replace for real reservations. Revisit if the ICP shifts to full-service/fine dining.

#5.2 Guest profile at the point of service

Cheap and disproportionately loved by full-service operators: notes, allergies, preferences (favourite table, wine, "always sparkling water"), VIP flag, lifetime spend, last 5 visits, last 5 items, open complaints. Must surface on the POS/handheld within 1 tap of the check and in the reservation view.

Privacy note: allergy and dietary data is health data (GDPR Art. 9) when it describes a medical allergy. Lawful basis: explicit consent (Art. 9(2)(a)) captured from the guest, or vital-interest arguments that you should not rely on. Practical design: allergy notes are (a) explicitly entered by the guest or with their verbal agreement recorded by staff, (b) shown only to staff on shift at that venue, (c) excluded from analytics and from all marketing segmentation, (d) short-retained (e.g. 24 months from last visit), (e) never exported to an ESP. This must be enforced in the schema (separate table, separate access role, tagged special_category=true, blocked from segment builder), not in a policy PDF.

#5.3 Feedback / NPS and service recovery

• Trigger a 1-question survey (NPS or 1–5 stars) 2 hours post-visit via the channel we already have. Expect 3–10 % response [estimate].
• Route detractors to a human, not a page. Score ≤ 6 → immediate task to the site manager with the check, items, server, and time; SLA timer; a "make it right" action that issues a signed voucher (§3.3) redeemable offline on the next visit. This closed service-recovery loop is genuinely valuable and cheap (~1 eng-month once the voucher and task primitives exist).
• Route promoters to a public review with a one-tap link. Do not gate: selectively soliciting reviews only from happy guests violates Google's and TripAdvisor's policies and, in the EU, the Unfair Commercial Practices Directive as amended by the Omnibus Directive (fake/selectively-solicited reviews) [known]. Solicit from everyone; just handle detractors privately first. This is a compliance point competitors get wrong and you can attack.

#5.4 Review management

• Google Business Profile API: read reviews, reply to reviews, manage locations. Access requires being allowlisted for the Business Profile APIs — the approval process is slow (weeks) and non-trivial for a new vendor [known]. Start this application in month 1 of the project; it is a long-pole item with no engineering fix.
• TripAdvisor: partner-gated content API, paid, restrictive; realistically out of reach for a small vendor in year 1 [known].
• Yelp / Facebook: Yelp Fusion is restricted for review content; Facebook Page reviews via Graph API require permissions review [known].
• Verdict: ship Google-only review inbox + AI-drafted replies (a legitimately good use of an LLM: draft a reply in brand voice, human approves). ~2 eng-months. Defer everything else.

#6. Privacy and consent — the part that is genuinely hard

#6.1 Who is the controller? (decide this before writing schema)

Recommendation: build A, with the schema partitioned so B is addable. Concretely: guest rows are tenant-scoped; a nullable network_identity_id column can later link them when (and only when) the guest opts in to the network. Do not silently share guest data across tenants — several EU DPAs would treat that as an unlawful disclosure, and it is also a commercial betrayal that will surface in a chain's security review.

#6.2 Lawful basis, per processing purpose

Also: Art. 30 records of processing, Art. 35 DPIA — a loyalty programme doing systematic profiling of guests at scale is a plausible DPIA trigger; budget one DPIA template + per-market review (~EUR 3,000–8,000 external counsel per major market [estimate]).

#6.3 The "loyalty discount vs. freely given consent" problem

GDPR Art. 7(4): consent is not freely given if performance of a contract is conditional on consent to processing not necessary for that contract.

The clean structure:

1. Layer 1 — join the programme = a contract. You get points and member prices. Basis: Art. 6(1)(b). This is allowed to be conditional; the discount is the consideration for the contract, not for consent.
2. Layer 2 — marketing consent = separate, optional, unbundled. Per channel (email / SMS / WhatsApp / push), per purpose (offers / newsletter / profiling). The member discount must not depend on ticking these. If it does, several EU DPAs (DE, NL, AT notably) will call the consent invalid, which retroactively invalidates every campaign you sent.
3. Layer 3 — profiling. Optional, separately consented, clearly explained ("we look at what you buy to pick your offers").

A member who ticks nothing still gets points and still gets transactional messages (receipts, "your points expire in 14 days" is arguably transactional/contractual, but a DPA may see it as marketing — draft it neutrally and keep it factual, no offers inside).

Art. 22 (automated decisions with legal or similarly significant effects): tier-based pricing is probably not "similarly significant", but if you build dynamic per-guest pricing, it very plausibly is. Flag before building personalised prices.

#6.4 Delivery-platform data

Glovo, Wolt, Bolt Food, Uber Eats, Deliveroo are controllers of their customer data. What they pass to the restaurant (first name, masked phone, address for delivery) is provided for order fulfilment. Using it to build a marketing profile is (a) usually contractually prohibited, (b) hard to justify under GDPR without a notice the guest never saw. Design rule: delivery orders create a separate, marketing-suppressed guest record, linked into the cluster only for analytics (spend, frequency), never as a marketing target — unless the guest independently joins with the same phone. Build the suppression flag into the segment engine so it cannot be bypassed by a clever query.

#6.5 Capturing consent at a POS terminal (hard, and mostly solved by not doing it there)

Ranked by defensibility:

Records of consent schema (this is what a regulator asks for, and what almost no SMB vendor can produce):

consent_record(
  id, tenant_id, guest_identity_id, purpose_key, channel,
  state ENUM(granted, withdrawn, expired, pending_confirm),
  policy_text_id,            -- FK to the exact version shown
  policy_text_sha256,        -- immutable hash of the wording
  locale, ui_surface,        -- 'sms_link' | 'qr_web' | 'cfd' | 'kiosk' | 'app'
  captured_at, confirmed_at, -- double opt-in confirm
  evidence JSONB,            -- ip, user_agent, terminal_id, staff_id, message_sid
  withdrawn_at, withdrawal_source,
  prev_record_id             -- full history chain, never overwrite
)
consent_policy_text(id, tenant_id, purpose_key, locale, body, sha256, effective_from)

Key rules: append-only (never UPDATE a consent row), store the hash of the exact wording shown, keep withdrawal proof as carefully as grant proof, and make every outbound message check consent at send time (not at audience-build time — a 4-hour-old audience can contain someone who unsubscribed 3 hours ago).

#6.6 DSAR, erasure, and the offline-device problem

This is the requirement that quietly dictates your sync architecture.

An erasure request must reach: primary DB, read replicas, the analytics warehouse, search indexes, the campaign/queue system, the ESP/SMS provider, the app's local caches, and every POS terminal that has a cached guest lookup, a cached float reservation, or a queued offline event. Terminals may be powered off for weeks.

Mechanism:

1. Tombstones over the same sync channel as everything else. erasure_order(guest_id, tenant_id, issued_at, scope, deadline) is a first-class replicated object. Terminals apply it on receipt and acknowledge; the server tracks per-device ack.
2. Device inventory + staleness SLA. Any device that has not synced in > 30 days is flagged; on next connect it must apply the pending tombstone log before it is allowed to serve loyalty lookups. Devices offline > 90 days are treated as lost: revoke their credentials, and their encrypted local store becomes unreadable (per-device data keys, revocable server-side — this is the only real answer to "the tablet is in a drawer and I can't erase it").
3. Erase vs. pseudonymise. Transaction rows survive erasure (Art. 17(3)(b), tax law). Implementation: null the guest_id FK, replace with an unlinkable tombstone id, delete the identity rows and the profile. Keep an erasure_log(request_id, tenant, hashed_subject, issued_at, completed_at, systems_acked) for accountability without keeping the person.
4. Suppression lists survive. You must keep a hashed record of "do not contact this address" — deleting it means the person gets marketed to again. Document this in the privacy notice; it is a legitimate-interest/legal-obligation retention.
5. Backups. Standard, defensible position: backups are excluded from immediate erasure, purged by rotation within N days (make N ≤ 35), erasure is re-applied if a backup is ever restored. Write it in the DPA.
6. Access/portability (Art. 15/20): generate a JSON + CSV export: profile, consents (with wording), loyalty ledger, transaction summary, campaign sends and why the guest was targeted (segment name + rule). Target 1-click, ≤ 30 days, realistically ≤ 24 h automated.
7. Multi-tenant subtlety: if the same person is a member of 12 brands on our platform, an erasure request to Brand A must not touch Brands B–L. Erasure is tenant-scoped. Our own consumer-facing UI (if model B) must make that explicit.

Estimated effort for a credible DSAR/erasure implementation including offline propagation: 3 engineer-months. It is not optional for EU sales; enterprise chain procurement will ask for it in the security questionnaire.

#6.7 US: CCPA/CPRA

• Loyalty programmes are explicitly addressed: you may offer a "financial incentive" (a discount for data) but must give a notice of financial incentive including a good-faith estimate of the value of the consumer's data and the method used to calculate it (Cal. Civ. Code §1798.125(b)) [known]. The California AG ran an enforcement sweep specifically on loyalty programmes in January 2022 [known]. Almost nobody complies with the valuation-methodology part; a compliant, templated version is a genuine selling point to US chains.
• Uploading a customer list to Meta/Google for advertising is a "sale" or "share" under CPRA → requires a "Do Not Sell or Share My Personal Information" link and honoring Global Privacy Control signals [known]. Sephora's $1.2 M settlement (2022) turned on exactly this [known].
• Plus state-by-state proliferation (VA, CO, CT, TX, OR, and more), each with slightly different opt-out and sensitive-data rules. Cost of US privacy compliance for a small EU vendor: EUR 25,000–60,000 in counsel + ~2 eng-months of product work [estimate]. Combined with TCPA exposure on SMS (47 U.S.C. §227, statutory damages $500–$1,500 per message, and a mature plaintiffs' bar) [known], the US is a bad first market for a 4-person team.

#6.8 Market compliance cost, ranked

Note: the ePrivacy Regulation proposal was withdrawn by the Commission (2025 work programme) [known], so national fragmentation is permanent for the foreseeable future. Budget per-country marketing-consent logic as a permanent product feature, not a one-off.

#7. Build vs. buy for the plumbing

What must be ours, in one line: the identity graph, the loyalty ledger, the offline redemption protocol, the rules engine, the consent record, and the incrementality/attribution engine. Everything else is rentable.

#8. Competitive reality

The gap we can occupy: POS-owned, offline-correct loyalty with holdout-based revenue attribution, priced at SMB/small-chain levels (EUR 39–99/site/month for CRM on top of the POS), in CEE languages, with credible EU privacy tooling. Nobody currently sits at that intersection. The nearest threat is Syrve/iiko extending its marketing module, and Toast/Lightspeed entering CEE.

#9. Sequencing recommendation

Honest constraint for S1 (bootstrapped, 3.5 effective engineers): 55 eng-months for CRM v1 alone = ~16 calendar months, on top of a POS build that is at least as large. S1 cannot deliver both in 24 months. The only S1-viable paths are (a) CRM-first on top of someone else's POS (accepting the ~24 % capture ceiling from §2.2 and a fragile integration dependency), or (b) a radically narrower POS (single-concept, e.g. coffee/QSR counter-service only, one payment provider, one fiscal market) so the combined scope fits. Say this to the owner plainly.

#Build effort

Engineer-months for the CRM/loyalty/marketing/privacy domain only. Assumes a competent full-stack team with AI-assisted development (which helps 25–35 % on CRUD/UI/adapters and **0–10 % on distributed-systems correctness, rules-engine parity, and legal design** — do not discount those rows).

Calendar translation: S1 (3.5 effective engineers) → ~16 months for v1 CRM alone. S2 (8 engineers on this domain) → ~7 months, and S2 can parallelise items 5, 6, 9 and 13 which are the critical path.

#Open questions / what would change this answer

1. Do we own the POS, or not? If we ship CRM on someone else's POS, capture drops from ~52 % to ~24 % of transactions (§2.2), offline redemption becomes impossible to guarantee, and the entire differentiation collapses. This is the load-bearing assumption of the whole document. Would change: everything.
2. Controller model A vs. B. A cross-brand consumer wallet is worth a great deal commercially (guest acquisition for tenants) and costs a whole extra legal posture plus consumer-facing brand. Deciding this after v1 ships is expensive; deciding the schema for it now is cheap. Resolve in month 1.
3. VAT treatment of points redemptions and "free item" rewards in PL/UA/CZ/RO. I have flagged this as a genuine risk (§3.7) and cannot resolve it from training data. A wrong answer here means every fiscal receipt we print is wrong. Needs a tax opinion per market before the loyalty ledger design is frozen — EUR 3–6 k each [estimate].
4. Does our target acquirer/PSP surface PAR in CEE? If PAR is unavailable, card-linked identity degrades to PSP-scoped fingerprints, which break on PSP change and don't unify Apple Pay with the physical card. Confirm with the chosen PSP before promising card-linked recognition.
5. Is SMB single-site actually a viable CRM buyer? A 40-member/month café takes 18+ months to reach audiences where campaign measurement is meaningful (§4.4 power analysis). The CRM's value may only be real at 2–20 sites. If true, the ICP shifts to small chains, which changes pricing, sales motion, and the priority of franchise hierarchy features (item 19).
6. Google Business Profile API access. Approval is slow and discretionary; if refused, review management is a manual-paste feature. Apply in month 1; it is a calendar risk with no engineering workaround.