SnappTable یک پلتفرم B2B2C است: مهمان مکان را کشف میکند و میز رزرو میکند، رستوران سالن و ظرفیتش را اداره میکند، و تیم پلتفرم کیفیت عرضه، پشتیبانی، مالی و ریسک را کنترل میکند. یک منبع حقیقت برای موجودی و وضعیت رزرو — بدون پنل موازی.
رستورانها با دفتر رزرو و تماس پیش میروند؛ مهمان ظرفیت واقعی را نمیبیند و مالک نمیتواند بفهمد کدام میز خالی مانده. SnappTable فقط «فرم رزرو» نیست؛ دادهٔ موجودی، عملیات میزبان، ارتباط با مهمان، سیاست، پرداخت، CRM و گزارش را یکپارچه میکند.
| وضعیت سنتی | هزینهٔ کسبوکار | پاسخ SnappTable | شاخص سنجش |
|---|---|---|---|
| تماس یا پیام برای رزرو | پاسخ کند، خطای انسانی، نبود رد قابل پیگیری | اسلات واقعی، رسید، اعلان و تایملاین | search-to-book |
| دفتر رزرو و اکسل | رزرو تکراری، صف مبهم، بهرهوری پایین | تقویم، نگهداری ظرفیت، نقشهٔ سالن و waitlist | نرخ خطای رزرو / زمان تا نشستن |
| ظرفیت بدون داده | میز خالی و no-show | بهرهوری، سیاست، یادآوری و ودیعهٔ اختیاری | نفرِ نشسته / نرخ no-show |
| CRM پراکنده | بازگشت مشتری نامشخص | رضایت، بخشبندی، کمپین و سنجش منشأ | نرخ بازگشت / بازده کمپین |
| عملیات مالی دستی | اختلاف و تسویهٔ کند | دفتر کل، بازپرداخت، تطبیق و حسابرسی | SLA / مغایرت |
ابتدا ابزار عملیاتی و موجودی دقیق ساخته میشود، بعد بازارگاه در سلولهای متراکم فعال میشود. این ترتیب، ریسک نقدشوندگی و پرداخت برای تقاضای اثباتنشده را حذف میکند.
تهران، دو محلهٔ متراکم، ۳۰ تا ۵۰ مکان منتخب و فقط دستههایی که بازهٔ خدمت (service period) روشن دارند. توسعهٔ شهر فقط پس از عبور از گیتهای داده مجاز است.
سفارش غذا، پیک، حسابداری POS، رزرو هتل و قیمتگذاری پویا بیرون از نسخهٔ اولاند؛ نقطهٔ اتصال دارند ولی به هستهٔ رزرو تزریق نمیشوند.
هر سطح صفحات و stateهای خودش را دارد: حالت بارگذاری، خالی، بدون مجوز، خطای قابل بازیابی، آفلاین یا قطعهای، موفقیت، تأیید عملیات مخرب و شکستهای responsive موبایل/تبلت/دسکتاپ.
برابری با قابلیتهای شناختهشدهٔ بازار رزرو هدف است؛ تمایز، جایی است که این محصول از یک رزروبوک ساده جدا میشود.
سیاست ودیعه و لغو در سطح شعبه، بازهٔ زمانی و نوع مهمان تعریف میشود و پیش از نگهداری ظرفیت، شفاف به کاربر نشان داده میشود. ودیعه پیشفرض همهٔ رزروها نیست.
میزبان آخرین دفتر رزرو رمزنگاریشده/کششده را میبیند و تغییرات صفدار با حل تعارض به سرور بازمیگردد. عملیات مالی هرگز بهصورت آفلاین قطعی نمیشود.
هر اسلات با ظرفیت، rule مؤثر و دلیل عدم دسترسی مشخص میشود. هر override فقط با مجوز، دلیل ثبتشده و رکورد حسابرسی ممکن است.
رضایت، مدت نگهداری داده، درخواست خروجی/حذف و کمینهسازی دادهٔ حساس از روز اول بخشی از محصولاند، نه یک وصلهٔ انطباق.
نقش، قیمت، سیاست و گزارش میتواند در سطح سازمان یا شعبه تعریف شود و دادهها بهصورت tenant-isolated نگهداری میشوند.
تاریخچه، اختلاف و بازپرداخت به تایملاین واحد رزرو متصلاند، نه به یادداشتهای پراکنده در چند ابزار.
رزرو، موجودی، پرداخت و اعلان تراکنشهای وابستهاند؛ بنابراین در نسخهٔ اول یک Modular Monolith با مرزهای دامنهٔ صریح انتخاب شده و خروجیهای دامنه از طریق outbox منتشر میشوند تا تفکیک سرویس در آینده ممکن باشد.
| تهدید | کنترل | اثبات |
|---|---|---|
| رزرو تکراری / رقابت ظرفیت | نسخهٔ رکورد + hold تراکنشی + idempotency | تست ۱۰۰ درخواست همزمان |
| خواندن/نوشتن بینسازمانی | مخزن و policy محدود به tenant | تست منفی جداسازی |
| بازپخش پرداخت | callback امضاشده، شناسهٔ یکتای رویداد، دفتر کل | تست callback تکراری |
| سوءاستفاده حساب و انباشت رزرو | محدودیت نرخ، TTL نگهداری، سیگنال بات | شبیهسازی سوءاستفاده |
| نشت دادهٔ شخصی در CRM | کمینهسازی، رضایت، نگهداری، رمزنگاری فیلد، حسابرسی دسترسی | ارزیابی اثر + تست حسابرسی |
| شکست پیامک | outbox، retry محدود، پیگیری وضعیت، جایگزین درونبرنامهای | تست قطع وابستگی |
| نشت اطلاعات حساس در لاگ | فهرست مجاز redaction، بدون استثنای متن آزاد | تست لاگ PII و secret |
draft → pending_hold → pending_payment? → confirmed confirmed → checked_in → seated → completed confirmed → cancelled | no_show | expired pending_payment → payment_failed | expired | confirmed waitlisted → offered → accepted → pending_hold | declined | expired
پاسخها با پاکت ثابت پروژه برمیگردند: وضعیت، داده، پیام خطای امن و context؛ فهرستها باید total، شمارهٔ صفحه، اندازهٔ صفحه و وضعیت صفحهبندی را در ریشه داشته باشند. طبقهبندی خطا از اعتبارسنجی (۴۰۰) تا احراز هویت (۴۰۱)، مجوز (۴۰۳)، عدم وجود (۴۰۴)، تعارض موجودی (۴۰۹)، محدودیت نرخ (۴۲۹) و وابستگی/وقفه (۵۰۳/۵۰۴).
پیام خطا هرگز شامل stack trace، پاسخ provider، توکن یا دادهٔ شخصی نیست و همیشن correlation دارد.
دو منبع درآمد مستقل: اشتراک ماهانهٔ نرمافزار برای عملیات، و کارمزد بهازای هر نفرِ نشستهٔ جذبشده از بازارگاه. قرارداد چندشعبهای مسیر سوم است. همهٔ ارقام به تومان و در سناریوی پایه هستند.
| جریان | تعریف | قیمت / فرض | اعتبارسنجی لازم |
|---|---|---|---|
| پایلوت | فعالسازی و آموزش ۹۰ روزه | ۰ | نرخ فعالسازی و NPS مکان |
| Core SaaS | رزرو مستقیم و عملیات پایه | ۳٫۹ میلیون / ماه | تمایل به پرداخت |
| Growth SaaS | CRM، کمپین، تحلیل و جذب تقاضا | ۷٫۹ میلیون / ماه | تبدیل پایلوت به پولی |
| کارمزد بازارگاه | هر نفرِ نشستهٔ جذبشده | ۳۵ هزار | نسبتدهی و تطبیق |
| Group | چندشعبه و یکپارچهسازی | قراردادی | مسیر فروش سازمانی |
| افزونه | پیام، یکپارچهسازی، تحلیل پیشرفته | پس از اثبات ارزش | نرخ اتصال |
| شاخص | محاسبه | نتیجه |
|---|---|---|
| مشارکت هر نفر نشسته | ۳۵٬۰۰۰ منهای ۷٬۰۰۰ هزینهٔ متغیر | ۲۸٬۰۰۰ |
| مشارکت Core ماهانه | ۳٫۹ میلیون منهای ۰٫۳۵ میلیون | ۳٫۵۵ میلیون |
| مشارکت Growth ماهانه | ۷٫۹ میلیون منهای ۰٫۶۵ میلیون | ۷٫۲۵ میلیون |
| مشارکت وزنی هر مکان | ۶۰٪ Core + ۴۰٪ Growth | ۵٫۰۳ میلیون |
| بازگشت CAC | ۲۸ میلیون تقسیم بر ۵٫۰۳ میلیون | ۵٫۶ ماه |
| LTV تقریبی | ۵٫۰۳ میلیون × ۱۸ ماه | ۹۰٫۵۴ میلیون |
| نسبت LTV به CAC | ۹۰٫۵۴ تقسیم بر ۲۸ میلیون | ۳٫۲۳ برابر |
| نقطه | مکان فعال | پولی | درآمد ماهانه |
|---|---|---|---|
| ماه ۳ | ۲۰ | ۰ | ۱۰٫۵ میلیون |
| ماه ۶ | ۵۰ | ۲۰ | ۱۶۲٫۱ میلیون |
| ماه ۱۲ | ۱۵۰ | ۸۰ | ۸۰۴ میلیون |
| ماه ۱۸ | ۳۵۰ | ۲۱۰ | ۲٬۳۳۶ میلیون |
| ماه ۲۴ | ۷۰۰ | ۴۹۰ | ۵٬۹۷۱ میلیون |
| ماه ۳۶ | ۱٬۸۰۰ | ۱٬۴۴۰ | ۱۷٬۶۷۶ میلیون |
ترتیب بستهها از وابستگی فنی میآید، نه از جذابیت ظاهری: بنیان کد ← هویت و مرز سازمان ← موتور ظرفیت و رزرو ← سه سطح محصول ← مرز پرداخت و اعلان ← دادهٔ نمایشی ← تضمین کیفیت و انتشار. هر ماه یک خروجی قابل آزمایش و یک گیت عبور دارد.
استقرار monorepo با pnpm و TypeScript سختگیرانه، خط پایهٔ lint و تست، Design System و پوستهٔ سه نقش، سپس هویت، نشست، tenant و RBAC با ثبت رخداد حسابرسی.
مکان، شعبه، ساعت، تعطیلی، سالن، میز، ناحیه، رسانه، سیاست و چرخهٔ انتشار؛ سپس موتور ظرفیت با نگهداری TTL، ماشین وضعیت، همروندی خوشبینانه، idempotency، تغییر و لغو با snapshot سیاست.
کشف و صفحهٔ مکان، سپس رزرو کامل، مدیریت رزرو، صف انتظار، حریم خصوصی و پشتیبانی؛ همزمان برد امروز، دفتر رزرو، تقویم و رزرو تلفنی میزبان آغاز میشود.
CRM، رضایت، بخشبندی، کمپین، تحلیل، اشتراک و دفتر کل در سطح مکان؛ سپس کنترل عرضه، پشتیبانی و محتوا و در ادامه مالی، ریسک و تنظیمات پلتفرم.
اعلان و adapter پرداخت با outbox، retry محدود و dead-letter؛ دادهٔ نمایشی بدون دادهٔ شخصی و ردیابی mockup تا تست؛ سپس تست سرتاسری سه نقش، تست بار و رقابت، دسترسپذیری، runbook و تمرین بازیابی پشتیبان.
| بسته | ماه | خروجی کلیدی | معیار پذیرش |
|---|---|---|---|
| M0 · بنیان و خط پایهٔ کیفیت | ۱ | monorepo، TypeScript سخت، lint و تست، CI محلی، endpoint سلامت | نصب و build و تست بدون secret و بدون provider واقعی |
| M1 · Design System و پوستهٔ سه نقش | ۱ | توکن، تایپوگرافی RTL، چیدمان واکنشگرا، ناوبری، فرم، حالتهای خالی و خطا | تم روشن و تیره، پیمایش با صفحهکلید و برابری فارسی/انگلیسی |
| M2 · هویت، نشست، tenant و RBAC | ۱ | ورود با کد یکبارمصرف، نقش و سازمان و شعبه، ثبت رخداد، محدودیت نرخ | تستهای بدون احراز هویت، ممنوع، بینسازمانی و ارتقای امتیاز سبز |
| M3 · مکان، شعبه، محتوا و عرضه | ۲ | مکان و شعبه، ساعت و تعطیلی، سالن و میز، سیاست، چرخهٔ انتشار و صف نظارت | پروفایل قابل انتشار و اسلات معتبر ساخته میشود و مدیر پلتفرم تأیید یا رد میکند |
| M4 · موتور ظرفیت و چرخهٔ رزرو | ۲ | پرسوجوی موجودی، نگهداری TTL، ماشین وضعیت، تغییر و لغو، تایملاین و حسابرسی | تست رقابت و retry، انقضای نگهداری، سیاست لغو و بینسازمانی سبز |
| M5 · کشف و صفحهٔ مکان | ۳ | خانه، جستوجو، فیلتر، نقشه، دسته، کالکشن، جزئیات، منو، ساعات، نظر | فیلتر دسترسپذیر و امن در URL، حالت بدون نتیجه و خطای قابل بازیابی |
| M6 · رزرو و حساب مهمان | ۳ | انتخاب زمان و نفرات، نگهداری، شبیهساز پرداخت، رسید و QR، مدیریت رزرو، انتظار، حریم خصوصی | سناریوی سرتاسری رزرو و حالتهای شکست پرداخت و نگهداری تست میشود |
| M7 · عملیات میزبان: امروز و میز | ۳ | برد امروز، تقویم، رزرو تلفنی، check-in، نشاندن، انتقال، نقشهٔ سالن و ترکیب میز | دو میزبان همزمان یک میز را نمیگیرند؛ هر override دلیل و حسابرسی دارد |
| M8 · عرضه، CRM، رشد و مالی مکان | ۴ | ساعت و سیاست، کاربران، CRM و رضایت، بخشبندی، کمپین، تحلیل، اشتراک و دفتر کل | مرز دادهٔ حساس، رضایت و مجوز گزارش و خروجی تست میشود |
| M9 · کنترل پلتفرم: عرضه و کاربران | ۴ | شاخصها، صف مکان، نظارت محتوا، جستوجوی کاربر، تیکت، SLA و درخواست داده | مدیر پلتفرم با کاربر مکان اشتباه نمیشود؛ هر اقدام حساس به عامل و دلیل متصل است |
| M10 · کنترل پلتفرم: مالی و ریسک | ۴ | تعرفه، صورتحساب، تطبیق، تأیید بازپرداخت، حسابرسی، feature flag و سلامت provider | تست منفی در برابر شارژ/بازپرداخت تکراری و نمایش دادهٔ شخصی |
| M11 · اعلان، پرداخت و مرز یکپارچهسازی | ۵ | درگاههای provider، outbox، retry محدود، صف مرده، امضای webhook و idempotency | وقفه، callback تکراری، شکست تحویل و redaction تست میشود؛ هیچ credential در مخزن نیست |
| M12 · دادهٔ نمایشی و mockup | ۵ | دادهٔ اولیهٔ واقعنما بدون دادهٔ شخصی، فهرست صفحه و mockup صفحهبهصفحه، prototype جریان | هر مسیر به mockup، سناریوی کاربرد و تست قابل ردیابی است |
| M13 · تضمین کیفیت و آمادگی انتشار | ۵ | تست سرتاسری سه نقش، تست قرارداد، بار و رقابت، دسترسپذیری، runbook و تمرین بازیابی | پاکت پایان کار، شواهد و داوری مستقل پذیرش؛ سپس فقط با دستور صریح مالک، انتشار |
M0 → M1 → M2 → M3 → M4
M4 → { M5 → M6 , M7 → M8 , M9 → M10 , M11 }
{ M6 , M8 , M10 , M11 } → M12 → M13
صفحات اپ مهمان و عملیات میزبان از نظر ساخت موازیاند، ولی هر دو روی قرارداد API مشترک ساخته میشوند. هیچ بستهای برای نمایش، حذف نمیشود؛ بستهٔ بعدی بدون پذیرش بستهٔ قبل شروع نمیشود.
رشد بر اساس داده قفل شده است، نه بر اساس خوشبینی. هر گیت یک عدد هدف، فرمول محاسبه و تصمیم صریح در صورت عدم تحقق دارد.
| گیت | هدف | فرمول | تصمیم در صورت عدم تحقق |
|---|---|---|---|
| تازگی موجودی | ۶۰٪+ | مکانهای بهروزکنندهٔ هفتگی ÷ مکان فعال | توقف جذب تقاضا و اصلاح onboarding |
| تکمیل خودکار رزرو | ۷۰٪+ | رزرو نهایی بدون مداخله ÷ رزرو قطعی | اصلاح جریان کاربر یا منطق ظرفیت |
| تبدیل پایلوت به پولی | ۴۰٪+ | مکان پولی ÷ مکان پایانیافتهٔ پایلوت | بازآزمایی ارزش و قیمت |
| بازگشت CAC | کمتر از ۹ ماه | هزینهٔ جذب عرضه ÷ مشارکت ناخالص ماهانه | توقف مقیاس کانال جذب |
| نرخ no-show | کمتر از خط پایه | no-show ÷ رزرو تأییدشده | آزمون سیاست، یادآوری و ودیعه |
| ریسک | کنترل | مالک و شرط خروج |
|---|---|---|
| provider و مقررات پرداخت | adapter، feature flag و snapshot سیاست؛ اتصال واقعی فقط با مجوز | کسبوکار و حقوقی |
| رقابت بر سر ظرفیت | نگهداری تراکنشی، idempotency، تست همروندی و بار | مهندسی |
| پیچیدگی صفحات | Design System، فهرست مسیرها و ردیابی mockup تا تست | محصول و طراحی |
| نشت دادهٔ شخصی | کمینهسازی، redaction، مجوز، حسابرسی و اسکن secret | امنیت |
| گسترش بیضابطه | بستههای M0 تا M13 و پذیرش مستقل هر بسته | مالک محصول |
اتاق دادهٔ این طرح مشخص است: مصاحبه، تعهد پایلوت، برگهٔ مالی، داشبورد واقعی، وضعیت حقوقی، نقشهٔ محصول، برنامهٔ استخدام و سیاههٔ ریسک. تا این شواهد جمع نشود، ادعای آمادگی بازار یا درآمد قطعی درست نیست.