درخواست روی چند پیامرسان پخش میشود
یکی در ایتا مینویسد، یکی در بله، یکی در تلگرام. هیچ نمای واحدی از «چه کسی منتظر است» وجود ندارد.
تیکت پشتیبانی را از همان پیامی بسازید که کاربر فرستاده
کاربر در ایتا، بله یا تلگرام پیام میدهد؛ شما همان پیام را به یک تیکت با وضعیت جدید→باز→در انتظار→حلشده تبدیل میکنید. یونیوم فقط لایه دریافت و ارسال را یکسان میکند؛ منطق تیکت، صف و SLA مال شماست و روی همان قالب آشنای Bot API اجرا میشود.
۴ وضعیت تیکت
۱ پیام به تیکت
۱ وبهوک مشترک
۹۰ ثانیه long-poll
ورودیپیام کاربر از هر پیامرسان متصل
وبهوکPOST به endpoint شما با message_id یکتا
تیکتوضعیت، مسئول و سابقه گفتوگو در سامانه شما
پشتیبانی پراکنده، نه پاسخ کند
مشکل سرعت پاسخ نیست؛ مشکل این است که هیچکس نمیداند وضعیت کجاست.
SLA و وضعیت تعریفنشده است
پیام خوانده میشود اما پاسخ دیر میرسد و هیچ نفر نمیداند از کجا دنبال آن بگردد. اولینبار بود یا ششمینبار؟
کیفیت پاسخ به اپراتور بستگی دارد
هر اپراتور فقط پیامرسانی را باز کرده که خودش استفاده میکند. درخواستهای دیگر در همان لحظه نادیده میمانند.
سابقه و audit trail نیست
هیچ لاگ متمرکزی از چه گفته شد، چه ارسال شد و کدام ارسال شکست خورد وجود ندارد. همهچیز در چت شخصی اپراتورها گم میشود.
راهکار پشتیبانی فقط «ارسال پاسخ» نیست؛ تبدیل یک کانال چت به یک فرآیند قابل اندازهگیری است. یونیوم لایه پیامرسان را یکسان میکند تا شما روی قواعد تیکت تمرکز کنید.
از پیام ورودی تا پاسخ اپراتور
هر تیکت از یک رویداد واقعی شروع میشود و در یک ارسال قابل پیگیری تمام میشود.
۱. پیام میرسد
کاربر در پیامرسان متصل پیام میفرستد. یونیوم رویداد را با message_id و update_id یکتا به وبهوک شما POST میکند.
۲. تیکت ساخته میشود
سرور شما را با 200 OK جواب میدهد و در پسزمینه تیکت را در صف میریزد: تطبیق با گفتوگوی قبلی کاربر یا باز کردن تیکت جدید.
۳. اپراتور پاسخ میدهد
اپراتور در helpdesk خودش پاسخ مینویسد. سامانه شما با کلید API با scope مشخص، پاسخ را از طریق sendMessage یونیوم به همان پیامرسان میفرستد.
۴. وضعیت و لاگ ثبت میشود
نتیجه ارسال (موفق / خطا) کنار تیکت ذخیره میشود. اگر ارسال شکست خورد، تیکت به حالت در انتظار برمیگردد تا اپراتور دوباره امتحان کند یا مسیر دیگری پیدا کند.
هر مرحله یک فراخوانی ساده HTTP است. کلید این است که پردازش سنگین (ارجاع، قوانین، ذخیره) داخل صف شما انجام میشود، نه در مسیر وبهوک؛ وبهوک باید سریع جواب 200 بدهد تا یونیوم آن update را تأییدشده بداند.
چیزی که یک helpdesk واقعی نیاز دارد
نه فقط «ارسال و دریافت» — کنترلهای عملیاتی که یک تیم پشتیبانی را سر پا نگه میدارند.
ساخت تیکت از message_id
هر پیام ورودی با شناسه پلتفرم + شناسه داخلی تیکت ذخیره میشود؛ جستوجوی سابقه گفتوگو با همان شناسهها انجام میشود.
ارجاع به اپراتور
تیکت به صف تیم یا یک اپراتور ارجاع میشود؛ فقط آن اپراتور مجاز به پاسخ با کلید API اختصاصی خودش است.
چرخه وضعیت
جدید → باز → در انتظار → حلشده. هر انتقال با دلیل ثبت میشود: پاسخ کاربر، اسکلشن به ارشد، یا بسته شدن خودکار.
پاسخ خودکار خارج از ساعت کار
پیام بیرون از ساعات کاری یک acknowledgment فوری میگیرد («در اولین فرصت پاسخ میدهیم») و تیکت در صف روز بعد میماند.
idempotency روی وبهوک
اگر یونیوم یک message_id را دوبار بفرستد، شما دو تیکت نمیسازید. بهجای آن، update_id را بهعنوان کلید یکتا در پایگاهداده نگه میدارید.
اسکلشن به ارشد
تیکتهای حساس یا قدیمی بهطور خودکار به صف ارشد میروند؛ همهچیز در همان گفتوگو و سابقه واحد قابل پیگیری میماند.
این قابلیتها در helpdesk شما اجرا میشوند، نه در یونیوم. یونیوم لایه ورودی/خروجی پیامرسان را یکسان و قابل اتکا میکند؛ منطق تیکت مال شماست.
اشتباههای رایج در helpdesk پیامرسانی
هر کدام از اینها یک تیم پشتیبانی را در عمل غیرفعال میکند.
پاسخ ۱۰۰۰تایی در یک دقیقه
روی پیامرسانهای account-based نمیتوانید هزاران پاسخ را در یک لحظه بفرستید. یونیوم تلاش میکند صف را عادلانه پخش کند اما محدودیت نرخ خود پلتفرم همچنان پابرجاست؛ صف پشتیبانی را با فاصله زمانی و اولویت طراحی کنید.
وبهوک را دیر جواب دادن
اگر پردازش تیکت را داخل خود endpoint وبهوک انجام دهید، timeout میخورید و یونیوم update را دوباره میفرستد. کار سنگین را در صف پسزمینه ببرید؛ endpoint فقط باید 200 برگرداند.
پاسخ به کاربر اشتباه
اگر chat_id گیرنده را درست ذخیره نکرده باشید، پاسخ اپراتور به یک کاربر دیگر میرسد. شناسهها را دقیقاً همانطور که از وبهوک آمدهاند، بدون نرمالسازی دستی، بازگردانید.
نادیده گرفتن خطای INVALID_AUTH
اگر یک credential احراز هویتش را از دست بدهد (INVALID_AUTH یا transport failed)، تیکتهای آن صف گیر میکنند. مانیتور کنید و مسیر fallback یا اعلان به اپراتور داشته باشید — یونیوم کاربر را جبرانی احراز نمیکند.
یک کلید API برای همه اپراتورها
اگر همه از یک کلید با scope کامل استفاده کنند، audit nonممکن میشود. به هر اپراتور کلید جدا با scope محدود بسازید تا هر ارسال قابل ردیابی بماند.
انتظار برابری قابلیتها
این قابلیت روی همه credentialها معنی یکسان ندارد. مثلاً ارسال ویس روی همه پیامرسانها پشتیبانی نمیشود؛ قبل از ساخت کمکدسک، جدول قابلیتهای هر پلتفرم را بررسی کنید.
کدام پیامرسان برای کدام نوع پشتیبانی
هر پیامرسان بازوی خاص خودش را دارد؛ انتخاب هوشمندانه بر اساس نوع تماس و مخاطب است.
تلگرام — پشتیبانی رسمی محصول
اگر کاربران شما VPN دارند، تلگرام با Bot API رسمی (BotFather) بهترین تجربه توسعهدهنده را دارد: inline keyboard، callback_query، rich media. برای کانالهای پشتیبانی رسمی ایدهآل است.
بله — پشتیبانی سازمانی + پرداخت
بله تنها پیامرسان ایرانی با Bot API رسمی بالغ («بازو»، مبتنی بر Bot API تلگرام) است و درگاه پرداخت درونبات دارد. برای پشتیبانی سازمانی و دولتی که هویت و خدمات مالی درهمآمیختهاند، انتخاب ریشهدار است.
ایتا — دسترسی به مخاطب کلان
حدود ۴۰ میلیون کاربر فعال ماهانه، اما هنوز Bot API رسمی ندارد. یونیوم از طریق لایه account به ایتا دسترسی میدهد؛ مناسب پشتیبانی بر اساس کانال و گفتوگوی مستقیم.
سروشپلاس — بدون فیلتر، رمزنگاریشده
پیامرسان بدون فیلتر با رمزنگاری؛ لایه بات رسمی هنوز آزمایشی است. برای کاربرانی که به تلگرام دسترسی پایدار ندارند و انتظار حریم خصوصی دارند، مسیر مطمئن پشتیبانی است.
روبیکا — بیشترین کاربر فعال روزانه
بیشترین کاربر فعال روزانه میان پیامرسانهای ایرانی (حدود ۴۸ میلیون DAU). اگر مخاطب جوان و مصرفکننده شماست، حضور در روبیکا از طریق لایه account یونیوم معنی میدهد.
معمولاً تیمها از ترکیبی استفاده میکنند: تلگرام و بله برای پشتیبانی رسمی، ایتا و روبیکا برای دسترسی به مخاطب کلان. با یک کلید یونیوم همه از همان endpoint و همان ساختار وبهوک کار میکنند.
چکلیست قبل از راهاندازی production
این موارد را در همان روز اول رعایت کنید، نه بعد از اولین حادثه.
از یک اتصال کوچک شروع کنید
یک پیامرسان، یک نوع تیکت، یک اپراتور. وقتی جریان ورودی→تیکت→پاسخ پایدار شد، پلتفرم بعدی را اضافه کنید. اصل helpdesk چندپیامرسانی این است که هر پلتفرم جدید فقط یک credential تازه باشد، نه یک پروژه بازنویسی.
- وبهوک را روی HTTPS با таймاوت کوتاه (۱۵–۲۵ ثانیه) اجرا کنید و کار سنگین را به صف پسزمینه ببرید.
- update_id یا message_id را بهعنوان کلید idempotency در پایگاهداده ذخیره کنید تا پیام تکراری تیکت تکراری نسازد.
- برای هر اپراتور کلید API جدا با scope فقط-send بسازید؛ کلید main را در helpdesk نگذارید.
- وضعیت ارسال (موفق / شکست / retry) را کنار تیکت لاگ کنید تا خطاهای INVALID_AUTH و transport failed را زود ببینید.
- خارج از ساعات کاری یک acknowledgment خودکار بفرستید و تیکت را در صف روز بعد نگه دارید.
- محیط توسعه را با یک credential آزمایشی و کلید scope-کم بسازید؛ هیچوقت روی credential عملیاتی توسعه ندهید.
- قواعد هر پلتفرم (rate limit، اندازه فایل، پشتیبانی ویس/مدیا) را پیش از طراحی پاسخهای متفاوت بررسی کنید.
- مسیر fallback برای وقتی یک credential احراز هویتش را از دست داد داشته باشید: اعلان به اپراتور، نه سکوت.
تیکتها و inboxهایی که آمادهی اتصالاند
پشتیبانی زنده معمولاً از یک ابزار تیکت یا inbox متمرکز میگذرد. بههوک یونیوم، پیام همهی پیامرسانها را به همان ابزار میدهد؛ تیم یک جا پاسخ میدهد.
Chatwoot
پیام ایتا، بله و تلگرام در یک inbox واحد Chatwoot مینشیند؛ مکالمات همانجا بسته میشوند و SLA قابل اندازهگیری است.
Zendesk
هر پیام ورودی یک تیکت با اولویت میسازد؛ وضعیت تیکت و پاسخ نهایی بهصورت خودکار به مخاطب اطلاع داده میشود.
Freshdesk
مکالمه را به تیکت Freshdesk نگاشت کنید و پاسخهای آماده را با sendMessage روی پیامرسان ترجیحی کاربر بفرستید.
نقطهی اتصال داخلی
بدون ابزار خارجی هم میشود: صفحهی پشتیبانی و بههوک یونیوم همان دو گوشهایاند که تیم را به پیامرسانها میدوزند.
قبل از اتصال، دامنهی ارسال هر پیامرسان را در صفحهی همان پلتفرم ببینید؛ همه پلتفرمها از گفتوگوی دوطرفه کامل پشتیبانی نمیکنند.
پشتیبانی چندپیامرسانی را با یک صف شروع کنید
یک حساب آزمایشی وصل کنید، وبهوک را در Playground تست کنید و اولین تیکت را از یک پیام واقعی بسازید. هزینه پنهانی نیست؛ فقط مصرف واقعی.