خودکارسازی ارتباط با مشتری با اتصال CRM و سایت به سامانه پیامکی
مشتری فرم سایت را پر کرده، اما نمی داند درخواستش ثبت شده یا نه. کارشناس فروش هم شماره را از سایت به CRM منتقل می کند و دستی پیام می فرستد. اتصال سایت به سامانه پیامکی باید همین کار مشخص را خودکار کند: ثبت درخواست، ارسال تأیید و نمایش نتیجه در پرونده مشتری.
ابتدا روش اتصال را انتخاب و یک سناریو را کامل اجرا کنید؛ فعال کردن چند گردش پیامکی هم زمان، عیب یابی را سخت تر می کند.
روش اتصال را با توجه به سایت و CRM انتخاب کنید
برای اتصال سایت به سامانه پیامکی، از جدول زیر شروع کنید. ملاک انتخاب، رویدادی است که می خواهید خودکار کنید؛ صرفاً داشتن حساب پیامکی کافی نیست.
|
وضعیت پروژه |
روش پیشنهادی |
قبل از اجرا چه چیزی را بررسی کنید |
|
سایت وردپرسی با نیازهای معمول |
افزونه سازگار با سرویس پیامکی |
پشتیبانی از فرم یا وضعیت سفارش موردنظر |
|
سایت اختصاصی با بک اند |
اتصال مستقیم API |
احراز هویت و ارسال و دریافت وضعیت |
|
CRM دارای اتصال پیامکی آماده |
تنظیم اتصال و گردش کار |
سرویس های پشتیبانی شده و گزارش خطا |
|
CRM دارای Webhook |
واسط میان CRM و API پیامک |
رویداد تغییر مرحله و اصالت درخواست |
|
CRM فاقد Webhook ولی دارای API خواندن تغییرات |
بررسی دوره ای توسط واسط |
دسترسی به تغییرات و کنترل ارسال مجدد |
پیشنهاد شروع: اگر فرم مشاوره دارید، ابتدا فقط تأیید ثبت درخواست را خودکار کنید. با همین سناریو می توانید ذخیره اطلاعات، ارسال پیام و ثبت گزارش را آزمایش کنید.
چه زمانی افزونه کافی است
افزونه وقتی مناسب است که رویداد شما را پوشش دهد. مثلاً افزونه سفارش فروشگاه، ممکن است از فرم اختصاصی درخواست دمو پشتیبانی نکند.
در اتصال سایت به سامانه پیامکی با افزونه، یک سفارش آزمایشی ثبت کنید. وضعیت را تغییر دهید و گزارش ارسال را ببینید. اگر دو افزونه برای همان وضعیت پیام می فرستند، یکی از گردش ها را غیرفعال کنید. مشتری به دو رسید یکسان نیاز ندارد!
چه زمانی API یا واسط لازم است
در سایت اختصاصی، سفارش و پشتیبانی از یک سرویس مشترک ارسال در بک اند استفاده کنند تا مدیریت خطا متمرکز بماند.
واسط می تواند رویداد CRM را دریافت کند. وجود Webhook به معنی آماده بودن اتصال نیست؛ دریافت کننده امن، بررسی شرایط و ثبت نتیجه همچنان لازم است.
قبل از دریافت کلید API این موارد را مشخص کنید
قبل از اتصال سایت به سامانه پیامکی، یک برگه نیازمندی کوتاه بنویسید: چه اتفاقی رخ می دهد، چه کسی پیام می گیرد، چه متنی ارسال می شود و کدام سیستم مسئول ارسال است.
بعد، در مستندات یا از پشتیبانی بپرسید:
-
آیا روش ارسال انتخابی، پیام خدماتی موردنظر شما را پشتیبانی می کند؟
-
آیا الگو باید تأیید شود و متغیرهای آن چه محدودیتی دارند؟
-
آیا شناسه پیام و استعلام وضعیت در دسترس است؟
-
آیا کنترل تکرار درخواست یا شناسه ارجاع مشتری پشتیبانی می شود؟
-
هزینه پیام چندبخشی و محدودیت سرعت ارسال چگونه محاسبه می شود؟
خدمت وب سرویس پیامکی در صفحه https://payam-resan.com/web-service/ معرفی شده است. نیازهای سناریو را با مستندات و امکانات قابل ارائه تطبیق دهید.
متن نهایی را آزمایش کنید. نام طولانی یا لینک می تواند تعداد بخش ها و هزینه را تغییر دهد. محاسبه را با متغیرهای جایگزین شده انجام دهید.
یک درخواست مشاوره را از سایت تا CRM خودکار کنید
فرض کنید نرم افزار حسابداری می فروشید. مشتری فرم دمو را پر می کند و کارشناس جلسه می گذارد. با این مثال، مسیر اتصال سایت به سامانه پیامکی را اجرا می کنیم.
مرحله اول درخواست را ذخیره کنید و بعد پیام بسازید
پیام تأیید را با کلیک روی دکمه فرم نفرستید. ابتدا اطلاعات را در سرور اعتبارسنجی و درخواست را ذخیره کنید. رویداد ارسال باید از ثبت موفق اطلاعات ساخته شود.
برای اتصال سایت به سامانه پیامکی، حداقل شناسه درخواست، شماره موبایل و نوع پیام را نگه دارید. شماره را طبق قالب API یکسان سازی کنید؛ فاصله اضافی و ارقام فارسی را نیز مدیریت کنید.
نمونه پیام آماده:
درخواست معرفی نرم افزار شما با کد {کدپیگیری} ثبت شد. کارشناسان در بازه {زمانپاسخگویی} با شما تماس می گیرند.
زمان پاسخ گویی را با برنامه تیم هماهنگ کنید؛ وعده تماس غیرقطعی ندهید.
مرحله دوم ارسال را به پردازش پس زمینه بسپارید
در اتصال سایت به سامانه پیامکی، کاربر نباید منتظر پاسخ سرویس پیامک بماند. پس از ثبت درخواست، نتیجه ثبت را نمایش دهید و ارسال را در پس زمینه انجام دهید.
برای جلوگیری از جا افتادن پیام بین ذخیره درخواست و ایجاد کار ارسال، می توانید از جدول Outbox استفاده کنید. درخواست مشتری و رویداد پیام را در یک تراکنش پایگاه داده ذخیره کنید. پردازشگر، رویدادهای انجام نشده را می خواند و نتیجه تلاش را ثبت می کند.
Outbox کار ارسال را پس از قطع برنامه قابل پیگیری نگه می دارد؛ تحویل پیامک را تضمین نمی کند. اجرای مجدد نیز باید کنترل شود.
مرحله سوم برای هر پیام یک مسئول تعیین کنید
یکی از دردسرهای اتصال سایت به سامانه پیامکی، فعال بودن ارسال در سایت و CRM برای یک اتفاق است. سایت پیام تأیید می فرستد و CRM هم ورود سرنخ را با پیام دیگری پاسخ می دهد.
تقسیم مسئولیت را روشن کنید:
-
سایت: تأیید ثبت درخواست دمو.
-
CRM: اعلام زمان جلسه و پیگیری پیشنهاد فروش.
-
زمان بند: یادآوری جلسه فعال.
شناسه درخواست سایت را در CRM نگه دارید تا انتقال مجدد، پرونده تکراری نسازد.
مرحله چهارم پیام را از وضعیت فعلی پرونده بسازید
بعد از تعیین زمان جلسه، رویداد تأیید جلسه را ایجاد کنید. صرف باز شدن صفحه ویرایش پرونده، دلیل ارسال پیام نیست.
نمونه متن:
جلسه معرفی نرم افزار برای {تاریخ} ساعت {ساعت} ثبت شد. برای تغییر زمان با {شمارهتماس} تماس بگیرید.
اتصال سایت به سامانه پیامکی زمانی کاربردی است که تغییرات را هم پوشش دهد. اگر جلسه جابه جا شد، یادآوری قبلی را لغو یا به روزرسانی کنید. پیش از ارسال، دوباره بررسی کنید جلسه فعال است؛ پیام یادآوری جلسه لغوشده فقط تماس پشتیبانی می سازد.
مرحله پنجم ارسال دوباره را کنترل کنید
برای هر پیام منطقی، شناسه ای مانند demo:8421:confirmation بسازید و در پایگاه داده محدودیت یکتا بگذارید. اجرای دوباره همان رویداد نباید کار ارسال تازه ای ایجاد کند.
اما در اتصال سایت به سامانه پیامکی، یک حالت مبهم باقی می ماند: سرویس درخواست را پذیرفته، ولی پاسخ به برنامه شما نرسیده است. Timeout الزاماً یعنی ارسال ناموفق نیست.
به نقل از Microsoft Learn:
Otherwise, retries could cause the operation to be executed more than once, with unintended side effects.
ترجمه: در غیر این صورت، تلاش های مجدد ممکن است باعث شوند عملیات بیش از یک بار اجرا شود و پیامدهای ناخواسته داشته باشد.
منظور، عملیاتی است که تکرارش اثر تازه ای دارد. پیش از ارسال دوباره، از استعلام یا کنترل تکرار ارائه دهنده استفاده کنید. در نبود این امکانات، وضعیت را «نامشخص» نگه دارید و مسیر بررسی تعیین کنید.
مرحله ششم نتیجه را در پرونده مشتری نمایش دهید
خروجی اتصال سایت به سامانه پیامکی باید برای کارشناس قابل استفاده باشد. کنار درخواست دمو، نوع پیام، زمان ارسال، شناسه ارائه دهنده و وضعیت را نمایش دهید.
پذیرش درخواست با تحویل به گوشی فرق دارد. وضعیت نهایی را با Webhook یا استعلام، مطابق امکانات سرویس، دریافت کنید. گزارش تحویل نیز اثبات نمی کند مشتری پیام را خوانده است.
اگر گزارش چند بار رسید، فعالیت تکراری نسازید. به روزرسانی را بر اساس شناسه پیام انجام دهید و وضعیت های سرویس را طبق مستندات تفسیر کنید.
اگر پیامک نرسید از کجا عیب یابی کنید
در عیب یابی اتصال سایت به سامانه پیامکی، مسیر یک درخواست مشخص را دنبال کنید؛ ارسال چندباره پیام آزمایشی، علت مشکل را نشان نمی دهد.
|
چیزی که می بینید |
بررسی بعدی |
اقدام |
|
هیچ کار ارسالی ساخته نشده |
اجرای رویداد و شرط آن |
بررسی ثبت موفق و وضعیت پرونده |
|
کار ارسال در صف مانده |
وضعیت پردازشگر |
بررسی توقف سرویس و خطای پردازش |
|
درخواست رد شده |
کد و توضیح خطای API |
اصلاح کلید یا گیرنده یا متغیرها |
|
پاسخ دریافت نشده |
احتمال پذیرش درخواست |
استعلام پیش از ارسال مجدد |
|
شناسه پیام وجود دارد |
گزارش وضعیت |
پیگیری طبق وضعیت اعلام شده |
خطای داده نامعتبر را با Retry حل نکنید. برای خطای موقت، تعداد تلاش ها محدود باشد و فاصله آن ها افزایش پیدا کند. محدودیت اعلام شده سرویس را نیز رعایت کنید.
برای پیام زمان دار، مهلت اعتبار بگذارید؛ یادآوری منقضی را نفرستید.
کلید API را در مرورگر و آدرس قرار ندهید
در اتصال سایت به سامانه پیامکی، درخواست را از سرور بفرستید. کلید نباید در فایل JavaScript، مخزن کد یا گزارش عمومی قرار بگیرد. احراز هویت را طبق مستندات سرویس و از طریق HTTPS انجام دهید.
به نقل از OWASP:
Passwords, security tokens, and API keys should not appear in the URL
ترجمه: رمزهای عبور و توکن های امنیتی و کلیدهای API نباید در آدرس URL قرار بگیرند.
نکته عملی این است که آدرس درخواست ممکن است در گزارش سرور ثبت شود. روش احراز هویت مبتنی بر هدر یا بدنه را، مطابق پشتیبانی API، انتخاب کنید. دسترسی به گزارش ها را محدود کنید و شماره ها و داده حساس را به اندازه نیاز نگه دارید.
پیش از فعال سازی این پنج آزمون را انجام دهید
برای تحویل اتصال سایت به سامانه پیامکی، فقط رسیدن یک پیام کافی نیست. این حالت ها را آزمایش کنید:
-
فرم دوبار ثبت شود: برای همان درخواست، پیام و پرونده تکراری ساخته نشود.
-
پردازشگر دوباره اجرا شود: همان رویداد، کار ارسال جدید نسازد.
-
پاسخ سرویس قطع شود: وضعیت مبهم با شکست قطعی اشتباه گرفته نشود.
-
جلسه لغو شود: یادآوری قبلی ارسال نشود.
-
گزارش دوباره برسد: تاریخچه CRM تکراری نشود.
ابتدا سناریو را محدود فعال کنید. درخواست ها و کارهای ارسال را تطبیق دهید و علت موارد بدون پیام را مشخص کنید.
سوالات متداول
سایت وردپرسی دارم ولی فرم اختصاصی من پیامک نمی فرستد
بررسی کنید افزونه از همان فرم و رویداد ثبت موفق پشتیبانی می کند. اتصال به سرویس پیامکی به تنهایی کافی نیست. اگر رویداد پشتیبانی نمی شود، باید از اتصال سازگار با فرم یا توسعه سمت سرور استفاده کنید.
چرا بعد از اتصال CRM مشتری دو پیام یکسان می گیرد
احتمالاً سایت و CRM هر دو برای یک رویداد ارسال دارند یا رویداد دوباره پردازش شده است. مسئول هر پیام را تعیین کنید و شناسه یکتا را ذخیره کنید. سپس گزارش دو ارسال را با شناسه درخواست تطبیق دهید.
API پاسخ نداده است آیا پیام را دوباره بفرستم
ابتدا احتمال پذیرش درخواست را بررسی کنید. پاسخ نرسیدن، اثبات ارسال نشدن نیست. از استعلام یا کنترل تکرار سرویس استفاده کنید؛ در نبود این امکانات، ارسال خودکار مجدد می تواند پیام تکراری ایجاد کند.
اگر مشتری جلسه را لغو کند یادآوری چگونه متوقف می شود
کار زمان بندی شده را لغو یا به روزرسانی کنید و درست پیش از ارسال، وضعیت جلسه را دوباره بخوانید. بررسی وضعیت هنگام ساخت یادآوری کافی نیست؛ ممکن است پرونده بعداً تغییر کرده باشد.
اجرای اتصال را از یک پیام مشخص شروع کنید
برای اتصال سایت به سامانه پیامکی، نوع سایت، نام CRM و یک سناریوی اولیه مانند تأیید درخواست دمو را مشخص کنید. سپس متن، مسئول ارسال و روش ثبت نتیجه را تعیین کنید.
برای بررسی مسیر اتصال پروژه خود، درخواست مشاوره ثبت کنید. این سه اطلاعات را همراه داشته باشید تا مشخص شود افزونه کافی است یا به API و واسط نیاز دارید؛ سپس اجرای اولیه را با همان سناریوی قابل آزمایش شروع کنید.




