برای تحویل‌گرفتن فرم درخواست مشاوره، فقط دکمه «ارسال» را امتحان نکنید. یک بار فرم را با مشخصات مخاطب تازه پر کنید، یک بار با مشخصات مشتری قبلی و بار دیگر موضوعی را انتخاب کنید که مسئول مشخصی برای آن تعیین نشده است. این آزمون‌های کوچک می‌توانند تفاوت میان یک فرم سالم از نظر ظاهری و یک مسیر قابل استفاده برای تیم فروش را آشکار کنند.
اتصال فرم سایت به CRM قرار است اطلاعات ورودی را به کاری قابل رسیدگی تبدیل کند. سرنخ فروش در این بحث، نشانه‌ای از علاقه یک مخاطب است که هنوز باید بررسی شود؛ هر فرم ارسالی الزاماً درخواست خرید نیست. هدف این مقاله، طراحی یک جلسه آزمون برای همین مرز میان سایت و فروش است. نمونه‌ها فرضی‌اند و آزمون عملی محصول خاصی را گزارش نمی‌کنند.
محیط آزمون: یک فرم، چند نوع درخواست
شرکت فرضی ما خدمات طراحی غرفه نمایشگاهی ارائه می‌کند. در سایت آن، بازدیدکننده می‌تواند درباره طراحی غرفه جدید، تغییر یک سفارش قبلی یا همکاری به‌عنوان تأمین‌کننده پیام بفرستد. فرم فعلی فقط نام، راه تماس و یک کادر توضیح دارد. همه پیام‌ها هم به صندوق ایمیل عمومی می‌روند. برای بازطراحی، پرسش اصلی این است: کدام اطلاعات باید همراه درخواست بماند تا همکار بعدی مجبور نباشد از ابتدا موضوع را کشف کند؟
در این مثال، انتخاب «نوع درخواست» برای تعیین مسیر رسیدگی کاربرد دارد. نام نمایشگاه و زمان برگزاری هم ممکن است برای بررسی درخواست طراحی لازم باشد؛ اما برای پیام یک تأمین‌کننده همان اهمیت را ندارد. بهتر است پیش از افزودن هر فیلد مشخص کنیم پاسخ آن چه تصمیمی را تغییر می‌دهد. اگر قرار نیست کسی از اطلاعاتی استفاده کند، صرفاً برای کامل‌تر به نظر رسیدن فرم از مخاطب نخواهیم آن را وارد کند.
در راهنمای ساخت فرم HubSpot، به‌روزشده در ۱۱ سپتامبر ۲۰۲۶، فیلدهای فرم به ویژگی‌های پرونده متصل می‌شوند و محل ذخیره اطلاعات به همین اتصال وابسته است. همان راهنما امکان نمایش شرطی فیلدها را، با توجه به پاسخ مخاطب و نوع اشتراک، توضیح می‌دهد. این شاهد فنی نشان می‌دهد طراحی ظاهر فرم و تعیین محل ذخیره اطلاعات دو کار مرتبط اما جدا هستند؛ قابلیتی از این محصول را نباید بدون بررسی به هر CRM دیگری نسبت داد.
جلسه آزمون را با داده ساختگی و نشانی‌های تماس تحت کنترل تیم برگزار کنید تا پیام آزمایشی برای مشتری واقعی نرود. طراح سایت باید بتواند نتیجه ثبت را ببیند و نماینده فروش نیز باید پرونده‌ای را که تحویل می‌گیرد بررسی کند. هر آزمون تنها زمانی تمام است که نتیجه مورد انتظار در مقصد دیده شود؛ مشاهده پیام تشکر در مرورگر برای این بررسی کافی نیست.
چهار آزمون پذیرش، با چهار انتظار متفاوت
آزمون اول: مخاطب تازه، درخواست روشن
درخواست فرضی طراحی یک غرفه جدید را با اطلاعاتی ثبت کنید که قبلاً در سیستم نبوده است. انتظار این است که راه تماس، موضوع درخواست و توضیح مخاطب در محل درست ذخیره شوند و مسئول رسیدگی بتواند آنها را ببیند. اگر نام شرکت در جای نام فرد نشسته یا نوع درخواست فقط در ایمیل مانده است، انتقال اطلاعات هنوز به شکل مطلوب انجام نمی‌شود؛ حتی اگر پرونده‌ای ساخته شده باشد.
از همکار فروش بخواهید فقط با خواندن پرونده توضیح دهد مخاطب چه می‌خواهد. لازم نیست تمام جزئیات پروژه از فرم معلوم باشد؛ اما باید بتواند تشخیص دهد تماس اول برای روشن‌کردن کدام موضوع است. برای مثال، اگر زمان نمایشگاه مشخص نیست، این ابهام باید قابل تشخیص باشد، نه اینکه مقدار پیش‌فرضی آن را پنهان کند. این آزمون کیفیت تحویل اطلاعات را می‌سنجد، نه احتمال خرید مخاطب را.
آزمون دوم: مشتری قبلی، درخواست تازه
همان فرم را با ایمیل یک مشتری آزمایشیِ موجود و موضوعی تازه پر کنید. اکنون انتظار با آزمون قبل فرق دارد: سابقه فرد باید حفظ شود و درخواست جدید نیز قابل تشخیص بماند. «یک مخاطب» با «یک درخواست» برابر نیست. مشتری می‌تواند برای نمایشگاه دیگری پروژه تازه بخواهد؛ نباید صرفاً چون نامش قبلاً وجود داشته، این نیاز تازه نادیده گرفته شود.
مستند فرم HubSpot توضیح می‌دهد که در تنظیم ایجاد مخاطب بر پایه ایمیل، تطابق ایمیل ارسالی با پرونده موجود باعث به‌روزرسانی همان پرونده می‌شود. بنابراین در طراحی اتصال باید مشخص کنیم کدام اطلاعات متعلق به خود مخاطب است و کدام به درخواست فعلی مربوط می‌شود. پیشنهاد عملی برای شرکت فرضی این است که شرح پروژه قبلی با متن درخواست تازه جایگزین نشود و هر دو درخواست، تاریخ و موضوع روشن داشته باشند.
این آزمون محل مناسبی برای بررسی نظم پرونده‌های مشتری هم هست. اگر اتصال سایت بر اطلاعات هویتی نامنسجم تکیه کند، تصمیم درباره ساخت پرونده تازه یا استفاده از سابقه قبلی دشوار می‌شود. مقاله مرتبط زیر درباره همین پیش‌نیاز، یعنی نگهداری اطلاعات مشتری به شکلی قابل پیگیری، توضیح بیشتری می‌دهد.
آزمون سوم: دریافت اعلان، بدون قبول مسئولیت
برای درخواست بعدی، بررسی کنید چه کسی فقط ایمیل اطلاع‌رسانی می‌گیرد و چه کسی در خود سیستم مسئول رسیدگی است. این دو نقش را یکسان فرض نکنید. ممکن است چند همکار پیام را ببینند، اما هرکدام تصور کند دیگری رسیدگی خواهد کرد. نتیجه مورد انتظار ما یک نام یا صف کاری مشخص در پرونده است، همراه با قاعده‌ای روشن برای اینکه چه کسی آن صف را بررسی می‌کند.
در مستند تعیین مسئول پرونده در HubSpot، به‌روزشده در ۸ سپتامبر ۲۰۲۶، مسئول با ویژگی مالک پرونده تعیین می‌شود و قواعد خودکار می‌توانند بر اساس شرایط، افراد متفاوتی را انتخاب کنند. همچنین همان مستند می‌گوید تعیین مسئول از راه واردکردن فایل، خودبه‌خود پیام اطلاع‌رسانی این مسئولیت را برای فرد ارسال نمی‌کند. این جزئیات نمونه‌ای روشن از جدا بودن مسئولیت و اطلاع‌رسانی در طراحی سیستم است.
در شرکت غرفه‌سازی، می‌توان درخواست پروژه جدید را به تیم فروش و تغییر سفارش جاری را به مسئول همان پروژه سپرد. این یک انتخاب پیشنهادی برای مثال ماست. اگر مشتری قبلی دوباره فرم پر کرد، لازم است روشن باشد مسئول فعلی حفظ می‌شود یا پرونده طبق قاعده دیگری ارجاع می‌خورد. تغییر مسئول نباید پیامد تصادفی پرکردن دوباره فرم باشد.
آزمون چهارم: هیچ‌کس با قاعده ارجاع تطابق ندارد
یک درخواست خارج از دسته‌های معمول ثبت کنید؛ مثلاً همکاری تأمین‌کننده‌ای که هنوز برای آن مسیر کاری تعریف نشده است. موفقیت آزمون به این نیست که نرم‌افزار به هر قیمتی نام یک فروشنده را انتخاب کند. انتظار مفید، دیده‌شدن درخواست در محل بررسی استثناهاست؛ جایی که مسئول معینی بتواند علت بی‌مسئول ماندن آن را بررسی کند و درباره مسیر بعدی تصمیم بگیرد.
راهنمای توزیع سرنخ در Microsoft Dynamics 365 نشان می‌دهد که با فعال‌بودن شرط ظرفیت، نبودن فروشنده‌ای با ظرفیت پذیرش کار تازه می‌تواند پرونده را بدون مسئول باقی بگذارد. شرط حضور فروشنده در بازه زمانی تعیین‌شده نیز ممکن است چنین نتیجه‌ای داشته باشد. این رفتار مربوط به قواعد و تنظیمات همان محصول است؛ نکته قابل استفاده برای طراحی ما، پیش‌بینی مسیر درخواست‌هایی است که قاعده معمول آنها را به کسی نمی‌سپارد.
برای چنین مواردی، صرف داشتن یک صندوق مشترک کافی نیست. در جلسه تحویل مشخص کنید چه کسی آن را بررسی می‌کند، چگونه پرونده‌های منتظر را از موارد رسیدگی‌شده جدا می‌کند و در صورت غیبت او چه کسی جایگزین است. زمان پاسخ را هم بر اساس توان واقعی تیم تعریف کنید؛ در فرم وعده‌ای ننویسید که فرایند داخلی امکان انجامش را ندارد.
خروجی جلسه تحویل: کنار هر درخواست آزمایشی، نشانی پرونده مقصد، مسئول رسیدگی و ایراد احتمالی را ثبت کنید. اگر یک آزمون شکست خورد، اصلاح باید همان رفتار را تغییر دهد و با همان ورودی دوباره بررسی شود. پس از تغییر فرم یا قواعد ارجاع نیز این نمونه‌ها را نگه دارید تا بتوانید مسیر را دوباره بسنجید. به این ترتیب، تحویل اتصال سایت با یک نمایش کوتاه تمام نمی‌شود؛ مجموعه‌ای از شواهد قابل تکرار دارید که نشان می‌دهد درخواست مخاطب واقعاً به محل رسیدگی می‌رسد.
هر دو تصویر، تصویرسازی مفهومی تولیدشده با هوش مصنوعی‌اند؛ شخصیت تصویر شاخص فرد واقعی معرفی‌شده در مقاله نیست و تصاویر نمای یک نرم‌افزار مشخص را نشان نمی‌دهند.
نظر شما چیست؟