تحویل مشتری پس از فروش باید وعده‌های تأییدشده، محدوده کار و سؤال‌های باز را به تیم اجرا منتقل کند. قرارداد یا سفارش به‌تنهایی همیشه توضیح نمی‌دهد مشتری دقیقاً چه مسئله‌ای دارد و از کجا باید شروع کرد. یک مالک تحویل تعیین کنید و پیش از اعلام شروع، پذیرش تیم اجرا و پیش‌نیازهای لازم را بررسی کنید. این صفحه درباره هماهنگی اجراست، نه تنظیم حقوقی قرارداد.
تعهد تأییدشده را از انتظار جدا کنید
در مکالمه فروش ممکن است درباره امکان‌های آینده صحبت شده باشد. تیم اجرا باید بداند کدام مورد در دامنه پذیرفته‌شده است، کدام نیازمند بررسی است و کدام صرفاً سؤال مشتری بوده است. هر قول را به نسخه معتبر پیشنهاد یا تأیید مسئول مربوط وصل کنید. عبارت «مشتری همه چیز را می‌خواهد» اطلاعات قابل اجرا نمی‌دهد و زمینه اختلاف می‌سازد.
جدول تحویل شروع همکاری
- بخش: مسئله مشتری؛ اطلاعات تحویلی: شرح مورد تأیید؛ نمونه فرضی: تعیین مسئول برای درخواست‌ها؛ پذیرنده: مالک اجرا
- بخش: دامنه؛ اطلاعات تحویلی: نسخه معتبر خدمت؛ نمونه فرضی: فقط مسیر نمونه مشخص؛ پذیرنده: مسئول پروژه
- بخش: پیش‌نیاز؛ اطلاعات تحویلی: اطلاعات لازم و صاحب آن؛ نمونه فرضی: شرح مراحل توسط مشتری؛ پذیرنده: کارشناس اجرا
- بخش: موضوع باز؛ اطلاعات تحویلی: سؤال بدون پاسخ قطعی؛ نمونه فرضی: بررسی امکان تبادل اطلاعات؛ پذیرنده: مسئول فنی
- بخش: ارتباط؛ اطلاعات تحویلی: مخاطب و کانال هماهنگی؛ نمونه فرضی: نماینده معرفی‌شده مشتری؛ پذیرنده: هماهنگ‌کننده
- بخش: پذیرش تحویل؛ اطلاعات تحویلی: تاریخ و نقص‌های باقیمانده؛ نمونه فرضی: پذیرش مشروط به تکمیل ورودی؛ پذیرنده: مالک اجرا
دانلود همین جدول با قالب CSV سازگار با اکسل
جلسه داخلی کوتاه اما تصمیم‌دار برگزار کنید
فروش مسئله، دامنه و موارد حساس را توضیح دهد؛ اجرا پرسش‌های شروع را مطرح کند و پذیرش را ثبت کند. اگر اطلاعات کافی نیست، فهرست نقص با مسئول تکمیل ساخته شود. انتقال پوشه بدون تأیید دریافت، نشان نمی‌دهد اجرا آماده است. برای دریافت دسترسی نیز فقط اطلاعات لازم را از مسیر امن مصوب بخواهید؛ رمزها را داخل فرم عمومی تحویل ننویسید.
نمونه معرفی تیم اجرا به مشتری
«برای ادامه مسیر مورد توافق، همکارم مسئول هماهنگی اجراست. خلاصه مسئله و نسخه دامنه به او تحویل شده تا لازم نباشد همه موضوع را از ابتدا توضیح دهید. در جلسه شروع، پیش‌نیازها و موضوع باز مربوط به تبادل اطلاعات را مرور می‌کنیم.» این معرفی زمانی درست است که تحویل واقعاً انجام شده باشد؛ صرف اضافه‌کردن فردی به گروه چنین معنایی ندارد.
مسئولیت پس از تحویل را مشخص کنید
برای سؤال درباره دامنه، وضعیت اجرا و مشکل خدمت، مسیر تماس روشن باشد. فروش نباید هم‌زمان زمان‌بندی متفاوتی به مشتری بدهد. اگر تغییر تازه‌ای درخواست شد، آن را به بررسی دامنه برگردانید؛ در یادداشت معمولی به کار قطعی تبدیل نکنید. تغییر مسئول اصلی نیز باید به مخاطب معرفی‌شده اعلام شود تا مشتری میان چند نفر سرگردان نشود.
پس از شروع، یک پرونده را از نگاه نفر تحویل‌گیرنده مرور کنید: آیا می‌داند خروجی مورد انتظار چیست و کدام موارد هنوز تأیید نشده؟ اگر برای یافتن وعده‌ها باید تاریخچه چند گفت‌وگو را جست‌وجو کند، فرم تحویل ناقص است. یادگیری این بررسی را به قالب برگردانید تا تحویل بعدی وابسته به حافظه فروشنده نباشد.
ادامه مطالعه و بررسی فرایند تماس
برای مرتبط‌کردن این الگو با جریان کار تیم، راهنمای ثبت اطلاعات تماس در CRM را بخوانید. برای بررسی تناسب اپراگپ با نیاز کسب‌وکارتان، معرفی و دموی اپراگپ را ببینید و سناریوی خود را مبنای ارزیابی قرار دهید.
موضوع مرتبط: راهنمای قابلیت مرتبط با این فرایند.