یادآوری مصاحبه زمانبندیشده
دو یادآوری از پیش تعیینشده: ۲۴ ساعت قبل (زمان + لینک جلسه) و ۱ ساعت قبل (یادآوری کوتاه). در صف بماند، نه در cron که با ریاستارت گم میشود.
یادآوری مصاحبه و پیام مرحله را از داخل ATS بفرستید، نه از ایمیل
داوطلب استفادهکننده نهایی، پیام استخدامی را در صندوق ورودی ایمیل یا یک SMS ناشناس نمیبیند؛ آن را در بله، ایتا یا روبیکا میبیند. یونیوم تغییر مرحله در ATS را به یک درخواست sendMessage روی پیامرسان تبدیل میکند، با همان قالب آشنای Telegram Bot API، تا هماهنگکننده استخدام دیگر بین ایمیل، تلفن و سه پنل پیامرسان جابهجا نشود.
۲ یادآوری مصاحبه
۱ callback تأیید
۱ پرونده داوطلب
۱ API مشترک
یادآوری مصاحبهزمانبندیشده، ۲۴ ساعت و ۱ ساعت قبل از جلسه
تغییر مرحله«به مرحله فنی رفتید» بهصورت خودکار از ATS
درخواست مدارکsendDocument برای سوابق و رزومه بهروز
پاسخ داوطلبتأیید/لغو از وبهوک، ثبت در همان پرونده
داوطلب در همان پنجرهای میافتد که کمترین توجه را دارد
یک فرایند جذب متوسط پنج مرحله دارد: بررسی رزومه، تماس اول، مصاحبه فنی، مصاحبه نهایی و پیشنهاد. در هر مرحله، یک هماهنگکننده باید زمان را با داوطلب چکه کند، یادآوری بفرستد و اگر داوطلب نیامد (no-show)، دوباره دستوپا کند. این کار امروز روی سه کانال پخش شده: تماس تلفنی که جواب نمیدهد، ایمیلی که در تب promotional گیر میکند، و یک پیامرسان که داوطلب ترجیح میدهد اما تیم استخدام به آن دسترسی برنامهای ندارد.
نتیجه این میشود: نرخ no-show بالا، تأخیر در پاسخ داوطلب، و مهمتر از همه — یک سیستم سایه. وقتی هماهنگکننده از تلفن شخصی یا اکانت بله خودش پیام میدهد، آن گفتوگو در ATS ثبت نمیشود و تیم استخدام یک تصویر ناقص از وضعیت داوطلب دارد.
- ایمیل یادآوری در تب promotional یا spam گیر میکند؛ SMS روی موبایل شخص اول مینشیند و نرخ بازخوانی پایینی دارد.
- تماس تلفنی بین جلسات هماهنگکننده قطع میشود؛ یک پیام کوتاه قابللغو بهتر از یک تماس جانرفته است.
- اگر گفتوگو در پیامرسان شخصی هماهنگکننده بماند، ATS منبع حقیقت نیست؛ لاگ ارتباط گم میشود.
- هر پیامرسان API و قواعد جدا دارد؛ نگهداری پنج کلاینت برای تیم استخدام توجیه ندارد.
از تغییر مرحله در ATS تا یادآوری روی گوشی داوطلب
چهار گام مشخص: ATS رویداد را emit میکند، یک worker درخواست میسازد، یونیوم آن را روی پیامرسان میفرستد، پاسخ داوطلب از وبهوک به همان پرونده برمیگردد. منطق «چه پیامی، چه زمانی» در ATS شماست؛ یونیوم فقط لایه ارسال و دریافت را یکسان میکند.
۱. رویداد مرحله در ATS
داوطلب وارد مرحله «مصاحبه فنی» میشود. ATS یک رویداد با candidate_id، stage، زمان جلسه و شناسه پیامرسان داوطلب (که هنگام ثبت نام گرفته شده) emit میکند. این رویداد نه پیام است، نه وبهوک؛ فقط یک تغییر وضعیت.
۲. ساخت درخواست و زمانبندی
یک worker داخل محصول، متن پیام را از قالب مرحله میسازد و دو یادآوری را در صف میگذارد: یکی ۲۴ ساعت قبل، یکی ۱ ساعت قبل. فقط base_url روی https://api.uniom.ir/bot است؛ همان کلاینت تلگرام فعلیتان کار میکند. chat_id شناسه داوطلب روی پیامرسان مقصد است.
۳. ارسال و لاگ تحویل
یونیوم درخواست sendMessage را با حساب مجاز استخدام روی بله/ایتا/تلگرام میفرستد. هر ارسال یک message_id برمیگرداند و وضعیت تحویل در لاگ ثبت میشود. اگر خطایی رخ دهد (INVALID_AUTH، PEER_FLOOD، تایماوت)، بهجای موفقیت جعلی، خطای واقعی برمیگردد تا worker بتواند retry یا escalation کند.
۴. پاسخ داوطلب از وبهوک
داوطلب روی دکمه inline keyboard میزند («تأیید میآیم» / «جابهجا کنیم»). پاسخ بهصورت callback_query از وبهوک یونیوم به worker میرسد. worker با candidate_id آن را به پرونده ATS وصل میکند، وضعیت را بهروز میکند و در صورت لزوم یک پیام تأیید برمیگرداند. تایماوت وبهوک ۱۰ ثانیه است؛ پردازش سنگین را در صف داخلی بگذارید.
اگر داوطلب در زمان جلسه نیامد (no-show)، یک گردشکار زمانبندیشده ۱۵ دقیقه بعد از جلسه یک پیام پیگیری میفرستد: «نرسیدید؟ زمان دیگری را هماهنگ کنیم». این همان جایی است که اکثر تیمهای استخدام بهخاطر پیگیری دستی آن را از دست میدهند.
قطعات مشخصی که یک جریان جذب واقعی نیاز دارد
هر قابلیت یک متد یا الگوی مشخص از Bot API است، نه یک ادعای مبهم «اتوماسیون استخدام». اینها پایهایترین قطعات هستند؛ بقیه در محصول شما با چسبیدن اینها ساخته میشود.
اطلاعرسانی تغییر مرحله
وقتی داوطلب به مرحله بعد میرود، یک پیام کوتاه و شفاف: «به مرحله فنی رفتید؛ تا ۴۸ ساعت یک ایمیل دعوت دریافت میکنید». متن از قالب مرحله در ATS ساخته میشود.
درخواست مدارک و سوابق
دعوت به ارسال رزومه بهروز، نمونه کار یا اسناد. فایلها از sendDocument/sendPhoto دریافت میشوند و به پرونده داوطلب وصل میشوند — نه به صندوق ایمیل شخصی هماهنگکننده.
تطبیق داوطلب (phone → messenger)
شماره موبایل داوطلب در ثبتنام گرفته شده؛ یونیوم از آن برای رسیدن به chat_id روی پیامرسان مقصد استفاده میکند. مسیر انسانمحور، نه «شناسه ناشناس».
دکمه تأیید/لغو و callback
inline keyboard برای «میآیم» / «جابهجا کنیم» / «لغو». پاسخ بهصورت callback_query از وبهوک برمیگردد و مستقیم وضعیت جلسه را در ATS بهروز میکند.
لاگ ارتباط در پرونده
هر پیام ارسالی و دریافتی با candidate_id و stage در لاگ یونیوم ثبت میشود. این لاگ را به ATS وصل کنید تا سابقه گفتوگو قابل بازبینی و قابل دفاع بماند.
هر قابلیت روی هر پیامرسان یک شکل نیست
API واحد به معنی برابری همه قابلیتها نیست. این تفاوتها واقعی هستند و بهتر است قبل از طراحی جریان، در انتخاب پلتفرم لحاظ شوند. تفاوت قابلیت پلتفرمها در صفحات ارائهدهنده شفاف باقی میماند.
یادآوری متنی + دکمه تأیید
روی همه پیامرسانها قابل ارسال است. inline keyboard و callback_query روی تلگرام و بله (با بازو) پختهتر است؛ روی لایه account ایتا، سروشپلاس و روبیکا به نسخه اتصال وابسته است — قبل از مهاجرت، در Playground تست کنید.
ارسال لینک جلسه (Google Meet / جیتسی)
همه پیامرسانها لینک را بهصورت متن میپذیرند. روی تلگرام و بله، لینک به یک preview تبدیل میشود؛ روی ایتا و روبیکا فقط متن. این تفاوت در طراحی قالب پیام مؤثر است.
دریافت فایل (رزومه، نمونه کار)
از sendDocument در جهت ورودی، کاربر فایل را میفرستد و یونیوم آن را در وبهوک تحویل میدهد. روی تلگرام و بله پایدار است؛ روی حسابهای کاربری ایتا و روبیکا محدودیت حجم و نوع فایل واقعی دارد — حجم بالا را تست کنید.
پیگیری no-show (زمانبندیشده)
یک پیام ۱۵ دقیقه بعد از جلسه از دست کاری خارج نمیشود؛ باید در صف تأخیردار باشد. منطق صف در محصول شماست؛ یونیوم فقط ارسال را انجام میدهد و خطا را برمیگرداند.
دعوت انبوه به رویداد استخدام
روی پیامرسانهای حسابمحور (ایتا، سروشپلاس، روبیکا) شکننده است و ریسک مسدود شدن دارد. دعوت انبوه را فقط با رضایت صریح، حجم پایین و فاصله بین پیامها امتحان کنید؛ اولویت با پیام تراکنشی (یکبهیک) است.
وضعیت تحویل قابل اتکا
تلگرام و بله رسید خواندهشدن میدهند؛ پیامرسانهای حسابمحور معمولاً فقط «ارسال شد». برای آنها، لاگ ارسال یونیوم را منبع حقیقت بدانید، نه read receipt — مخصوصاً وقتی میخواهید no-show واقعی را از «پیام نرسیده» تشخیص دهید.
کارهایی که حساب استخدام را به ریسک میاندازد
بخش بزرگی از ریسک این راهکار از خود پیامرسان نمیآید، از نحوه استفاده میآید. سه الگوی زیر شایعترین علت قطع سرویس یا از دست رفتن داده در ادغام ATS هستند.
تبدیل پیامرسان به سیستم سایه
اگر هماهنگکننده از حساب شخصی خودش به داوطلب پیام میدهد و آن گفتوگو در ATS ثبت نمیشود، بعداً تیم استخدام نمیداند چه گفته شده. همیشه پاسخ را از وبهوک یونیوم به پرونده وصل کنید.
دعوت انبوه بدون رضایت
ارسال دعوت به رویداد استخدام به لیست بزرگی از داوطلبان، روی حسابهای کاربری ایتا/روبیکا/سروشپلاس میتواند به PEER_FLOOD یا مسدود شدن حساب منجر شود. دعوت انبوه را فقط با رضایت صریح و حجم پایین بفرستید.
نبود مسیر لغو
اگر داوطلب راه سادهای برای لغو دریافت پیام ندارد، شما را report میکند. یک دکمه «دیگر نیازی نیست» در inline keyboard کافی است؛ نبودش، بهویژه برای داوطلبانی که رد شدهاند، ریسک گزارش است.
مخلوط کردن ATS و کمپین بازاریابی
پیام «تغییر مرحله» تراکنشی و کمریسک است؛ دعوت به «سمینار استخدامی» بازاریابی و پرریسک. آنها را با حساب یا کلید API جدا کنید تا یک اشتباه در بازاریابی، اتصال ATS را قطع نکند.
رضایت داوطلب برای دریافت پیام ارتباطی، مسئولیت محصول شماست، نه یونیوم. در فرم ثبتنام، مسیر ترجیحی (ایمیل/پیامرسان/هیچکدام) و موافقت به دریافت یادآوری را بپرسید و در پرونده ATS ذخیره کنید. yونیوم فقط ارسال میکند؛ رضایت را شما ثبت میکنید.
برای هر نوع پیام جذب، کدام پیامرسان میچسبد
انتخاب بر اساس هدف پیام، نه فقط نام آشنا. این قابلیتها روی همه credentialها معنی یکسان نیست؛ جدول هر پلتفرم را قبل از راهاندازی بخوانید.
تلگرام و بله برای یادآوری با دکمه تأیید/لغو بهترین انتخاباند (قالب Bot API کامل، inline keyboard پایدار)؛ ولی تلگرام بهخاطر فیلترینگ به دسترسی VPN داوطلب وابسته است. ایتا، روبیکا و سروشپلاس برای رسیدن به داوطلب داخلی بدون فیلتر قویاند، ولی برای دکمه و مدیا به لایه account وابستهاند و در حجم انبوه ریسک مسدود شدن دارند. بله، با داشتن هم بات رسمی (بازو) و هم حساب کاربری، کاندید طبیعی برای فرایند استخدام رسمیتر است. اینستاگرام و واتساپ در نقشه راه هستند و «بهزودی».
قبل از اولین دعوت واقعی، اینها را ببندید
این فهرست همان چیزی است که تیمهای باسابقه قبل از فعالسازی کامل انجام میدهند. رد کردن قدمهای اول و ششم، شایعترین علت قطع سرویس یا از دست رفتن سابقه ارتباط است.
- حساب استخدام جداگانه روی یک پیامرسان وصل کنید — نه حساب شخصی هماهنگکننده.
- در فرم ثبتنام داوطلب، مسیر ترجیحی (ایمیل/پیامرسان/هیچکدام) و موافقت به دریافت یادآوری را بپرسید و در پرونده ATS ذخیره کنید.
- کلید API با scope محدود بسازید؛ کلید ارسال دعوت را از کلید دریافت پاسخ جدا کنید.
- وبهوک ورودی را روی HTTPS با تأیید سریع راه بیندازید؛ پردازش سنگین را در صف داخلی بگذارید تا تایماوت ۱۰ ثانیه نخورید.
- صف زمانبندی یادآوری را داخلی بسازید؛ دو یادآوری (۲۴ ساعت و ۱ ساعت قبل) و یک پیگیری no-show (۱۵ دقیقه بعد) را در همان صف بگذارید.
- شناسه پیام ورودی را بهعنوان کلید idempotency ذخیره کنید تا تکرار وبهوک دو بار وضعیت جلسه را تغییر ندهد.
- لاگ ارسال و خطا را به
candidate_idوstageدر ATS وصل کنید تا سابقه ارتباط قابل بازبینی بماند. - قبل از حجم کامل، با ۲۰–۵۰ داوطلب آزمایشی محدودیت نرخ و تحویل هر پیامرسان را بسنجید.
پیامرسان یک کانال است، نه سیستم ثبت
اشتباه بزرگ در ادغام ATS با پیامرسان، این است که پیامرسان جایگزین پرونده میشود. قرار نیست داوطلب در بله گزارش کامل پیشینه خودش را ببیند؛ قرار است یک کانال سریع برای یادآوری، تأیید و درخواست مدارک باشد. منبع حقیقت — وضعیت مرحله، تاریخچه تصمیمها، امتیاز مصاحبه — همیشه ATS شماست.
ATS منبع وضعیت است
وضعیت مرحله، نتیجه مصاحبه و تصمیم نهایی در ATS ثبت میشوند. یونیوم فقط آنچه ATS emit کرده را به پیام تبدیل میکند؛ هرگز برعکس.
پیامرسان کانال ارتباط است
یادآوری، تأیید، لغو و درخواست مدارک از پیامرسان میروند. پاسخ داوطلب از وبهوک به ATS برمیگردد و وضعیت را بهروز میکند، نه اینکه در چت گم شود.
لاگ ارتباط، پل بین دو سامانه
هر پیام ارسالی و دریافتی با candidate_id در لاگ یونیوم ثبت میشود. این لاگ به ATS وصل میشود تا تیم استخدام یک تصویر کامل از «چه گفته شد» داشته باشد — قابل بازبینی، قابل دفاع.
ATS، فرم و شیت در کنار پیام
جریان استخدام معمولاً در سه جا زندگی میکند: ATS، فرمها و شیتها. بههوک یونیوم همان رویداد ورودی را به هر سه میدهد و یادآوریها از یک جا میروند.
ATS با API
بههوک یونیوم پروندهی داوطلب را در ATS میسازد و مرحلهی مصاحبه با دکمه تأیید/لغو از inline keyboard به ATS برمیگردد.
Google Forms
پاسخ فرم استخدام یک پیام تأیید به داوطلب میفرستد؛ پیام جدید در شیت پاسخها ردیف میسازد.
Google Sheets
داشبورد سادهی استخدام: ردیف هر داوطلب با chat_id یکتا، ستون وضعیت که تیم بهروزرسانی میکند.
تقویم و یادآوری
نوبت مصاحبه یک روز قبل با پیام به داوطلب و استخدامکننده یادآوری میشود؛ هر دو از یک کلید محدود.
یادآوری را همیشه با دکمهی تأیید/لغو بفرستید؛ اگر داوطلب پاسخ نداد، بههوک با callback_query وضعیت را برای مرحلهی بعد نگه میدارد.
از یک رویداد مرحله شروع کنید
یادآوری مصاحبه را روی یک پیامرسان وصل کنید، نتیجه را روی چند داوطلب آزمایشی ببینید، بعد مرحلهها و کانالهای دیگر را اضافه کنید.