ساعت ۹ شب، تیم پشتیبانی یک فروشگاه اینترنتی میان سه پنل جابهجا میشود: رسید پرداخت در بله رسیده، پرسش بعدی در تلگرام است و پیگیری ارسال در روبیکا. روزانه ۲۰۰ گفتوگو از این مسیرها میگذرد و هیچکدام کنار هم نیستند. برای مشتری، همه اینها ادامه ارتباط با یک فروشگاه است؛ برای تیم فنی، چند پیامرسان با چند روش اتصال، چند ساختار پیام و چند رفتار خطا.
یونیوم بستری برای اتصال نرمافزارها به چند پیامرسان است. بهجای آنکه برای تلگرام، بله، ایتا، روبیکا یا سروشپلاس چند اتصال جدا بسازید، میتوانید بخش مشترک ارسال و دریافت پیام را از یک مسیر پیش ببرید و منطق اصلی محصول را در سیستم خودتان نگه دارید.
این تعریف کوتاه است، اما هنوز مسئلهای را که یونیوم حل میکند بهخوبی نشان نمیدهد. اگر این اتصالها جدا از هم ساخته شوند، سابقه گفتوگو در چند جا پخش میشود، تیم پشتیبانی نمیداند هر پیام به کدام سفارش مربوط است و یک تغییر ساده در روند پاسخگویی باید در چند بخش مختلف تکرار شود. یونیوم برای کم کردن همین پراکندگی ساخته شده است.
مشکل از پیامرسان دوم شروع میشود
برای یک ربات کوچک، اتصال مستقیم به API همان پیامرسان میتواند انتخاب خوبی باشد. توکن را میگیرید، چند متد را فراخوانی میکنید و کار راه میافتد. این انتخاب تا وقتی ربات تکپیامرسانه است ارزان میماند؛ از پیامرسان دوم به بعد، هر قابلیت مشترک باید در هر اتصال جداگانه تست شود و خطای یک اتصال فقط در همان بکاند دیده میشود. پیچیدگی از جایی آغاز میشود که پیامرسان دوم به محصول اضافه میشود.
حالا باید همان منطق ارسال و دریافت را دوباره بنویسید، خطاهای تازه را بشناسید، وضعیت اتصال دیگری را زیر نظر بگیرید و پاسخهای آن پیامرسان را به ساختار داخلی خودتان تبدیل کنید. با اضافه شدن پیامرسان سوم، این دوبارهکاری بیشتر هم میشود.
هزینه فقط نوشتن چند درخواست تازه نیست. بخشی از اطلاعات در یک پروژه میماند، بخشی در پروژه دیگر و بخشی در پنلهایی که تیم پشتیبانی هر روز میان آنها جابهجا میشود. پس از مدتی، تغییر متن پیام، افزودن یک مرحله به روند خرید یا سپردن گفتوگو به پشتیبان، به اصلاح چند پیادهسازی جدا نیاز دارد.
در چنین وضعی، تیم بهجای بهتر کردن محصول، وقتش را صرف هماهنگ کردن تفاوت پیامرسانها میکند.
یونیوم دقیقا چه کاری انجام میدهد؟
یونیوم میان نرمافزار شما و پیامرسانها قرار میگیرد و دسترسی به آنها را از راه یک API مشترک فراهم میکند. الگوی این API به Telegram Bot API نزدیک است؛ بنابراین توسعهدهندهای که با متدهایی مانند sendMessage، getUpdates و setWebhook آشناست، برای شروع با مدل کاملا بیگانهای روبهرو نمیشود.
نزدیکی به الگوی تلگرام به معنی یکسان بودن همه پیامرسانها نیست. ممکن است یک پیامرسان دکمه، فایل، برنامک یا رویداد خاصی را به شکل متفاوتی پشتیبانی کند. یونیوم بخشهای مشترک را یکدست میکند و تفاوتهای هر پیامرسان را در بخش اتصال نگه میدارد؛ اما قابلیتی را که در خود پیامرسان وجود ندارد از هیچ نمیسازد.
نکته مهم این است که قواعد سفارش، پشتیبانی و ارتباط با مشتری به یک پیامرسان خاص وابسته نمیماند. نرمافزار شما تصمیم میگیرد چه پیامی، برای چه کسی و در چه زمانی فرستاده شود. یونیوم مسئول رساندن آن پیام از مسیر انتخابشده و برگرداندن پاسخ کاربر به سیستم شماست.
با یونیوم چه چیزهایی میتوان ساخت؟
یونیوم فقط برای ساخت رباتهای ساده نیست. هرجا پیامرسان بخشی از روند کاری یک نرمافزار باشد، میتوان از یک اتصال مشترک استفاده کرد. چند نمونه روشن:
- رباتی که منطق اصلی آن یک بار نوشته میشود و در چند پیامرسان کار میکند؛
- سامانه پشتیبانی که پیامهای بله، تلگرام یا روبیکا را همراه با سابقه مشتری در یکجا نشان میدهد؛
- ارسال خودکار پیام ثبت سفارش، تایید پرداخت، یادآوری نوبت یا تغییر وضعیت ارسال؛
- اتصال پیامهای مشتری به CRM، سفارش، تیکت یا نرمافزار داخلی شرکت؛
- راهاندازی فرایندهای خودکار با ابزارهایی مانند
n8n؛ - دستیار هوشمندی که پرسشهای روشن را پاسخ میدهد و موارد حساس یا مبهم را به پشتیبان میسپارد؛
- افزودن امکان اتصال پیامرسان به نرمافزارهای فروش، پشتیبانی و خدمات سازمانی.
این کاربردها یک وجه مشترک دارند: پیام باید به یک کار مشخص در کسبوکار برگردد. پیام مشتری شاید به یک سفارش، درخواست پشتیبانی، سرنخ فروش یا پرونده مشتری مربوط باشد. اگر فقط متن پیام جابهجا شود اما ارتباط آن با این اطلاعات از بین برود، مسئله اصلی همچنان حل نشده است.
تیم پشتیبانی فقط دریافت پیام را نمیخواهد. باید بداند چه کسی مسئول رسیدگی است، مشتری پیش از این چه گفته، موضوع گفتوگو به کدام سفارش مربوط میشود و چه زمانی باید پاسخ به همکار دیگری سپرده شود.
تیم محصول نیز فقط فرستادن پیام را نمیخواهد. پیامرسان باید بتواند بخشی از روند خرید، پیگیری سفارش، بازگشت کاربر یا دریافت خدمات باشد. تیم فنی هم به چند متد پراکنده نیاز ندارد؛ به اتصالی نیاز دارد که بتوان وضعیت آن را دید، خطاهایش را پیگیری کرد و با بزرگ شدن محصول از نو نوشته نشود.
یونیوم در معماری محصول کجا قرار میگیرد؟
یونیوم جای نرمافزار اصلی شما را نمیگیرد. ثبت نهایی سفارش، اطلاعات مشتری، وضعیت تیکت و قواعد کسبوکار باید در سیستم خودتان باقی بماند. یونیوم بخش ارتباط با پیامرسانها را بر عهده میگیرد: حساب را متصل میکند، پیام را میفرستد، پاسخ را دریافت میکند و آن را به نرمافزار شما برمیگرداند.
برای نمونه، پس از تایید پرداخت، فروشگاه رویداد «پرداخت موفق» را ثبت میکند. سیستم شما متن مناسب را میسازد و از یونیوم میخواهد آن را برای مشتری بفرستد. اگر مشتری پاسخ دهد، پیام دوباره به سیستم فروشگاه یا سامانه پشتیبانی میرسد تا در کنار همان سفارش دیده شود.
در یک سرویس جدی، همچنان باید برای صف پیامها، ارسال دوباره پس از خطا، جلوگیری از پردازش تکراری و ثبت گزارشها تصمیم بگیرید. یونیوم این تصمیمها را بهجای شما نمیگیرد؛ کاری میکند که مجبور نباشید بخش اتصال به هر پیامرسان را جداگانه از نو بسازید.
یونیوم چه چیزی نیست؟
یونیوم CRM، فروشگاه اینترنتی یا سامانه پشتیبانی نیست. جای پشتیبان انسانی را هم نمیگیرد و قرار نیست همه رفتارهای پیامرسانها را کاملا یکسان کند.
اگر فقط یک بازوی کوچک در یک پیامرسان میخواهید و قرار نیست آن را به سفارش، مشتری یا نرمافزار دیگری متصل کنید، استفاده مستقیم از API همان پیامرسان شاید سادهتر باشد. یونیوم زمانی ارزش بیشتری پیدا میکند که ارتباط با کاربر از سطح چند پیام ساده عبور کرده باشد.
یونیوم برای چه تیمهایی مناسب است؟
یونیوم بیشتر بهکار تیمی میآید که یکی از این مسئلهها را دارد:
- کاربرانش در چند پیامرسان حضور دارند؛
- یک ربات تلگرام دارد و میخواهد منطق آن را در پیامرسانهای دیگر هم بهکار بگیرد؛
- پیامهای ورودی باید به سفارش، مشتری، تیکت یا تیم پشتیبانی متصل شوند؛
- میخواهد وضعیت اتصالها و خطاهای ارسال را از یکجا پیگیری کند؛
- نرمافزاری میسازد که باید امکان اتصال پیامرسان را در اختیار کاربران خودش بگذارد.
بهترین شروع، وصل کردن همه پیامرسانها نیست. یک کاربرد محدود انتخاب کنید؛ برای مثال، فرستادن پیام تایید پرداخت و ثبت پاسخ مشتری در کنار سفارش. وقتی این مسیر از ابتدا تا انتها درست کار کرد، افزودن پیامرسان یا کاربرد بعدی بدون بازنویسی زیرساخت قبلی بسیار سادهتر خواهد بود.
وقتی نوبت پیامرسان سوم میرسد، بهجای شمارش متدهای هر API، از خودتان بپرسید: کدام بخش از این ارتباط قرار است دوباره در محصول تکرار شود؟ پاسخ همین سوال، اندازه لایه اتصالی را که نیاز دارید تعیین میکند.