پیام وضعیت سفارش
ثبت، انبار، ارسال و تحویل را با قالب یکسان روی هر پیامرسان بفرستید. متن کوتاه + کد رهگیری کافی است.
پیام فروش را به رویداد واقعی محصول وصل کنید، نه به یک پنل پیامک دیگر
یادآوری پرداخت، وضعیت سفارش و پیگیری سبد رهاشده قرار است به کاربر برسند، نه در پوشه اسپم ایمیل یا یک SMS ناشناس بمانند. یونیوم این پیامها را از داخل محصول شما، روی پیامرسانی که کاربر واقعاً باز میکند، با همان قالب آشنای Telegram Bot API ارسال میکند.
۳ رویداد فروش
۲۴ ساعت یادآوری
۱ API مشترک
۱ لاگ تحویل
سفارش #۴۷۰۲۱«سفارش ثبت شد؛ در حال آمادهسازی»
یادآوری پرداختزمانبندیشده، ۲ ساعت بعد از رها کردن سبد
تحویل«مرسوله تحویل شد» با کد رهگیری
ایمیل به باکس promo میرود، پیامک به علامتگذاری ناخواسته
بیشتر تیمهای فروش برای پیام تراکنشی به ایمیل یا SMS تکیه میکنند و هر دو کانال در ایران پیر است: ایمیل در تب promotional گیر میکند، SMS روی موبایل شخص اول مینشیند و نرخ بازخوانی پایینی دارد. در همان حال کاربر همان روز دهها بار بله، ایتا یا روبیکا را باز میکند. ارزش این کانالها برای فروش تراکنشی مشخص است، اما هر پیامرسان API، کلاینت و قواعد متفاوتی دارد و نگهداری همزمان پنج کلاینت، انرژی تیم محصول را میبلعد.
- پنج پیامرسان یعنی پنج SDK، پنج جریان احراز هویت و پنج مکانیزم وبهوک.
- یادآوری پرداخت زمانمند باید در صف بماند، نه در یک cron ساده که با ریاستارت گم میشود.
- بدون لاگ ارسال و خطا، شکست تحویل پیام دیده نمیشود تا زمانی که کاربر شکایت کند.
- رضایت کاربر (opt-in) و مسیر لغو (opt-out) مسئولیت محصول شماست، نه پیامرسان.
از رویداد محصول تا صندوق ورودی کاربر
سه گام مشخص: رویداد را به یک درخواست تبدیل کنید، درخواست را در صف زمانبندی کنید، نتیجه را لاگ کنید. یونیوم فقط لایه ارسال را یکسان میکند؛ منطق کسبوکار دست شماست.
۱. رویداد را به درخواست تبدیل کنید
یک رویداد داخل محصول (ثبت سفارش، شکست پرداخت، رها کردن سبد) یک درخواست استاندارد sendMessage میسازد. فقط base_url را روی https://api.uniom.ir/bot میگذارید؛ همان کد تلگرام فعلیتان کار میکند. chat_id شناسه کاربر روی پیامرسان مقصد است.
۲. صف، زمانبندی و کنترل نرخ
یادآوری پرداخت را فوری نفرستید؛ آن را در صف بگذارید (مثلاً ۲ ساعت بعد). یونیوم اعتبارنامه و مدیریت نشست را نگه میدارد، اما کنترل نرخ ارسال انبوه بر عهده product شماست تا زیر سقف محدودیت هر پیامرسان بمانید. disable_notification برای پیام بیصدا، parse_mode برای Markdown یا HTML در دسترس است.
۳. تحویل، لاگ و رسید ضعف
هر ارسال یک شناسه پیام برمیگرداند. وضعیت تحویل و خطاهای واقعی (مثل INVALID_AUTH، PEER_FLOOD، timeout وبهوک) در لاگ یونیوم ثبت میشوند. این لاگ را به همراه شناسه سفارش داخلی ذخیره کنید تا وقتی کاربر میپرسد «پیام را نفرستادید»، پاسخ قطعی داشته باشید.
قطعات مشخصی که یک جریان فروش نیاز دارد
هر قابلیت یک متد یا الگوی مشخص است، نه یک قابلیت مبهم «آماده برای فروش».
یادآوری پرداخت زمانمند
صف تأخیردار بسازید؛ پیام فقط برای کاربری که فرایند پرداخت را شروع کرده، بعد از تأخیر مشخص ارسال شود.
بازیافت سبد رهاشده
یک یادآوری حسابی، با یک کد تخفیف محدود. فقط برای کاربرانی که رضایت بازاریابی دادهاند.
مدیریت opt-in و opt-out
ترجیح ارتباطی کاربر را در پایگاهداده خودتان نگه دارید؛ یونیوم فقط ارسال میکند، رضایت را شما ثبت میکنید.
قالب Markdown و HTML
parse_mode آشنای Bot API: متن پررنگ، لینک، لیست و کد را با همان قالب تلگرام رندر کنید.
لاگ تحویل و خطا
شناسه درخواست، نتیجه ارسال و رشته خطا برای هر پیام. قابل اتصال به داشبورد فروش یا سامانه مانیتورینگ.
هر قابلیت روی هر پیامرسان یک شکل نیست
API واحد به معنی برابری همه قابلیتها نیست. این تفاوتها واقعی هستند و بهتر است از روز اول در طراحی جریان لحاظ شوند.
پیام تراکنشی متن + دکمه
همه پیامرسانها پشتیبانی میکنند. inline keyboard برای «پیگیری سفارش» یا «لغو» روی بله و تلگرام پختهتر است؛ روی ایتا، سروشپلاس و روبیکا به لایه account وابسته است.
ارسال فاکتور/رسید (PDF)
از طریق sendDocument. روی تلگرام و بله پایدار است؛ روی حسابهای کاربری ایتا و روبیکا محدودیت حجم و نرخ واقعی دارد؛ همیشه حجم را تست کنید.
درگاه پرداخت دربات
فقط بله با «بازو» و درگاه پرداخت بومی این کار را بهطور رسمی دارد. برای تسویه داخل چت، بله کاندید اصلی است؛ بقیه پیامرسانها پیام را به لینک بیرونی هدایت کنید.
کمپین انبوه بازاریابی
روی پیامرسانهای حسابمحور (ایتا، سروشپلاس، روبیکا) شکننده است و ریسک مسدود شدن دارد. اولویت را به پیام تراکنشی بدهید و بازاریابی را فقط با رضایت صریح و حجم پایین امتحان کنید.
وضعیت تحویل قابل اتکا
تلگرام و بله رسید خواندهشدن میدهند؛ پیامرسانهای حسابمحور معمولاً فقط «ارسال شد». برای آنها لاگ ارسال را منبع حقیقت بدانید، نه read receipt.
صف وبهوک ورودی
پاسخ کاربر (مثلاً «لغو شد» یا «پرداخت کردم») از وبهوک یونیوم میآید. تایماوت وبهوک ۱۰ ثانیه است؛ پردازش سنگین را به صف داخلی بدهید تا تایماوت نخورید.
کارهایی که فروش را به مسدود شدن حساب میکشاند
بخش بزرگی از ریسک این راهکار از خود پیامرسان نمیآید، از نحوه استفاده میآید. این موارد را جدی بگیرید.
ارسال بدون رضایت
بزرگترین علت مسدود شدن حساب. کاربری که پیام بازاریابی نمیخواهد، شما را report میکند و در چند گزارش، حساب محدود میشود.
نادیده گرفتن محدودیت نرخ
هر پیامرسان سقف پیام در دقیقه دارد. ارسال بدون فاصله، PEER_FLOOD یا توقف موقت حساب میآورد؛ بین ارسالها فاصله بیندازید.
بدون مسیر لغو
اگر کاربر راه سادهای برای توقف پیام ندارد، گزارش میدهد. یک دکمه «لغو دریافت» کافی است؛ نبودش گران تمام میشود.
مخلوط کردن تراکنشی و بازاریابی
پیام «وضعیت سفارش» تراکنشی است و کمریسک؛ پیشنهاد تخفیف بازاریابی است و پرریسک. آنها را با حساب یا کلید جدا کنید.
اگر هدف اصلی شما ارسال انبوه بازاریابی بدون رضایت است، این راهکار برایتان ساخته نشده؛ یونیوم برای پیام تراکنشی و پیگیری با رضایت صریح طراحی شده است.
برای هر جریان فروش، کدام پیامرسان میچسبد
ترکیب درست، به هدف پیام بستگی دارد: تراکنشی، بازاریابی یا تسویه دربات.
بله برای تسویه و درگاه پرداخت دربات؛ تلگرام برای مخاطبی که VPN دارد و قالب Bot API کامل میخواهد؛ ایتا، روبیکا و سروشپلاس برای رسیدن به مخاطب داخلی بدون فیلتر — اما با احتیاط در حجم و فقط برای پیام تراکنشی. اینستاگرام و واتساپ در نقشه راه هستند و «بهزودی».
قبل از اولین کمپین واقعی، اینها را ببندید
این فهرست همان چیزی است که تیمهای باسابقه قبل از بالا بردن حجم، انجام میدهند. رد کردن قدم اول و چهارم، شایعترین علت قطع سرویس است.
- حساب آزمایشی روی یک پیامرسان وصل کنید و اولین پیام تراکنشی را در Playground بفرستید.
- کلید API با scope محدود بسازید؛ کلید فروش را از کلید پشتیبانی یا اپراتور جدا کنید.
- وبهوک ورودی را روی HTTPS با تایید سریع راه بیندازید؛ پردازش سنگین را در صف داخلی بگذارید.
- فیلد opt-in را در پرونده مشتری اضافه کنید؛ فقط کاربران دارای رضایت پیام بازاریابی بگیرند.
- لاگ ارسال را به شناسه سفارش داخلی وصل کنید تا شکست تحویل قابل ردیابی بماند.
- قبل از حجم کامل، با یک نمونه ۵۰–۱۰۰ نفری محدودیت نرخ و تحویل هر پیامرسان را بسنجید.
ابزارهای فروش متصل به بههوک
لید از پیام میآید و باید به ابزار فروش برسد. همین که یک بههوک واحد همهی پیامرسانها را جمع کند، پرسونالسازی کانال را از تیم پشتیبانی جدا میکند.
HubSpot CRM
لید پیامرسان با شمارهی کاربر در HubSpot ساخته یا تطبیق میشود؛ فعالیت و ایمیلها کنارش ثبت میشود.
Zendesk Sell
هر گفتوگوی فروش به یک فرصت (Deal) وصل میشود و مرحله با پاسخ دکمهی مخاطب بهروزرسانی میشود.
Google Sheets
فرم سفارش یا پیشفاکتور در شیت؛ ارسال با یک sendMessage و پیگیری پرداخت با دکمهی «پرداخت شد».
Grafana و مانیتورینگ
هشدار رزرو سهمیه یا خطای 429 مستقیم به کانال فروش میرود؛ نه به ایمیلی که هیچکس باز نمیکند.
لیدها را با chat_id تطبیق بدهید نه شمارهی موبایل؛ شماره از API همهی پلتفرمها برنمیگردد.
از یک پیام تراکنشی شروع کنید
یادآوری پرداخت را روی یک پیامرسان وصل کنید، نتیجه را ببینید، بعد حجم و کانالها را اضافه کنید.