طراحی فرم دریافت درخواست مشتری؛ از پیام پراکنده تا کار قابل اجرا

نویسنده: WKFGo Editorial · تاریخ انتشار · آخرین ویرایش

چرا انتقال ایمیل به فرم به‌تنهایی کافی نیست؟

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

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

فیلدهای حداقلی

برای بیشتر درخواست‌های پروژه این اطلاعات مفید است:

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

از مشتری نخواهید فیلدهای داخلی مانند story point یا اولویت نهایی را تعیین کند. او اثر و زمینه را می‌گوید؛ تیم تریاژ اولویت را بر اساس قواعد مشترک مشخص می‌کند.

جریان پس از ارسال

1. رسید با شناسه پیگیری و انتظار زمانی ارسال شود.
2. مالک تریاژ کامل‌بودن و مسیر درخواست را بررسی کند.
3. موارد تکراری به رکورد اصلی متصل شوند.
4. در صورت نیاز، سؤال تکمیلی مشخص پرسیده شود.
5. درخواست پذیرفته، رد یا برای تصمیم ارجاع شود و دلیل آن به مشتری برگردد.
6. کار پذیرفته‌شده با معیار پذیرش به پروژه مرتبط وصل شود.

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

مثال: درخواست «گزارش فوری»

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

KPI‌های فرایند intake

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

تعداد درخواست بسته‌شده بدون سنجش کیفیت پاسخ، تیم را به بستن سریع موارد سوق می‌دهد.

اجرا در WKFGo

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

محدودیت و حریم خصوصی

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

قدم بعدی

یک نوع درخواست پرتکرار را در WKFGo پایلوت کنید و نرخ رفت‌وبرگشت اطلاعات را بسنجید. امکانات را ببینید یا برای طراحی فرم و مسیر تریاژ با ما تماس بگیرید.