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