اتصال سایت به CRM؛ راهنمای انتخاب و تعریف نیازمندی

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

اتصال سایت به CRM چه مسئله‌ای را باید حل کند؟

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

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

اما «فرستادن به CRM» همیشه یک معنا ندارد. سه خروجی متفاوت ممکن است:

• ثبت مخاطب: فقط مشخصات فرد در فهرست مشتریان ذخیره می‌شود.

• ساخت درخواست فروش: یک سرنخ یا فرصت (Lead) با موضوع و منبع مشخص ساخته می‌شود.

• ایجاد کار پیگیری: یک وظیفه با مهلت برای کارشناس مشخص تعریف می‌شود.

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

پیشنهاد من این است که هدف اتصال سایت به CRM را طوری بنویسید که بشود آزمودش: «هر فرم معتبر یک درخواست قابل‌ردیابی با مسئول مشخص بسازد.» این جمله را می‌شود آزمود. «فروش بیشتر» را نه؛ چون اتصال فقط شرایط پیگیری بهتر را فراهم می‌کند.

برای اتصال سایت به CRM چه نیازمندی‌هایی باید مشخص شود؟

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

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

برای هر جریان دو مالک تعیین کنید. مالک کسب‌وکاری، که معمولاً مسئول فروش است، فیلدها و قواعد تخصیص را تأیید می‌کند. مالک فنی درباره دسترسی، خطا و پایش تصمیم می‌گیرد. تأیید فیلدهای فروش را فقط به توسعه‌دهنده نسپارید، چون توسعه‌دهنده (از جمله خود من) همیشه نمی‌داند کدام فیلد برای کارشناس واقعاً مهم است.

یک فرم آماده تعریف نیازمندی را هم در انتهای همین راهنما گذاشته‌ام تا همه این موارد را یک‌جا بنویسید.

کدام اطلاعات باید منتقل شوند و منبع اصلی هر داده چیست؟

فقط داده‌ای را منتقل کنید که کسی در مقصد واقعاً با آن کار می‌کند و برای هر داده یک منبع اصلی بگذارید. نگاشت فیلدها (Field Mapping) یعنی مشخص کنید هر داده سایت در CRM به کدام فیلد می‌رسد. نمونه زیر کاملاً فرضی است:

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

در اتصال سایت به CRM، قواعد تبدیل را هم صریح بنویسید؛ چون بیشتر خطاهای بی‌صدا از همین‌جا شروع می‌شوند:

• ارقام فارسی و لاتین پیش از ذخیره یکسان شوند تا جست‌وجو و تشخیص تکرار درست کار کند.

• شماره تماس با یک قالب واحد ذخیره شود، مثلاً بدون فاصله و با پیش‌شماره مشخص.

• زمان ثبت با منطقه زمانی صریح برود؛ وگرنه ساعت درخواست در گزارش جابه‌جا دیده می‌شود.

• مقدار خالی بدون قاعده، داده کامل مقصد را پاک نکند.

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

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

تفاوت اتصال یک‌طرفه و همگام‌سازی دوطرفه چیست؟

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

همگام‌سازی (Sync) یعنی هماهنگ نگه‌داشتن داده‌های منتخب میان دو سامانه. کلمه «منتخب» این‌جا کلیدی است. برگرداندن وضعیت فروش به سایت با بازنویسی دوطرفه همه اطلاعات مشتری یکی نیست و پیچیدگی‌شان هم اصلاً در یک اندازه نیست.

برای مثال، در یک سناریوی فرضی مشخصات درخواست از سایت به CRM می‌رود و از CRM فقط فیلد «وضعیت» با مقادیر مجاز برمی‌گردد. یادداشت داخلی کارشناس، مثل «مشتری به قیمت حساس است»، هرگز نباید به سایت برسد.

سخت‌ترین بخش، ویرایش هم‌زمان است و بیشترین نگرانی من هم همین‌جاست. اگر مشتری شماره‌اش را در سایت عوض کند و کارشناس همان لحظه در CRM، کدام درست است؟ برای هر فیلد مرجع تعیین کنید و نسخه تغییر را نگه دارید. اتکا به «آخرین زمان ثبت» ساده است، اما ساعت دو سرور همیشه یکی نیست.

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

این جدول ارزیابی نسبی من از پیچیدگی است، نه آمار پروژه‌ها.

فیلدی که دو سامانه می‌توانند عوضش کنند، بدون داور دیر یا زود خراب می‌شود.

چه زمانی اتصال آماده کافی است و چه زمانی توسعه لازم داریم؟

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

1. فیلدهای سفارشی CRM شما را می‌شناسد یا فقط فیلدهای پیش‌فرض را؟

2. درخواست فروش می‌سازد یا فقط مخاطب ثبت می‌کند؟

3. تخصیص به کارشناس را با قاعده شما انجام می‌دهد؟

4. خطاها را ثبت می‌کند و جایی برای دیدنشان دارد؟

5. ارسال مجدد درخواست‌های ناموفق را ممکن می‌کند؟

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

توسعه اختصاصی را وقتی بررسی کنید که منطق تخصیص پیچیده است یا داده باید به چند مقصد برود. همچنین وقتی قواعد تعارض یا الزامات دسترسی خاصی دارید. در چنین پروژه‌هایی، ما در نیاسا یکپارچه سازی سایت و crm را بخشی از طراحی سایت اختصاصی برای فرایندهای ویژه کسب‌وکار می‌بینیم، نه یک افزونه جدا.

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

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

پیش‌نیازهای دسترسی و مستندات سرویس مقصد چیست؟

شرط اصلی اتصال سایت به CRM، دسترسی به API سرویس مقصد با مستندات روشن است. رابط برنامه‌نویسی کاربردی (API) مسیر رسمی تبادل داده میان نرم‌افزارهاست. اما داشتن دسترسی به پنل CRM لزوماً به معنای دسترسی به این مسیر نیست؛ گاهی اشتراک فعلی اصلاً API ندارد.

معمولاً اولین سؤالی که می‌پرسم این است که مستندات کدام نسخه را داریم. بعد سراغ این موارد می‌روم:

• روش احراز هویت، یعنی سرویس چطور تشخیص می‌دهد درخواست از طرف شماست.

• مجوز ساخت و ویرایش رکوردها، نه فقط خواندن.

• سقف درخواست‌ها در دقیقه یا روز.

• امکاناتی که در اشتراک فعلی شما فعال است.

• محیط آزمایشی جدا از داده واقعی.

اعلان خودکار تغییرات (Webhook) یعنی CRM خودش هنگام تغییر وضعیت به سایت خبر بدهد. اگر این امکان نباشد، سایت باید هر چند دقیقه بپرسد چه چیزی عوض شده است. این بررسی دوره‌ای تأخیر دارد و سهمیه درخواست‌ها را هم مصرف می‌کند. برای فهم پاسخ‌های سرور، مستندات ارتباط HTTP و پاسخ‌های سرور مرجع خوبی است.

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

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

رکورد تکراری و تخصیص درخواست به کارشناس چگونه مدیریت شوند؟

راه‌حل این است که مشتری و درخواست را جدا از هم شناسایی کنید. رکورد یعنی یک مورد ثبت‌شده در سامانه، مثل یک مخاطب یا یک درخواست. مشتری تکراری با درخواست تازه همان مشتری فرق دارد؛ اولی را باید ادغام کرد و دومی را ثبت.

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

موارد مرزی را از قبل بنویسید. اعضای یک خانواده یا کارمندان یک شرکت ممکن است شماره تماس مشترک داشته باشند. کسی هم ممکن است شماره‌اش را عوض کرده باشد. به همین دلیل ادغام خودکار فقط بر اساس نام را ممنوع کنید؛ دو «علی محمدی» لزوماً یک نفر نیستند.

برای اتصال فرم سایت به crm، قاعده تخصیص را صریح بنویسید. مثلاً درخواست‌های «اپلیکیشن» به کارشناس محصول برسد و درخواست‌های تهران به تیم تهران. یک صف پیش‌فرض هم بگذارید تا درخواستی که با هیچ قاعده‌ای جور نشد یا کارشناسش غیرفعال بود، بی‌صاحب نماند.

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

هنگام قطع ارتباط یا خطای انتقال چه اتفاقی باید بیفتد؟

سایت باید درخواست را اول در پایگاه داده خودش ذخیره کند و انتقالش را جداگانه پیگیری کند. این دو مرحله را یکی نکنید. پیام «درخواست شما ثبت شد» درست است، اما «کارشناس ما درخواست شما را دید» وعده‌ای است که شاید هنوز محقق نشده باشد.

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

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

برای خطای دائمی این‌ها را تعیین کنید:

• حداکثر تعداد تلاش پیش از توقف.

• مسئول دریافت هشدار.

• مسیر اصلاح داده.

• امکان ارسال مجدد دستی پس از اصلاح.

قطعی نباید به سکوت عملیاتی تبدیل شود. در واقع بدترین سناریو قطع‌شدن اتصال نیست؛ این است که دو هفته قطع باشد و کسی نفهمد.

اتصالی که خطایش را پنهان کند، از نبودنش بدتر است.

در گزارش عملیاتی سه وضعیت را جدا نشان دهید: منتظر، موفق و نیازمند بررسی. همچنین ترتیب پیام‌ها را کنترل کنید. مثلاً ممکن است اعلان «قرارداد بسته شد» زودتر از «در حال مذاکره» برسد؛ وضعیت قدیمی نباید وضعیت جدید را بازنویسی کند.

اطلاعات مشتری و رویدادهای دسترسی چگونه محافظت شوند؟

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

همچنین این موارد را در نیازمندی ثبت کنید: ارتباط رمزگذاری‌شده، برنامه تعویض کلید، روش لغو فوری دسترسی و بررسی اصالت اعلان‌های ورودی. بدون این بررسی، هر کسی می‌تواند خودش را CRM جا بزند و وضعیت جعلی بفرستد. فهرست خطرهای رایج را در راهنمای امنیت رابط‌های برنامه‌نویسی ببینید.

ثبت رویداد (Log) یعنی نگهداری رد عملیات برای پیگیری بعدی. شناسه درخواست، زمان، نتیجه و عامل تغییر را ثبت کنید. اما متن کامل فرم یا رمز دسترسی را نه؛ چون لاگ‌ها معمولاً کمتر از پایگاه داده محافظت می‌شوند. در بازبینی کد، این یکی از اولین چیزهایی است که چک می‌کنم.

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

آزمون پذیرش و شمارش درخواست‌های منتقل‌شده چگونه انجام شود؟

به زبان ساده، آزمون پذیرش یعنی بررسی اینکه نتیجه توافق‌شده از دید کسب‌وکار واقعاً اتفاق افتاده یا نه. پاسخ موفق فنی، مثل کد ۲۰۰ از سرور، به‌تنهایی ثابت نمی‌کند که درخواست درست ثبت و تخصیص داده شده است.

برای هر جریان اتصال سایت به CRM یک ردیف آزمون بسازید: ورودی غیرواقعی، پیش‌شرط، اقدام، نتیجه مورد انتظار، شاهد و تأییدکننده. نمونه:

تأییدکننده هر ردیف مسئول فروش است، نه فقط تیم فنی؛ چون اوست که می‌داند درخواست واقعاً به دست درستی رسیده یا نه.

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

هزینه اتصال سایت به crm به چه عواملی بستگی دارد؟

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

عوامل اصلی هزینه این‌ها هستند:

• کیفیت مستندات API و وجود محیط آزمایشی.

• سهولت گرفتن دسترسی و مجوزهای لازم.

• حجم تبدیل و یکسان‌سازی داده.

• پیچیدگی قواعد تخصیص.

• یک‌طرفه یا دوطرفه بودن همگام‌سازی.

• آزمون سناریوهای خطا.

• امکانات پایش و گزارش.

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

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

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

فرم آماده تعریف نیازمندی اتصال چگونه تکمیل شود؟

این فرم را در چهار برگه یک فایل صفحه‌گسترده قابل‌ویرایش پر کنید و نسخه چاپی‌اش را برای جلسه با تیم فروش همراه داشته باشید. ترتیب برگه‌ها این است:

1. تصویر کلی: مسئله، سامانه‌ها و نسخه‌هایشان، مالک فنی، مسئول فروش، دامنه و موارد خارج از دامنه.

2. جریان‌ها: یک ردیف برای هر جریان و نگاشت فیلدهای همان جریان.

3. قواعد: شناسه مشتری و درخواست، قواعد تکرار، تخصیص، تعارض، قطع ارتباط و دسترسی.

4. پذیرش: آزمون پذیرش و شاهد قبولی برای تک‌تک جریان‌ها.

برای مثال، یک ردیف تکمیل‌شده فرضی در برگه جریان‌ها چنین شکلی دارد:

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

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