Flow Meet: ثبتنام، اجرای رویداد و پیگیری
P31
برنامه شروع
ثبتنام معتبر به پرداخت تأییدشده و یک بلیت درست برای رویداد برسد.
قدم اول
یک سفارش آزمایشی را در محیط تست از ثبتنام تا بلیت بازپخش کنید؛ شناسه رویداد، سفارش، تراکنش و رسید سمت سرور را ثبت کنید.
- مسئول پیشنهادی
- مسئول Flow Meet و عملیات رویداد
- معیار نتیجه
- پرداخت ناموفق، تکراری یا دیررس به بلیت اضافه یا بیشفروشی منجر نشود؛ نتیجه از رسید سمت سرور تأیید شود.
ورودیهای لازم
- محیط تست و شناسههای سفارش
- ظرفیت و شرایط رویداد
- قرارداد درگاه و صدور بلیت
کمک هوش مصنوعی: از راهنمای تأییدشده پاسخ و خلاصه پرونده پیشنهاد کند؛ ظرفیت، پرداخت، بلیت و بازپرداخت در منطق محصول بمانند.
روش آزمون و ابزارها
مقایسه با روش فعلی
یک منبع حقیقت برای رویداد و ظرفیت، وضعیت قطعی ثبتنام/پرداخت/بلیت، کلید یکتا برای عملیات و پیامهای قالبی؛ آزمون انتهابهانتها و رسیدگی انسانی به وضعیت نامعلوم. این لایه مستقل از AI لازم است.
نمونه آزمون
طرح پیشنهادی: یک رویداد تست و دستکم ۲۰ مسیر شامل ظرفیت آخر، دو کلیک، callback تکراری/دیررس، قطع شبکه، بلیت غایب و تغییر زمان؛ سپس ۳۰ پرسش مجاز رویداد شامل بیپاسخ و وضعیت حساب غیرمجاز. پرداخت واقعی لازم نیست و این نمونه نرخ فروش واقعی تولید نمیکند.
- تعداد بلیت/پیام اضافه برای یک سفارش و تعداد ظرفیت فروختهشده خارج سقف
- سهم پرداخت تأییدشده دارای یک بلیت معتبر و زمان تطبیق استثنا
- درستی پاسخ منبعدار، امتناع از وضعیت غیرمجاز و تحویل موفق به خدمات
- زمان کل پاسخگویی؛ تکمیل خرید و حضور فقط پس از داشتن داده واقعی
معیار پیشنهادی پذیرش
پیشنهاد: تمام مسیرهای حساس تست بدون بلیت اضافه، بیشفروشی و اعلام پرداخت ساختگی عبور کنند؛ هیچ اطلاعات حساب دیگر در آزمون FAQ آشکار نشود؛ دستیار زمانی اضافه شود که نسبت به FAQ/قالب، پاسخگویی را با کیفیت حداقل برابر آسانتر کند. این شرط پیشنهادی و فاقد نتیجه اجرایی است.
ابزارهای مرتبط
- Easy Digital Downloads — موتور فروش مشاهدهشده و اتصال خواندنی
- Playwright — آزمون انتهابهانتها با شاهد
- promptfoo — ارزیابی FAQ پس از صحت پایه
منابع فنی
- C01 · Promptfoo — Assertions and metrics — آزمون قطعی، اعتبارسنجی ساختار، معیار هزینه و تأخیر و داوری مدل؛ مبنای طراحی مجموعه آزمون نسخهها.
- C05 · Playwright — Trace viewer — ثبت مرحلهها، وضعیت DOM، خطا و درخواست شبکه برای تشخیص علت شکست مسیر مرورگر؛ مجوز Apache-2.0 بررسی شد.
- C08 · Easy Digital Downloads — REST API introduction — REST API توصیفشده اطلاعات ذخیرهشده محصول، مشتری و فروش را میخواند و ساخت محصول، سفارش یا مشتری را پشتیبانی نمیکند؛ هدر کد GPL-2.0-or-later بررسی شد.
- C18 · LangGraph — Interrupts and idempotent side effects — توقف با checkpointer و thread_id و ادامه با تصمیم بیرونی؛ هنگام resume کد پیش از interrupt ممکن است دوباره اجرا شود و اثر جانبی باید تکرارپذیر باشد.
جزئیات پروژه و منابع
این پروژه چه کمکی به کار روزانه میکند؟
یک مثال فرضی: در Flow Meet کاربر دوبار دکمه پرداخت را میزند یا پرداختش موفق است اما بلیت ندارد. ابزار وضعیت ثبتنام، پرداخت و بلیت را به هم وصل میکند.
برای شروع، چه چیزی آماده میشود؟
برای هر ثبتنام یک پرونده روشن دیده میشود: «پرداخت تأیید شده؛ بلیت صادر نشده؛ نیازمند پیگیری»؛ درخواست تکراری بلیت اضافه نمیسازد.
در مرحله بعد، چه میتوان اضافه کرد؟
بعد از درستشدن این مسیر، پاسخ به سؤالهای رویداد و یادآوری زمان برگزاری اضافه میشود.
وضعیت پرداخت و بلیت از رکورد سامانه تعیین میشود؛ هوش مصنوعی فقط در نوشتن پیام و دستهبندی سؤال کمک میکند.
مراحل پیشنهادی کار
- مرحله ۱
آزمایش ثبتنام، پرداخت و صدور بلیت
ابتدا رویداد، ظرفیت، پرداخت و صدور بلیت را تا نتیجه نهایی آزمایش میکنیم.
- مرحله ۲
راهنمای اطلاعات تأییدشده
سپس دستیار از اطلاعات تأییدشده رویداد به سؤالهای پرتکرار پاسخ میدهد.
- مرحله ۳
پیگیری انسانی
سؤالهای نیازمند پیگیری خلاصه و به کارشناس مشخص سپرده میشوند.
- مرحله ۴
جمعبندی رویداد با رضایت
پس از رویداد، با رضایت افراد صورتجلسه یا محتوای قابل انتشار آماده میشود.
زمان، درستی خروجی و فایده کار را بسنجیم
۱. زمان و هزینه انجام کار
دقیقه پاسخگویی و رسیدگی به استثنای ثبتنام
۲. کیفیت و اعتبار
نرخ بلیت/پرداخت صحیح و عدم وعده ظرفیت ناموجود
۳. فایده و نتیجه اقتصادی
نرخ تکمیل خرید بلیت و حضور واقعی
توضیحات بیشتر برای اجرا و بررسی نتیجه
این کار کجا ثبت میشود؟
تیمیک: کارهای فعلی Flow Meet برای تحویل کار؛ سفارش/بلیت در سامانه رویداد، نه چت هوش مصنوعی
هر مرحله را چه کسی انجام میدهد و به چه کسی تحویل میدهد؟
- ۱
فروش یا برگزارکننده، تعهدات رویداد را مشخص میکند
- ۲
تیم فنی، ظرفیت و پرداخت را بررسی میکند
- ۳
خدمات، موارد خاص و بازپرداخت را پیگیری میکند
- ۴
تیم ویدئو و شبکههای اجتماعی، محتوای مجاز را آماده میکنند.
فروش یا برگزارکننده، تعهدات رویداد را مشخص میکند ← تیم فنی، ظرفیت و پرداخت را بررسی میکند ← خدمات، موارد خاص و بازپرداخت را پیگیری میکند ← تیم ویدئو و شبکههای اجتماعی، محتوای مجاز را آماده میکنند.
از کجا بفهمیم آزمون اولیه موفق بوده است؟
یک رویداد تست با ظرفیت تمام، پرداخت تکراری/ناموفق و تغییر زمان؛ هوش مصنوعی حق رزرو قطعی یا بازپرداخت ندارد.
چه زمانی باید کار را متوقف کنیم؟
تا وقتی مراحل اصلی کار تأیید نشده، متناسبسازی برای هر کاربر و agent فروش بلیت اولویت نگیرد.
برای شروع چه لازم است و بعد چه میکنیم؟
چه چیزهایی باید آماده باشد؟
این موارد باید از پروژههای مرتبط آماده شوند؛ کاملشدن همه امکانات آن پروژهها لازم نیست.
- P20؛ دیدن پروژه مرتبط
مسیرهای مهم کاربر و حسابها و دادههای آزمایشی آماده باشند؛ مثلاً خرید با پرداخت آزمایشی.
- P09؛ دیدن پروژه مرتبط
راهنمای پاسخ پشتیبانی و روش خواندن اطلاعات مجاز حساب و ارجاع به کارشناس آماده باشد.
مراحل پیشنهادی اجرا و توسعه
این مراحل برنامه پیشنهادیاند؛ انجامشدن آنها هنوز تأیید نشده است.
- مرحله ۱آزمون پایه
ثبتنام، پرداخت و صدور بلیت را تا آخر آزمایش کنید.
- مرحله ۲دستیار از راهنماهای مجاز، همراه منبع پاسخ میدهد.
به سؤالهای زمان و شرایط رویداد از راهنمای تأییدشده پاسخ دهید.
- مرحله ۳پیگیری با رضایت
ثبتنام ناقص را یادآوری و نیاز شرکتکنندگان برای رویداد بعد را بررسی کنید.