نحوه ساخت اپلیکیشن رزرو: بازه‌های زمانی، دسترسی، یادآوری و پیش‌پرداخت

برای ساخت یک اپلیکیشن رزرو، چهار چیز باید کنار هم کار کنند: فهرستی از آنچه می‌شود رزرو کرد (خدمات، اتاق‌ها، کارکنان)، قوانینی برای زمان در دسترس بودن هر کدام، جریان رزروی که فقط زمان‌های واقعاً خالی را پیشنهاد می‌دهد، و نمایی خصوصی که کسب‌وکار در آن آنچه وارد شده را مدیریت می‌کند. یک سازنده‌ی اپلیکیشن هوش مصنوعی می‌تواند از یک توضیح کوتاه، در چند دقیقه، نسخه‌ی اول کارکردی بسازد؛ کار واقعی تصمیم‌گیری درباره‌ی قوانین است — طول هر بازه، فاصله‌ی بین نوبت‌ها، لغو، منطقه‌های زمانی — و آزمایش اینکه رزرو دوباره غیرممکن باشد.

ابتدا تعیین کنید «یک رزرو» برای شما یعنی چه

اپلیکیشن‌های رزرو از بیرون شبیه‌اند، ولی از درون خیلی متفاوت‌اند. اول به این سؤال‌ها پاسخ دهید:

• چه چیزی رزرو می‌شود؟ یک خدمت (اصلاح مو)، یک نفر (مدرس خصوصی)، یک منبع (اتاق جلسه، زمین بازی، ون)، یا یک جا در یک جلسه (کلاس یوگا با ۱۲ جا).
• چقدر طول می‌کشد؟ برای هر خدمت ثابت است، یا مشتری انتخاب می‌کند؟
• چه کسی ارائه می‌دهد؟ یک نفر، چند کارمند با ساعات کاری خودشان، یا هیچ‌کس (یک اتاق)؟
• پس از رزرو چه اتفاقی می‌افتد؟ تأیید فوری، یا درخواستی که صاحب کسب‌وکار تأیید می‌کند؟
• آیا پول در میان است؟ رایگان، پرداخت در روز مراجعه، پیش‌پرداخت، یا پرداخت کامل از قبل؟

«زمانی را درخواست کنید، صاحب کسب‌وکار با ایمیل تأیید می‌کند» بسیار ساده‌تر از «رزرو فوری در برابر تقویم سه کارمند، با پیش‌پرداخت» ساخته می‌شود. هر دو معتبرند — برای نسخه‌ی اول همان را انتخاب کنید که واقعاً لازم دارید.

اپلیکیشن به چه چیزی نیاز دارد

داده

ذخیره‌ی زمان پایان برای هر رزرو، نه فقط زمان شروع، بررسی هم‌پوشانی را خیلی ساده‌تر می‌کند.

صفحات

• عمومی: فهرست خدمات، انتخاب‌گر بازه، فرم رزرو، صفحه‌ی تأیید، و یک لینک لغو یا تغییر زمان.
• خصوصی (صاحب کسب‌وکار یا کارکنان): برنامه‌ی امروز، رزروهای آینده، راهی برای مسدود کردن زمان مرخصی، و تنظیمات خدمات و ساعات.

دسترسی‌ها

مشتریان فقط باید زمان‌های خالی یا مشغول را ببینند — هرگز نام مشتریان دیگر را. کارکنان شاید فقط برنامه‌ی خودشان را ببینند؛ صاحب کسب‌وکار همه‌چیز را می‌بیند. این را یادداشت کنید، چون تعیین می‌کند آیا به ورود و نقش‌ها نیاز دارید یا نه. راهنمای ما درباره‌ی افزودن ورود به اپلیکیشن گزینه‌ها را پوشش می‌دهد.

بخش‌های سخت، و نحوه‌ی برخورد با آن‌ها

رزروهای دوباره

باگ کلاسیک: دو نفر صفحه را باز می‌کنند، هر دو ساعت ۱۰:۰۰ را خالی می‌بینند، و هر دو آن را رزرو می‌کنند. راه‌حل این است که هنگام ذخیره‌ی رزرو، روی سرور دوباره بررسی شود و اگر هم‌پوشانی وجود داشت رد شود. این را صریحاً درخواست کنید:

هنگام ذخیره‌ی یک رزرو، روی سرور دوباره بررسی کن که هیچ رزرو تأییدشده یا در انتظاری برای همان کارمند با زمان درخواستی هم‌پوشانی نداشته باشد (از جمله زمان بین نوبت‌ها). اگر داشت، رد کن و پیام «این زمان همین حالا گرفته شد — لطفاً زمان دیگری انتخاب کنید» را نشان بده.

سپس آن را با دو پنجره‌ی مرورگر آزمایش کنید.

منطقه‌های زمانی

هر زمان را به‌صورت UTC ذخیره کنید و برای نمایش تبدیل کنید. تصمیم بگیرید صفحه‌ی رزرو منطقه‌ی زمانی چه کسی را نشان دهد — معمولاً منطقه‌ی کسب‌وکار برای خدمات حضوری، و منطقه‌ی مشتری برای تماس‌های آنلاین — و آن را روی صفحه برچسب بزنید. یک رزرو را در تغییر ساعت تابستانی آزمایش کنید.

زمان بین نوبت‌ها، اطلاع قبلی و محدودیت‌ها

قوانین رایجی که ارزش دارد پیش از شروع تصمیم بگیرید: زمان فاصله بین نوبت‌ها، حداقل اطلاع قبلی («کمتر از ۲ ساعت قبل رزرو نداریم»)، اینکه مردم تا چند وقت جلوتر می‌توانند رزرو کنند، و سقف روزانه. هر کدام یک جمله در یک پرامپت است؛ اگر آن‌ها را حذف کنید، هوش مصنوعی پیش‌فرض‌ها را برایتان انتخاب می‌کند.

لغو و عدم حضور

به هر تأیید یک لینک لغو با توکن یکتا بدهید تا مشتریان به حساب کاربری نیاز نداشته باشند. پنجره‌ی لغو و اینکه آیا پیش‌پرداخت قابل بازپرداخت است را تعیین کنید، و آن سیاست را پیش از پرداخت نشان دهید.

یادآورها

ایمیل یا پیامک یادآور به چیزی نیاز دارد که به‌صورت زمان‌بندی‌شده اجرا شود («هر ۱۵ دقیقه، یادآور بفرست برای رزروهایی که ۲۴ ساعت دیگر شروع می‌شوند»). بررسی کنید سازنده و میزبانی شما کارهای زمان‌بندی‌شده را چطور مدیریت می‌کنند. اگر نمی‌کنند، از یک زمان‌بند خارجی استفاده کنید که یک endpoint در اپلیکیشن شما را فراخوانی کند، یا ایمیل تأیید را با یک دعوت تقویم پیوست کنید تا تقویم خود مشتری یادآوری کند. برای بخش ارائه‌دهنده به نحوه‌ی ارسال ایمیل از اپلیکیشن مراجعه کنید.

پیش‌پرداخت و پرداخت

الگوی معمول با Stripe:

۱. مشتری یک بازه را انتخاب می‌کند؛ اپلیکیشن یک رزرو در انتظار می‌سازد که بازه را برای مدت کوتاهی (مثلاً ۱۵ دقیقه) نگه می‌دارد. ۲. اپلیکیشن آن‌ها را برای پرداخت پیش‌پرداخت به Stripe Checkout می‌فرستد. ۳. وقتی پرداخت موفق باشد، Stripe از طریق webhook به اپلیکیشن شما خبر می‌دهد؛ رزرو تأییدشده می‌شود. ۴. اگر پرداختی به‌موقع انجام نشود، رزرو در انتظار منقضی می‌شود و بازه آزاد می‌شود.

قیمت‌گذاری استاندارد Stripe درصدی به‌علاوه‌ی کارمزد ثابت برای هر پرداخت موفق با کارت است، بدون هزینه‌ی ماهانه (از سپتامبر ۲۰۲۶)؛ نرخ‌ها بر اساس کشور فرق می‌کنند، پس صفحه‌ی قیمت Stripe را برای کشور خودتان بررسی کنید. تا وقتی همه‌چیز کار نکند، از حالت آزمایشی و کارت‌های آزمایشی استفاده کنید. راهنمای افزودن پرداخت را گام‌به‌گام دنبال کنید.

یک پرامپت اولیه که کار می‌کند

یک اپلیکیشن رزرو برای Northside Barbers بساز. خدمات: اصلاح مو (۳۰ دقیقه، $25)، اصلاح ریش (۱۵ دقیقه، $12)، اصلاح مو + ریش (۴۵ دقیقه، $32). دو آرایشگر، Sam و Ali، هر کدام از سه‌شنبه تا شنبه ۹:۰۰ تا ۱۸:۰۰ کار می‌کنند. مشتریان یک خدمت را انتخاب می‌کنند، سپس یک آرایشگر یا «هر آرایشگری»، و بعد فقط زمان‌های شروع ۱۵ دقیقه‌ای خالی را برای ۱۴ روز آینده می‌بینند و نام، تلفن و ایمیل را وارد می‌کنند. رزروها را در یک دیتابیس ذخیره کن، با ۱۰ دقیقه فاصله بعد از هر نوبت، و هنگام ذخیره دوباره دسترسی را بررسی کن تا رزرو دوباره جلوگیری شود. یک صفحه‌ی تأیید با لینک لغو نشان بده. صاحب کسب‌وکار یک صفحه‌ی خصوصی دارد که رزروهای امروز و آینده را فهرست می‌کند، می‌تواند رزرو را لغو کند و می‌تواند زمان مسدود کند. زمان‌ها بر اساس منطقه‌ی زمانی محلی مغازه است. طراحی تمیز و اول‌موبایل.

این پرامپت نام خدمات، کارکنان، ساعات، قوانین و نمای صاحب کسب‌وکار را مشخص می‌کند — همه‌چیزی که در غیر این صورت هوش مصنوعی حدس می‌زد.

مراحل ساخت

۱. اول جریان اصلی رزرو. خدمات ← بازه ← فرم ← رزرو ذخیره‌شده ← تأیید. تا وقتی این روی گوشی کار نکند، چیز دیگری اضافه نکنید. ۲. نمای صاحب کسب‌وکار. فهرست امروز، فهرست آینده، لغو، مسدود کردن زمان. ۳. محافظت از صفحات صاحب کسب‌وکار. پیش از ورود داده‌ی واقعی، ورود را اضافه کنید. ۴. قوانین. زمان بین نوبت‌ها، دوره‌ی اطلاع قبلی، افق رزرو، تعطیلات. ۵. ایمیل. تأیید با دعوت تقویم و لینک لغو. ۶. پیش‌پرداخت در صورت نیاز، ابتدا در حالت آزمایشی Stripe. ۷. آزمایش حالت‌های مرزی. دو پنجره که همان بازه را رزرو می‌کنند، رزروی که از نیمه‌شب می‌گذرد، تاریخ تغییر ساعت تابستانی، و رزروی که لغو شده و بازه‌اش را آزاد می‌کند. ۸. انتشار، سپس پیش از اشتراک‌گذاری لینک، خودتان یک رزرو واقعی انجام دهید.

اشتباهات رایج

• بررسی دسترسی فقط در مرورگر. درست به نظر می‌رسد و باز هم دوبار رزرو می‌کند.
• ذخیره‌ی زمان محلی بدون منطقه‌ی زمانی. تا وقتی ساعت‌ها تغییر کنند کار می‌کند.
• نمایش نام مشتریان در تقویم عمومی. فقط خالی یا مشغول را نشان دهید.
• ساختن برنامه‌ریزی کارکنان، امتیازهای وفاداری و پیامک در روز اول. جریان اصلی را راه بیندازید، سپس آنچه مشتریان واقعاً می‌خواهند را اضافه کنید.
• نبودن راهی برای صاحب کسب‌وکار برای مسدود کردن زمان. اولین روز بیماری، عدم حضور مشتریان را ایجاد می‌کند.

کی Calendly (یا مشابه آن) انتخاب بهتری است

اگر یک نفر هستید که زمان‌های خالی‌اش را برای تماس به اشتراک می‌گذارد، یک ابزار زمان‌بندی را سخت می‌توان شکست داد. از سپتامبر ۲۰۲۶، پلن رایگان Calendly یک نوع رویداد، یک اتصال تقویم و زمان‌بندی یک‌به‌یک با صفحه‌ی رزرو قابل‌سفارشی‌سازی را پوشش می‌دهد، و پلن‌های پولی نوع رویداد و امکانات تیمی بیشتری اضافه می‌کنند. ابزارهایی از این دست از همان ابتدا به تقویم موجود شما وصل می‌شوند، کاری که یک اپلیکیشن اختصاصی باید برای آن ساخته شود.

اپلیکیشن اختصاصی را بسازید وقتی به قوانینی نیاز دارید که آن ابزارها پشتیبانی نمی‌کنند، به چند منبع قابل رزرو، برند اختصاصی در همه‌جا، رزروهایی که به داده‌های دیگر (مشتریان، سفارش‌ها، عضویت‌ها) وصل‌اند، یا وقتی یک محصول رزرو می‌سازید که به دیگران بفروشید.

ساخت با Mythex

در Mythex اپلیکیشن رزرو را در چت توصیف می‌کنید، در یک پیش‌نمایش زنده ساخته می‌شود، و وقتی رزروها باید ذخیره شوند یک دیتابیس Postgres اضافه می‌کند. یوزکیس صفحه‌ی رزرو در مستندات پیشنهاد می‌کند با یک فرم درخواست و فهرست مدیریت شروع کنید و بعد بقیه را اضافه کنید. درباره‌ی آنچه داخلی است و آنچه خودتان وصل می‌کنید شفاف باشید: Mythex همگام‌سازی تقویم داخلی، یادآور پیامکی یا محصول پیش‌پرداخت ندارد. ایمیل از طریق ارائه‌دهنده‌ی خودتان می‌رود، پیش‌پرداخت از طریق کلیدهای Stripe خودتان که به‌عنوان اسرار پروژه ذخیره می‌شوند (دستور Stripe)، و قوانین هم‌پوشانی و منطقه‌ی زمانی چیزهایی هستند که خودتان مشخص و آزمایش می‌کنید، همان‌طور که بالاتر گفته شد.

دستور /test باعث می‌شود عامل جریان رزرو را در پیش‌نمایش طی کند و گزارش دهد چه چیزی خراب می‌شود. برای یک پرامپت شروع، قالب‌های وب‌سایت رزرو آرایشگاه یا رزروکننده‌ی جلسه را امتحان کنید، یا همه‌ی قالب‌های اپلیکیشن را ببینید.

پرسش‌ها