Опознайте всеки гост като редовен
Materialized RFM резултати, lifetime статистика, нормализирани тагове, append-only бележки, алергени и хранителни предпочитания, GDPR одит на съгласия, double opt-in и global delete с grace period — всичко вградено в платформата за поръчки. Без външен CDP, без допълнителен абонамент.
Какво е CRM за клиенти?
Всяка завършена поръчка обновява per-venue статистика на клиента — общо поръчки, общо изхарчено, средна стойност на поръчка, recency, frequency и композитен RFM сегмент (CHAMPION / LOYAL / POTENTIAL / NEW / AT_RISK / LOST / INACTIVE). Списъчната страница показва сегмента като оцветен badge, така че управителят да види редовните и загубените веднага.
Таговете са глобални за клиента (един VIP таг го следва във всеки обект, който управлявате). Бележките са per-venue и append-only — историята се запазва. Промените на съгласие се записват в одит лог с IP, user agent и автор — GDPR Article 7 готово.
Какво получавате
RFM сегменти автоматично
Recency, frequency, monetary scoring с percentile bucketing за обекти с 30+ клиенти и стабилни прагове за по-малки. Без външен инструмент.
Запазени сегменти за маркетинг + промо
Изградете групи клиенти чрез JSON criteria DSL — high-value champions, dormant клиенти, VIP-tagged opt-ins. Membership-ите се materialize нощно; маркетинг кампании и промо кодове ги targetват мигновено.
Тагове, бележки, алергени — всичко в едно досие
Нормализирани тагове (глобални за клиента), append-only бележки на ниво venue (с автор + timestamp) и структурирани предпочитания за алергени / диета. Любими и нехаресвани продукти се auto-derive-ват нощно от историята на поръчките. Предаванията на персонал спират да губят контекст.
Пълен GDPR toolbox
Append-only consent log (Article 7 evidence) с IP / user agent / автор за всеки flip. Optional double opt-in per venue за EU съответствие. Customer-initiated global delete със 7-дневен grace period; force-execute path за DPA orders.
Как работи
Поръчката завършва
Inline writer преизчислява per-venue статистиката на клиента. Евтино (един aggregate + един upsert).
Нощен cron балансира
Веднъж дневно в 03:30 UTC цялата venue cohort се re-percentile-bucketира, така че segment labels остават точни.
Маркетинг + промо четат мигновено
Запазените сегменти materializira-т membership в join таблица. Marketing campaign recipients и promo targeting получават мигновени lookups вместо full-table scans.
Audit trail хваща всеки flip на съгласие + оцелява изтриване
Checkout opt-in, admin toggle, клик върху unsubscribe link, double opt-in confirmation — всеки пише структуриран ред в CustomerConsentLog. Когато клиент поиска global изтриване, consent log-ът се запазва и финален REVOKED запис се добавя; самият личен запис се anonymise-ва in place след grace period-а, така че Order/Bill финансовата интегритет се запазва.
Възможности
Materialized customer stats
Per-(customer, venue) ред с totalOrders, totalSpent, AOV, firstOrderAt, lastOrderAt, daysSinceLastOrder, RFM scores 1-5 и композитен segment label.
- Inline updates при завършване на поръчка
- Нощен recompute през PM2-leader cron + external trigger
- Sub-millisecond reads — admin списък никога не сканира Order таблица
- Единствен източник на истина за AI Conversational Admin tools
Запазени сегменти с criteria DSL
JSON-driven criteria DSL — комбинирайте field/op/value predicates с all/any/not групи. Compile до Prisma where-fragment, materialize membership.
- 6 system сегмента seed-нати автоматично (legacy enum)
- Custom сегменти неограничени за всеки обект
- Member counts + last-computed timestamp видими наведнъж
- Manual recompute бутон за instant feedback след criteria edit
Тагове, бележки, алергени + хранителни предпочитания
Таговете са глобални за клиента; бележките са per-venue и append-only с автор + timestamp. Алергени / диетични / любими / нехаресвани продукти живеят в структурирана таблица — explicit записи от dossier-а плюс auto-derived favorites и dislikes от историята на поръчките с confidence score.
- До 50 тага на клиент (unique constraint), tag-based segment criteria (hasTag)
- Алергени + хранителни предпочитания се показват при поръчка и на kitchen ticket-а
- Любими + нехаресвани се auto-derive-ват нощно (топ 3 с ≥3 поръчки → favorite; поръчан веднъж + ≥5 пропуска → disliked)
- Бележките се пазят завинаги с пълна attribution на автор
GDPR toolbox — consent log + double opt-in + global delete
Append-only CustomerConsentLog (канал, action, source, IP, user agent, автор) е вашето Article 7 evidence. Per-venue Venue.requireDoubleOptIn включва EU-style double opt-in за маркетинг — confirmation token email се изпраща и consent flag-ът остава false докато клиентът не натисне. CustomerDeleteRequest schedule-ва global anonymisation със 7-дневен grace period; нощният cron изпълнява; ROLE_ADMIN може да force-execute за DPA orders.
- Записва EMAIL_MARKETING / SMS_MARKETING / WHATSAPP_MARKETING / REVIEW_REQUEST
- Double opt-in tokens имат 7-day TTL; idempotent — duplicates collapse
- Global delete anonymise-ва in place — Order/Bill FKs запазени за финансова интегритет
- Cron auto-executes pending deletes ежедневно; force-execute достъпно за DPA compliance
Изградено за тези workflow-и
Засечете редовните преди да си отидат
AT_RISK badge се появява 30 дни след последното посещение на редовен. Filter-нете списъка, изпратете winback кампания или нека управителят да им се обади — преди LOST badge на 90-ия ден.
Birthday кампании без spreadsheets
Customer.dateOfBirth + birthday cron вече shipped. Сдвойте със запазен сегмент за VIP клиенти и имейлът отива точно до правилните хора.
Multi-venue вериги, следящи същия клиент
Таговете са глобални; статистиката е per-venue. Lifetime Stats card в dossier-а показва cross-venue totals + per-venue breakdown.
Маркетинг кампании с materialized recipients
Съществуващият marketing/recipients flow вече чете от CustomerSegmentMembership. Recipient counts се връщат за милисекунди дори на venues с 100K+ клиенти.
GDPR data subject requests, end-to-end
Клиент пита 'кога се записах?' — pull CustomerConsentLog. Клиент иска изтриване — schedule global CustomerDeleteRequest със 7-дневен grace period и нощният cron anonymise-ва навсякъде; за DPA orders платформеният собственик force-execute-ва моментално. EU venues могат да изискват double opt-in за маркетинг — consent flag-ът остава false докато клиентът не натисне линка от имейла.
AI Conversational Admin на чисти данни
/admin/ask асистентът извиква customer-stats tools, които четат директно от CustomerVenueStats. Отговори като 'кои са топ 5 клиенти?' се връщат с числено-точни данни, не LLM hallucinations.
Защо вграден CRM бие външен CDP
Повечето ресторант SaaS ви насочват към външна customer data platform. За повечето независими ресторанти и малки вериги тези инструменти са overkill, скъпи и добавят оперативна сложност. CRM вграден в платформата за поръчки чете от authoritative bills + rounds данните и ви дава 80% от важното: сегменти, тагове, бележки, съгласия.
Защо materialized RFM бие on-the-fly compute
Изчисляването на RFM при всеки list-page load е бавно щом customer base мине 5,000. Materializing на score-а при order completion държи четенията евтини завинаги.
Защо таговете трябва да са глобални
VIP следва клиента. Ако е VIP в London venue-то ви и влезе в Sofia venue-то, той все още е VIP. Per-venue tag scoping създава несъответствия. Бележките са per-venue, защото са за специфично взаимодействие или сервизен проблем в конкретно място.
Защо audit log е незаменим
GDPR Article 7 изисква да докажете, че съгласие е дадено. Предишният 'last-write-wins' подход губи всяка предишна промяна. Append-only CustomerConsentLog хваща всеки flip с attribution.