چطور فرم تماس سایتم را به CRM یا پیامک وصل کنم؟

یک بازدیدکننده فرم تماس سایت شما را پر می‌کند. این اطلاعات کجا میرود؟ در بسیاری از سایت‌ها، فقط یک ایمیل ساده به صاحب سایت میرسد. بعد کسی باید آن ایمیل را ببیند، اطلاعات مشتری را دستی در CRM وارد کند و شاید یک پیامک هم برایش بفرستد. اگر تعداد فرم‌ها کم باشد، این روش دستی جواب می‌دهد. اما با افزایش تعداد مشتری‌ها، همین کار ساده وقت زیادی میگیرد و گاهی ممکنه از قلم بیوفتد!

این مشکل معمولا یک‌ شبه خودش را نشان نمی‌دهد. در ماه‌های اول، مدیریت دستی چند فرم در روز کاملا قابل‌ کنترل است. اما وقتی تعداد فرم‌ها از چند مورد در روز به چند مورد در ساعت برسد، همان فرآیند ساده وقت زیادی از تیم فروش میگیرد. دلیل این اتفاق پیچیدگی کار نیست؛ تکرار زیاد آن است.

این اتصال دقیقا چطور کار می‌کند؟

وقتی بازدیدکننده فرم سایت شما را ثبت می‌کند، می‌توانید سایت را طوری تنظیم کنید که فورا یک پیام حاوی اطلاعات فرم به آدرس مشخصی برود. این آدرس معمولا متعلق به CRM یا پنل پیامک شماست. به این مکانیزم Webhook می‌گویند. معمولا این پیام شامل فیلدهایی مثل نام، شماره تماس، ایمیل و متن پیام است؛ دقیقا همان اطلاعاتی که کاربر در فرم وارد کرده. سرویس مقصد این پیام را دریافت می‌کند، آن را میخواند و بر اساس اطلاعات ورودی یک کار مشخص انجام می‌دهد. برای مثال، یک مخاطب جدید در CRM می‌سازد یا یک پیامک ارسال می‌کند.

یک مثال واقعی و مشخص

فرض کنید سایت شما را با وردپرس ساخته‌اید و از افزونه‌ی Fluent Forms برای فرم تماس استفاده می‌کنید. این افزونه یکی از پرکاربردترین فرم‌سازهای وردپرسی است. نسخه‌ی حرفه‌ای آن یک ماژول داخلی به نام Webhook دارد که در تنظیمات هر فرم قابل فعال‌ سازی است. کافی است آدرس (URL) سرویس مقصد را در آن وارد کنید. سایت پس از آن، اطلاعات فرم را مستقیما و بدون نیاز به کدنویسی برای همان سرویس می‌فرستد.

حالا فرض کنید می‌خواهید همان لحظه، سیستم یک پیامک تایید هم برای مشتری بفرستد. بسیاری از سرویس‌دهنده‌های پیامک داخلی، حتی آن‌هایی که نسبت به سرویس‌های بین‌المللی کمتر شناخته‌شده‌اند، یک ساختار REST برای ارسال پیامک ارائه می‌دهند. در این حالت، آدرس Webhook را باید به‌جای CRM، به یک واسط کوچک وصل کنید. این واسط اطلاعات فرم را می‌گیرد، آن‌ها را در قالب موردنیاز سرویس پیامکی می‌چیند و درخواست ارسال پیامک را می‌فرستد. این واسط، همان بخشی است که معمولا نیاز به کدنویسی اختصاصی دارد.

پیش از شروع؛ چطور مستندات سرویس مقصد را بخوانیم؟

پیش از انتخاب هر روشی، باید مستندات فنی سرویس مقصد (CRM یا پنل پیامک) را بررسی کنید. چهار نکته در این مستندات اهمیت دارد:

• روش احراز هویت: آیا سرویس فقط یک کلید API ساده میخواهد، یا از روش پیچیده‌تری مثل OAuth استفاده می‌کند؟
• فیلدهای الزامی: دقیقا چه اطلاعاتی را باید بفرستید و کدام فیلدها اختیاری هستند.
• محدودیت تعداد درخواست: بسیاری از سرویس‌ها سقفی برای تعداد درخواست در هر دقیقه یا روز دارند؛ اگر تعداد فرم‌های سایت شما زیاد است، این عدد مهم می‌شود.
• فرمت پاسخ: سرویس مقصد بعد از دریافت درخواست، چه پاسخی برمی‌گرداند و این پاسخ چطور نشان می‌دهد درخواست موفق بوده یا نه.

سه سطح مختلف برای پیاده‌سازی این اتصال

سطح اول: ماژول Webhook داخل خود فرم‌ساز

اگر فرم‌ساز شما، مثل Fluent Forms، قابلیت Webhook داشته باشد و سرویس مقصد هم آدرس دریافت داده را بپذیرد، این ساده‌ترین و سریع‌ترین گزینه است. این روش هیچ کدنویسی‌ای نیاز ندارد.

سطح دوم: ابزارهای آماده‌ی اتوماسیون

ابزارهایی مثل Zapier یا Make به شما اجازه می‌دهند فرم سایت را به سرویس‌های شناخته‌ شده وصل کنید، حتی اگر سرویس مقصد Webhook قبول نکند. این ابزارها معمولا برای سرویس‌های بین‌المللی پرکاربرد گزینه‌ی آماده دارند.

سطح سوم: اتصال مستقیم از طریق کد

وقتی CRM یا پنل پیامک شما داخلی، سفارشی، یا کمتر شناخته‌شده باشد، ابزارهای آماده معمولا پشتیبانی نمی‌کنند. در این حالت، یک قطعه‌ کد باید داده‌ی فرم را بگیرد، آن را مطابق مستندات فنی سرویس مقصد فرمت کند و درخواست را ارسال کند.

مقایسه‌ی سریع این سه روش

چند نکته‌ی فنی که معمولا از قلم می‌افتد

محل نگهداری کلید API

هر اتصال به یک سرویس بیرونی، به یک کلید یا توکن دسترسی نیاز دارد. این کلید را نباید مستقیم داخل کد قالب یا افزونه بنویسید. بهتر است آن را در تنظیمات امن سایت یا متغیرهای محیطی سرور ذخیره کنید، جایی که در دسترس عموم قرار نمی‌گیرد.

تایید اصالت درخواست‌های ورودی

این نکته وقتی مهم می‌شود که یک سرویس بیرونی قرار است به سایت شما پیام بفرستد، نه برعکس. برای مثال، وقتی درگاه پرداخت باید به سایت شما اطلاع دهد که تراکنشی موفق بوده است. در این حالت، سایت باید مطمئن شود این پیام واقعا از همان سرویس آمده، نه از یک منبع جعلی. برای این کار، سرویس مقصد معمولا یک امضای رمزنگاری‌شده همراه پیام می‌فرستد که سایت باید پیش از پردازش، آن را بررسی کند. سرویس مقصد این امضا را معمولا با الگوریتمی مثل HMAC و یک کلید مشترک می‌سازد. سایت با همان کلید، امضای دریافتی را دوباره محاسبه می‌کند و نتیجه را با مقدار دریافتی مقایسه می‌کند؛ اگر این دو مقدار یکسان نباشند، سایت درخواست را نادیده می‌گیرد.

تست پیش از اتصال نهایی

پیش از وصل‌ کردن فرم به سرویس واقعی، بهتر است ابتدا با یک ابزار واسط ساده بررسی کنید. ابزارهایی مثل webhook.site محتوای درخواست‌های Webhook را نمایش می‌دهند و نشان می‌دهند داده‌ی فرم را دقیقا با چه ساختاری می‌فرستید. برای تست دقیق‌تر، از جمله شبیه‌سازی پاسخ سرویس مقصد یا بررسی هدرهای درخواست، Postman هم گزینه‌ی مناسبی است. این کار از اتصال به سرویس نهایی با فرمت اشتباه جلوگیری می‌کند.

مدیریت خطا وقتی سرویس مقصد پاسخ نمی‌دهد

اگر سرویس مقصد موقتا در دسترس نباشد، سایت نباید اطلاعات فرم را از دست بدهد. یک پیاده‌سازی درست، این درخواست‌های ناموفق را در دیتابیس سایت ذخیره می‌کند و بعد از چند دقیقه دوباره تلاش می‌کند. این روش بهتر از تلاش یکباره و رهاکردن درخواست است. نکته‌ی مهم دیگر جلوگیری از ثبت تکراری است؛ اگر پیاده‌سازی، هر تلاش ناموفق را دوباره امتحان کند، باید مطمئن شود این تلاش‌های مکرر به طور مثال چند مخاطب تکراری در CRM نمی‌سازند. یک روش رایج برای این کار، اختصاص یک شناسه‌ی یکتا به هر درخواست و بررسی همان شناسه پیش از پردازش مجدد است.

حجم درخواست‌ها و تاثیر آن بر عملکرد سایت

اگر سایت شما ترافیک بالایی دارد و این اتصال روی هر فرم یا هر سفارش فعال است، تعداد این درخواست‌های خروجی هم زیاد می‌شود. این موضوع از جنس همان مسئله‌ای است که در راهنمای admin-ajax.php بررسی کردیم. درخواست‌های پویا و پرتکرار، حتی وقتی کوچک به نظر می‌رسند، می‌توانند منابع سرور را زیر بار سنگین قرار دهند.

مراحل کلی یک پروژه‌ی اتصال حرفه‌ای

1. بررسی مستندات فنی سرویس مقصد و تعیین روش احراز هویت.
2. تحلیل دقیق داده‌ای؛ مشخص‌ کردن اینکه دقیقا چه اطلاعاتی را باید بفرستید.
3. انتخاب سطح مناسب پیاده‌سازی از میان سه روشی که در بالا توضیح دادیم.
4. پیاده‌سازی اتصال همراه با مدیریت خطا و ذخیره‌ی درخواست‌های ناموفق.
5. تست کامل با داده‌ی واقعی، نه فقط یک نمونه‌ی ساده.
6. مستندسازی کوتاه از نحوه‌ی عملکرد اتصال، برای مراجعه تیم شما در آینده.

بازگشت به مثال Fluent Forms و سرویس پیامک داخلی

در همان مثالی که در ابتدا گفتیم، فرم Fluent Forms داده را به یک واسط بین‌ راهی می‌فرستد. وظیفه‌ی این واسط، ارسال پیامک از طریق همان سرویس پیامک داخلی است و همه‌ی نکات بالا درباره‌ی آن مصداق پیدا می‌کنند. شما باید کلید API این سرویس پیامکی را در تنظیمات امن سرور ذخیره کنید، نه داخل کد آن واسط. اگر آن سرویس پیامکی به هر دلیلی موقتا پاسخ ندهد، سایت باید آن درخواست پیامک را ذخیره کند و بعدا دوباره امتحان کند. در غیر این صورت، مشتری هیچ‌وقت پیامک تاییدیه‌اش را دریافت نمی‌کند و شما هم متوجه این خطا نمی‌شوید. همین یک نکته‌ی کوچک، فاصله‌ی یک اتصال ساده با یک اتصال قابل‌اعتماد را مشخص می‌کند.

چه زمانی این کار را به یک متخصص بسپاریم؟

• سرویس مقصد شما داخلی، اختصاصی، یا کمتر شناخته‌شده است.
• باید همزمان چند سیستم مختلف را با منطق خاصی به هم وصل کنید.
• حجم درخواست‌ها بالا هست و ابزارهای آماده روی آن حجم محدودیت یا هزینه‌ی زیادی دارند.
• نیاز دارید مطمئن شوید هیچ اطلاعاتی، حتی در صورت قطعی موقت سرویس مقصد، از دست نمی‌رود.

در این موارد، وب‌کاستر این اتصال را زیر عنوان یکپارچه‌سازی API و سرویس‌های شخص ثالث پیاده‌سازی می‌کند.

اشتباهات رایج

• ذخیره‌ی کلید API داخل فایل‌های کد: اگر فایل‌های کد به هر دلیلی در دسترس عموم قرار بگیرد، این کلید هم لو میرود.
• نادیده‌گرفتن قطعی موقت سرویس مقصد: بدون برنامه‌ای برای تلاش دوباره، همان چند دقیقه قطعی می‌تواند باعث از دست رفتن چندین سرنخ واقعی شود.
• انتخاب ابزار پولی برای اتصالی که رایگان هم قابل انجام است: پیش از خرید یک ابزار اتوماسیون، ابتدا بررسی کنید. شاید فرم‌ساز فعلی سایت، خودش این قابلیت را داشته باشد.
• تست‌ نکردن با داده‌ی واقعی: یک تست ساده در محیط توسعه، همیشه رفتار واقعی زیر بار ترافیک واقعی را نشان نمی‌دهد.
• عدم بررسی محدودیت تعداد درخواست سرویس مقصد: اگر فرم‌های موجود در سایت زیاد توسط کاربران شما ثبت می‌شوند، رسیدن به سقف مجاز سرویس مقصد ممکن است اطلاعات را بی‌صدا از بین ببرد.

اگر شما هنوز فرم سایت را دستی بررسی می‌کنید، یا CRM و پنل پیامک شما با روش‌های آماده قابل اتصال نیستند، این قابل تغییر است. می‌توانید جزئیات را با تیم یکپارچه‌سازی API و سرویس‌های شخص ثالث وب‌کاستر در میان بگذارید.