فرض کنید ساعت ۱۰:۳۰ صبح، کارشناس فروش قرارداد را نهایی کرده و تصور می‌کند کارش تمام شده است. پشتیبانی تماس می‌گیرد، اما نمی‌داند مشتری دقیقاً چه چیزی خریده، چه قولی شنیده و اولین درخواستش را چه کسی باید پیگیری کند. مشتری دوباره توضیح می‌دهد، فروشنده دنبال پیام‌های قدیمی می‌گردد و مدیر هم نمی‌تواند بفهمد تأخیر از کجا شروع شده است. این نوشته توضیح می‌دهد چگونه «تحویل مشتری» را از یک پیام کوتاه به یک فرایند روشن تبدیل کنید؛ فرایندی که اطلاعات، مسئولیت، اقدام بعدی و معیار پذیرش آن مشخص باشد.
چرا لحظه واگذاری پرونده، نقطه شکست تجربه مشتری است؟
فروش معمولاً با گفت‌وگو، مذاکره و تصمیم‌گیری جلو می‌رود. در این مرحله، جزئیات زیادی در ذهن فروشنده یا میان مکالمات مختلف شکل می‌گیرد: نیاز اولیه، حساسیت مشتری، وعده‌های داده‌شده، محدودیت زمانی و کسی که در شرکت مشتری تصمیم نهایی را می‌گیرد. پشتیبانی اما به جای حدس زدن، به تصویری روشن از وضعیت نیاز دارد.
مشکل از جایی شروع می‌شود که فروش، پایان کار خود را «امضای قرارداد» بداند و پشتیبانی، شروع کار را «اولین تماس مشتری» حساب کند. میان این دو نقطه، یک بخش مهم جا می‌ماند: انتقال مسئولیت همراه با اطلاعات کافی.
اگر پرونده بدون توضیح به پشتیبانی برسد، چند اتفاق قابل پیش‌بینی رخ می‌دهد. پشتیبان پرسش‌هایی را تکرار می‌کند که مشتری قبلاً پاسخ داده است. فروشنده برای پاسخ‌گویی دوباره وارد ماجرا می‌شود. مشتری احساس می‌کند هر بخش شرکت اطلاعات جداگانه‌ای دارد. مدیر نیز در گزارش‌ها فقط می‌بیند پرونده از یک مرحله به مرحله دیگر رفته، اما نمی‌داند آیا تیم مقصد واقعاً آمادگی پذیرش آن را داشته است یا نه.
پس انتقال موفق فقط تغییر نام مسئول نیست. باید روشن باشد:
- مشتری چه مسئله‌ای داشته است؟
- چه چیزی به او وعده داده شده است؟
- کدام بخش‌ها قطعی و کدام موارد مشروط هستند؟
- نخستین کار تیم پشتیبانی چیست؟
- اگر اطلاعات ناقص باشد، پرونده به چه کسی برمی‌گردد؟
- چه زمانی می‌گوییم پرونده واقعاً پذیرفته شده است؟
در مدل عملیاتی CRM کلید همین نگاه از تماس مشتری تا کار روزانه تیم بررسی شده است؛ یعنی هر ارتباط باید به مسئول، سابقه و اقدام بعدی وصل باشد.
چه اطلاعاتی باید از فروش به پشتیبانی برسد؟
همه اطلاعات فروش برای پشتیبانی لازم نیست. انتقال انبوه پیام‌ها و یادداشت‌ها، پرونده را شلوغ می‌کند و پیدا کردن نکته مهم را سخت‌تر می‌سازد. هدف، ساختن خلاصه‌ای است که پشتیبان با خواندن آن بتواند بدون تماس دوباره با فروشنده، وضعیت مشتری را بفهمد و کار را ادامه دهد.
۱. مسئله و انتظار مشتری را بنویسید
شرح نیاز را با نام محصول یا خدمت جایگزین نکنید. «مشتری بسته خدماتی را خرید» به تنهایی کافی نیست. بنویسید مشتری با چه مسئله‌ای آمده و انتظار دارد چه چیزی تغییر کند.
مثلاً:
«مشتری برای مدیریت پیگیری درخواست‌های خدماتی چند شعبه مراجعه کرده است. انتظار دارد درخواست‌ها در پرونده مشتری ثبت شوند و مسئول هر پیگیری مشخص باشد.»
این جمله به پشتیبانی کمک می‌کند پاسخ‌ها را به مسئله اصلی وصل کند. اگر مشتری بعداً درباره یک قابلیت پرسید، تیم مقصد می‌داند آن پرسش در چه زمینه‌ای مطرح شده است.
۲. تصمیم‌های قطعی و موارد مشروط را جدا کنید
در مکالمه فروش، ممکن است درباره چند امکان صحبت شده باشد، اما همه آن‌ها بخشی از توافق نهایی نباشند. در خلاصه پرونده دو بخش جدا بسازید:
- موارد قطعی که بر اساس توافق باید پیگیری شوند.
- مواردی که نیاز به بررسی، تأیید یا تصمیم دیگری دارند.
این تفکیک از شکل‌گیری انتظار نادرست جلوگیری می‌کند. اگر چیزی هنوز تأیید نشده است، آن را در بخش «قول قطعی» ننویسید. عبارت‌هایی مانند «قرار شد بررسی شود» باید همراه با مسئول و زمان پیگیری بیاید؛ وگرنه چند روز بعد کسی نمی‌داند بررسی بر عهده چه کسی بوده است.
۳. افراد اثرگذار را مشخص کنید
نام مشتری سازمانی همیشه به معنی نام فردی نیست که با پشتیبانی صحبت می‌کند. فروشنده باید مشخص کند چه کسانی در روند کار نقش دارند: تصمیم‌گیرنده، کاربر اصلی، فرد مالی یا مسئول فنی.
لازم نیست درباره هر فرد شرح طولانی بنویسید. یک توضیح کوتاه کافی است:
«خانم رضایی تصمیم‌گیرنده است. آقای نادری کاربر اصلی خواهد بود و پرسش‌های فنی را پیگیری می‌کند.»
این اطلاعات از تماس اشتباه و ارجاع‌های بی‌مورد جلوگیری می‌کند.
۴. سابقه مکالمات و فعالیت‌های مهم را نگه دارید
پشتیبانی به همه گفت‌وگوها نیاز ندارد، اما تصمیم‌های مهم باید در پرونده ثبت شوند. خلاصه تماس، جلسه، پیام یا فعالیتی که روی مسیر مشتری اثر گذاشته است، باید قابل مشاهده باشد.
اگر فروشنده فقط در پیام‌رسان شخصی خود یادداشت کرده باشد که مشتری با چه موضوعی مخالف بوده، این اطلاعات با تغییر مسئول از بین می‌رود. بهتر است نکته مهم در سابقه مکالمات یا فعالیت پرونده ثبت شود؛ کوتاه، روشن و بدون قضاوت شخصی.
۵. اقدام بعدی را با مسئول و موعد بنویسید
«پشتیبانی پیگیری کند» اقدام قابل اجرا نیست. چه کسی باید پیگیری کند؟ درباره چه چیزی؟ تا چه زمانی؟ پاسخ این سه پرسش باید در پرونده دیده شود.
نمونه بهتر:
«کارشناس پشتیبانی، راه‌اندازی دسترسی کاربران را بررسی کند و تا پایان روز دوشنبه نتیجه را در پرونده ثبت کند.»
اقدام بعدی باید به یک نفر یا یک نقش مشخص برسد. مسئولیت گروهی معمولاً به مسئولیت هیچ‌کس تبدیل نمی‌شود.
مالک پرونده و معیار پذیرش را از قبل مشخص کنید
یکی از خطاهای رایج این است که فروشنده پرونده را به پشتیبانی ارجاع می‌دهد، اما کسی در پشتیبانی رسماً آن را نمی‌پذیرد. در این حالت، هر دو تیم تصور می‌کنند دیگری در حال پیگیری است.
برای پیشگیری از این وضعیت، دو نقش را جدا کنید:
مسئول انتقال: فردی از فروش که اطلاعات را کامل می‌کند، وضعیت توافق‌ها را توضیح می‌دهد و پاسخ پرسش‌های اولیه تیم مقصد را می‌دهد.
مالک پس از انتقال: فرد یا نقش مشخصی در پشتیبانی که از زمان پذیرش، ادامه مسیر را دنبال می‌کند و اقدام‌های مربوط به مشتری به او ارجاع می‌شود.
مالک پرونده لزوماً برای همیشه همان فرد باقی نمی‌ماند. نکته مهم این است که در هر لحظه مشخص باشد پرونده روی میز چه کسی است.
معیار پذیرش باید قابل بررسی باشد
برای پذیرش پرونده، چند شرط روشن تعیین کنید. این شرط‌ها با توجه به نوع کار شما تغییر می‌کنند، اما معمولاً شامل این موارد هستند:
- مشخصات مشتری و افراد مرتبط کامل باشد.
- نیاز یا مسئله اصلی در یک یا دو جمله نوشته شده باشد.
- محصول یا خدمت مورد توافق مشخص باشد.
- وعده‌ها و موارد مشروط از هم جدا شده باشند.
- سابقه مکالمات مهم ثبت شده باشد.
- اقدام بعدی، مسئول و موعد داشته باشد.
- پشتیبانی بتواند با اطلاعات موجود کار را شروع کند.
- اگر اطلاعاتی کم است، پرسش مشخصی برای برگشت به فروش وجود داشته باشد.
پذیرش پرونده به معنی بی‌نقص بودن همه چیز نیست. ممکن است هنوز یک پرسش فنی پاسخ داده نشده باشد. در این صورت باید همان پرسش، مسئول پاسخ و موعد آن مشخص شود. پرونده نباید با برچسب کلی «ناقص» بین دو تیم رفت‌وبرگشت کند.
گردش کار انتقال را در چهار گام اجرا کنید
فرایند باید آن‌قدر روشن باشد که مدیر فروش و مدیر پشتیبانی بتوانند آن را در یک جلسه برای تیم توضیح دهند.
گام اول: فروش وضعیت پرونده را آماده می‌کند
پیش از اعلام پایان کار، فروشنده پرونده مشتری و فرصت فروش را مرور می‌کند. اطلاعات تکراری، یادداشت‌های مبهم و وعده‌های شفاهی باید به خلاصه‌ای قابل استفاده تبدیل شوند.
در این مرحله فروشنده باید از خود بپرسد: «اگر فردا در دسترس نباشم، آیا پشتیبان می‌تواند با این پرونده کار را ادامه دهد؟» اگر پاسخ منفی است، هنوز زمان انتقال نرسیده است.
گام دوم: جلسه یا پیام کوتاه انتقال انجام می‌شود
برای پرونده‌های ساده، خلاصه ثبت‌شده و یک اقدام مشخص ممکن است کافی باشد. برای پرونده‌های پیچیده‌تر، یک گفت‌وگوی کوتاه میان فروش و پشتیبانی لازم است. این گفت‌وگو نباید به مرور همه تاریخچه تبدیل شود. فقط مواردی مطرح شوند که بر ادامه کار اثر دارند.
ترتیب پیشنهادی چنین است:
۱. مشتری برای چه مسئله‌ای آمده است؟
۲. چه چیزی پذیرفته شده است؟
۳. حساس‌ترین انتظار یا محدودیت چیست؟
۴. نخستین اقدام پشتیبانی چیست؟
۵. چه پرسشی هنوز باز مانده است؟
گام سوم: پشتیبانی پرونده را بررسی و قبول می‌کند
پشتیبانی باید بتواند پرونده را ببیند و در صورت کافی بودن اطلاعات، پذیرش را ثبت کند. اگر اطلاعات ناکافی است، پرونده نباید بی‌صدا در صف بماند. دلیل برگشت باید روشن باشد؛ مثلاً «موعد شروع خدمت مشخص نیست» یا «فرد مسئول پاسخ فنی معرفی نشده است».
در سامانه‌ای که مشتری، فرصت، مکالمات، فعالیت‌ها و اقدام‌های بعدی را کنار هم نگه می‌دارد، این مرحله قابل پیگیری‌تر می‌شود. مدیر به جای پرسیدن «این پرونده دست چه کسی است؟» می‌تواند وضعیت و مسئول آن را بررسی کند.
گام چهارم: تماس نخست و نتیجه آن ثبت می‌شود
اولین تماس پشتیبانی فقط برای سلام و معرفی نیست. باید مشخص شود مشتری از ادامه مسیر چه می‌خواهد و آیا اطلاعات فروش با وضعیت واقعی او همخوانی دارد.
بعد از تماس، یک یادداشت کوتاه بنویسید:
- مشتری چه چیزی را تأیید کرد؟
- چه پرسشی مطرح شد؟
- چه اقدامی باید انجام شود؟
- مسئول اقدام چه کسی است؟
- موعد بررسی بعدی چه زمانی است؟
این ثبت، ادامه مسیر را از حافظه افراد بیرون می‌آورد. اگر اقدام دیگری لازم نیست، همین موضوع هم باید روشن باشد.
چک‌لیست اجرایی برای پذیرش پرونده
جدول زیر را می‌توانید با فرایند داخلی خود تطبیق دهید. لازم نیست همه ردیف‌ها برای همه کسب‌وکارها اجباری باشند. برای هر نوع محصول یا خدمت، مواردی را که واقعاً روی کار پشتیبانی اثر دارند نگه دارید.
| ردیف | مورد کنترل | پرسش پذیرش | مسئول تکمیل | وضعیت |
|---|---|---|---|---|
| ۱ | مشخصات مشتری | نام سازمان، فرد تماس و نقش او مشخص است؟ | فروش | ☐ |
| ۲ | مسئله اصلی | دلیل خرید در یک خلاصه روشن نوشته شده است؟ | فروش | ☐ |
| ۳ | توافق نهایی | محصول یا خدمت مورد توافق از موارد مشروط جدا شده است؟ | فروش | ☐ |
| ۴ | وعده‌های داده‌شده | هر وعده مسئول و وضعیت مشخص دارد؟ | فروش | ☐ |
| ۵ | سابقه ارتباط | مکالمات و فعالیت‌های مهم در پرونده ثبت شده‌اند؟ | فروش | ☐ |
| ۶ | حساسیت مشتری | محدودیت زمانی، فنی یا ارتباطی مشتری نوشته شده است؟ | فروش | ☐ |
| ۷ | مالک پرونده | مسئول پشتیبانی و جانشین او مشخص هستند؟ | پشتیبانی | ☐ |
| ۸ | اقدام نخست | اولین کار پشتیبانی، مسئول و موعد آن ثبت شده است؟ | پشتیبانی | ☐ |
| ۹ | پرسش‌های باز | موارد نیازمند پاسخ فروش یا فنی جدا شده‌اند؟ | هر دو تیم | ☐ |
| ۱۰ | پذیرش نهایی | پشتیبانی توان شروع کار با اطلاعات موجود را تأیید کرده است؟ | پشتیبانی | ☐ |
| ۱۱ | تماس نخست | نتیجه اولین ارتباط با مشتری ثبت شده است؟ | پشتیبانی | ☐ |
| ۱۲ | وضعیت بعدی | مرحله بعدی و زمان مرور پرونده مشخص است؟ | پشتیبانی | ☐ |
این جدول را به فرم طولانی و خسته‌کننده تبدیل نکنید. اگر فروشنده برای پر کردن آن مجبور شود چندین فیلد کم‌استفاده را تکمیل کند، احتمال ثبت اطلاعات بی‌کیفیت بیشتر می‌شود. هر ردیف باید به یک تصمیم یا اقدام واقعی کمک کند.
برای بررسی مرحله‌ای کار، می‌توانید از گردش کار فروش و پشتیبانی استفاده کنید. توضیح تسک‌های پس از فروش در CRM نشان می‌دهد چگونه قول‌های بعد از قرارداد را به کارهای روشن برای افراد مختلف تبدیل کنیم.
مثال فرضی: انتقال پرونده یک شرکت خدماتی
مثال زیر کاملاً فرضی است و فقط برای آموزش فرایند نوشته شده است.
فرض کنید یک شرکت خدمات فنی، سامانه‌ای برای ثبت مشتریان و پیگیری درخواست‌ها تهیه کرده است. فروشنده در چند جلسه با مدیر شرکت صحبت کرده و در پایان، توافق شده اطلاعات مشتریان در پرونده‌ها ثبت شوند و درخواست‌های پیگیری‌شده مسئول داشته باشند.
یادداشت ضعیف فروش ممکن است چنین باشد:
«مشتری خرید کرد. لطفاً برای راه‌اندازی با او تماس بگیرید.»
این یادداشت چند پرسش مهم را بی‌پاسخ می‌گذارد: چه کسانی کاربر هستند؟ مسئله اصلی شرکت چه بوده؟ راه‌اندازی از چه زمانی باید شروع شود؟ چه چیزی به مدیر شرکت گفته شده؟ اولین تماس درباره چه موضوعی باشد؟
نسخه بهتر می‌تواند چنین باشد:
«مسئله اصلی شرکت، پراکندگی سابقه تماس با مشتریان خدماتی است. مدیر شرکت تصمیم‌گیرنده است و سرپرست خدمات کاربر اصلی خواهد بود. توافق شده پرونده مشتری، سابقه مکالمات و اقدام بعدی هر درخواست در سامانه ثبت شود. هنوز زمان شروع کار با سرپرست خدمات قطعی نشده است. کارشناس پشتیبانی تا روز سه‌شنبه با سرپرست خدمات تماس بگیرد، زمان شروع را مشخص کند و نتیجه را ثبت کند. فروشنده درباره زمان شروع پاسخ‌گوی پرسش‌های احتمالی است.»
پشتیبانی پس از خواندن این خلاصه، پذیرش را انجام می‌دهد و اقدام نخست را بر عهده می‌گیرد. اگر سرپرست خدمات در تماس اول بگوید کاربران دیگری هم باید اضافه شوند، این موضوع در فعالیت پرونده ثبت می‌شود و مسئول بررسی آن مشخص خواهد بود.
در این مثال، هیچ نتیجه‌ای از پیش تضمین نشده است. فقط اطلاعاتی ثبت شده که برای ادامه کار لازم است. همین تفاوت میان «ثبت وضعیت» و «ادعای نتیجه» اهمیت دارد.
خطاهای رایج را با چند شاخص ساده کنترل کنید
انتقال با پیام مبهم
پیام‌هایی مانند «لطفاً رسیدگی شود» یا «مشتری ناراضی است» برای شروع کار کافی نیستند. پشتیبانی باید بداند نارضایتی از چه چیزی است و رسیدگی مورد انتظار چه شکلی دارد.
تحویل همه مسئولیت‌ها به پشتیبانی
فروش با انتقال پرونده از پاسخ‌گویی به قول‌های ثبت‌شده معاف نمی‌شود. اگر مشتری درباره وعده‌ای پرسید که در زمان فروش مطرح شده، فروشنده باید در پاسخ‌گویی به آن نقش داشته باشد. تحویل، پاک کردن مسئولیت قبلی نیست.
ثبت نکردن برگشت پرونده
گاهی پشتیبانی اطلاعات کافی ندارد. اگر دلیل برگشت ثبت نشود، پرونده بارها میان دو تیم جابه‌جا می‌شود. هر برگشت باید یک دلیل مشخص و یک اقدام بعدی داشته باشد.
تبدیل چک‌لیست به فرم تشریفاتی
اگر همه پرونده‌ها با یک الگوی یکسان و طولانی بررسی شوند، اعضای تیم بعد از مدتی فقط تیک می‌زنند. چک‌لیست باید با نوع خدمت، اندازه مشتری و میزان پیچیدگی پرونده تناسب داشته باشد.
استفاده از حساب مشترک
وقتی چند نفر با یک حساب مشترک کار می‌کنند، تشخیص مسئول فعالیت‌ها دشوار می‌شود. تفکیک دسترسی و حساب‌های فردی به مدیر کمک می‌کند بداند چه کسی اطلاعاتی را ثبت یا تغییر داده است. این موضوع باید با نقش افراد و سطح دسترسی مورد نیازشان تنظیم شود، نه با دسترسی کامل برای همه.
شاخص‌هایی که واقعاً ارزش بررسی دارند
گزارش مدیریتی زمانی مفید است که به یک پرسش کاری پاسخ دهد. برای کنترل این فرایند، این موارد را در دوره‌های منظم بررسی کنید:
- چه تعداد پرونده بدون مالک مشخص مانده است؟
- چند پرونده به دلیل اطلاعات ناقص برگشته است؟
- در چند پرونده اقدام بعدی و موعد ثبت نشده است؟
- کدام نوع اطلاعات بیشتر از بقیه ناقص می‌ماند؟
- فاصله میان اعلام انتقال و پذیرش پرونده چقدر است؟
- چند پرونده پس از پذیرش، تماس یا فعالیت ثبت‌شده ندارد؟
این اعداد به تنهایی خوب یا بد نیستند. باید علت تغییرشان را پیدا کنید. مثلاً افزایش پرونده‌های برگشتی می‌تواند از تغییر محصول، آموزش ناکافی یا پیچیده شدن مرحله فروش ناشی شود. پیش از تصمیم‌گیری، چند پرونده واقعی را بخوانید و گزارش را با تجربه روزانه تیم مقایسه کنید.
پرسش‌های رایج
پرونده را چه زمانی از فروش به پشتیبانی منتقل کنیم؟
وقتی توافق اصلی روشن شده و اطلاعات لازم برای شروع کار ثبت شده است. اگر هنوز درباره اصل خرید یا محدوده خدمت مذاکره می‌شود، پرونده فروش است. اگر مشتری وارد مرحله اجرا، استفاده یا دریافت خدمت شده، باید مالک پشتیبانی و اقدام نخست مشخص شوند.
اگر اطلاعات پرونده ناقص بود، پشتیبانی باید چه کار کند؟
پرونده را بدون توضیح کنار نگذارید. یک دلیل مشخص برای نقص بنویسید، فرد پاسخ‌گو را تعیین کنید و موعد برگشت اطلاعات را ثبت کنید. اگر بخشی از کار قابل شروع است، همان بخش را متوقف نکنید و پرسش باز را جداگانه دنبال کنید.
در شرکت کوچک، آیا به فرایند رسمی نیاز داریم؟
بله، اما نه لزوماً به فرایند طولانی. در تیم کوچک می‌توان با یک الگوی کوتاه شامل مسئله مشتری، توافق، مسئول، اقدام بعدی و موعد شروع کرد. هرچه تعداد افراد و مشتریان بیشتر شود، ثبت این موارد در پرونده و فعالیت‌های سامانه اهمیت بیشتری پیدا می‌کند.
اگر فروشنده پس از انتقال در دسترس نبود چه می‌شود؟
اطلاعات نباید فقط در ذهن فروشنده بماند. تصمیم‌ها، وعده‌ها، مکالمات مهم و موارد باز را در پرونده ثبت کنید. برای پرسش‌های پیش‌بینی‌نشده نیز جانشین فروشنده یا مسئول دوم تعیین کنید. در راهنمای آموزش CRM به تیم روی تمرین سناریوهای واقعی و ثبت ادامه مسیر مشتری تأکید شده است.
آیا همه مشتریان به یک چک‌لیست نیاز دارند؟
نه. پرونده‌ای با یک درخواست ساده، اطلاعات کمتری می‌خواهد؛ پرونده‌ای با چند کاربر، چند مرحله خدمت یا تعهدهای مختلف، کنترل بیشتری لازم دارد. چک‌لیست را بر اساس نقاطی بسازید که نبودشان واقعاً باعث تماس تکراری، تأخیر یا اختلاف در انتظار مشتری می‌شود.
از فردا چگونه شروع کنیم؟
از همه پرونده‌ها هم‌زمان شروع نکنید. یک نوع پرونده پرتکرار را انتخاب کنید؛ مثلاً مشتریانی که تازه قراردادشان نهایی شده است. سپس پنج مورد اجباری تعیین کنید: مسئله مشتری، توافق نهایی، افراد مرتبط، اقدام نخست و مالک پشتیبانی.
برای یک هفته، همین پنج مورد را در پرونده‌ها ثبت کنید. مدیر فروش چند پرونده را مرور کند و ببیند آیا خلاصه‌ها برای فردی خارج از گفت‌وگوی اولیه قابل فهم هستند یا نه. مدیر پشتیبانی نیز بررسی کند آیا با این اطلاعات می‌تواند تماس نخست را انجام دهد. هر موردی که مرتب ناقص می‌ماند، یا باید ساده‌تر شود یا آموزش کوتاهی برای آن در نظر بگیرید.
بعد از این آزمون، معیار پذیرش را نهایی کنید و وضعیت‌های روشن برای «آماده انتقال»، «در انتظار تکمیل»، «پذیرفته‌شده» و «در حال پیگیری» بسازید. در ادامه، گزارش را به چند پرسش محدود کنید تا تیم زیر بار سنجش‌های بی‌فایده نرود.
اگر می‌خواهید این فرایند را متناسب با ساختار فروش و پشتیبانی خود بررسی کنید، از صفحه تماس با کلید و درخواست دمو شروع کنید و مسئله، نقش‌ها و اطلاعاتی را که امروز میان دو تیم گم می‌شود، با خودتان مرور کنید.
