فهرست مقاله
تلفن گویا یا IVR سامانه‌ای برای تعامل با تماس‌گیرنده و هدایت درخواست اوست. پخش پیام فقط یکی از اجزای آن است؛ سامانه باید ورودی را دریافت کند، وضعیت گفت‌وگو را بشناسد و بداند پس از هر انتخاب چه اتفاقی می‌افتد. یک منوی ظاهراً ساده، در عمل با سکوت، انتخاب نامعتبر، قطع تماس و درخواست کارشناس روبه‌رو می‌شود. این مقاله یک روش پیشنهادی برای طراحی این مسیرها ارائه می‌کند؛ مثال‌ها فرضی هستند و گزارش عملکرد محصول خاصی نیستند.
در VoiceXML 2.0 که در ۲۶ اسفند ۱۳۸۲ به‌عنوان توصیه‌نامهٔ W3C منتشر شد، تعامل می‌تواند شامل صدای ضبط‌شده، گفتار تولیدشده، تشخیص گفتار و ورودی کلیدی DTMF باشد. بنابراین تفاوت تلفن گویا و پاسخ‌گوی مبتنی بر مدل زبانی را نباید فقط به «کلید در برابر صدا» تقلیل داد. مرجع تصمیم، دامنهٔ گفت‌وگو و حدود اقدام هم باید بررسی شوند.
۱. تماس ورودی را به یک مسیر مشخص تبدیل کنید
پیش از نوشتن متن خوشامد، درخواست‌های متداول را فهرست کنید. برای مثال فرضی، تماس‌گیرنده ممکن است اطلاعات ساعات کاری بخواهد، وضعیت درخواست خود را پیگیری کند یا با کارشناس صحبت کند. این سه نیاز، لزوماً سه منوی تو در تو نمی‌خواهند. هر گزینه باید مقصد روشن داشته باشد و تیم بداند چرا آن گزینه در همان مرحله ارائه شده است. گزینه‌ای که مقصد آن مشخص نیست، حتی با پیام صوتی زیبا هم مسیر قابل استفاده‌ای نمی‌سازد.
مدل پیشنهادی را به‌صورت وضعیت‌ها بنویسید: ورود، ارائهٔ گزینه‌ها، دریافت پاسخ، اجرای مسیر و پایان یا انتقال. برای هر وضعیت مشخص کنید کدام ورودی قابل قبول است و چه رویدادی آن را تغییر می‌دهد. ساعات کاری را هم در همین طراحی وارد کنید. انتقال به داخلی‌ای که در آن ساعت پاسخ نمی‌دهد، پایان منطقی تعامل نیست. مسیر خارج از ساعت کاری باید پیام روشن و امکان مناسب همان سازمان داشته باشد، بدون اینکه وعدهٔ پاسخ‌گویی نامشخص بدهد.
۲. ورودی DTMF و گفتار را جدا آزمایش کنید
DTMF نام روش ورودی کلیدی با ترکیب دو فرکانس است. در تجربهٔ کاربر، فشردن یک کلید ممکن است به انتخاب یک گزینه یا ورود بخشی از اطلاعات منجر شود. در طراحی، دریافت یک رقم را از تکمیل یک رشتهٔ چندرقمی جدا کنید. اگر ورودی ناقص است، سامانه باید بداند هنوز منتظر ادامه است یا زمان انتظار تمام شده است. رفتار پاک کردن، تکرار و پایان ورودی نیز باید با تجربهٔ تماس‌گیرنده سازگار باشد.
ورودی گفتاری مسئلهٔ دیگری دارد: کاربر ممکن است همان درخواست را با واژه‌های متفاوت بیان کند. برای سامانهٔ دارای تشخیص گفتار، نمونه‌های فارسی محاوره‌ای، مکث، تکرار و نام خدمت را بررسی کنید. راهنمای ارزیابی تشخیص گفتار فارسی به تفکیک خطای رونویسی و خطای انجام وظیفه می‌پردازد. دریافت درست کلیدها، موفقیت مسیر گفتاری را ثابت نمی‌کند و خوانا بودن متن خروجی نیز الزاماً به معنای انتخاب درست مقصد نیست.
۳. منو و پیام صوتی را با یک هدف بنویسید
هر پیام بهتر است از تماس‌گیرنده یک تصمیم روشن بخواهد. در مثال فرضی، «برای آگاهی از ساعات کاری، کلید یک را بزنید» هم هدف را مشخص می‌کند و هم ورودی مورد انتظار را. متن منو را با نام‌های داخلی نامفهوم یا توضیح چند موضوع نامرتبط سنگین نکنید. اگر کاربر برای فهم گزینه باید پیام را دوباره از ابتدا بشنود، ساختار را بازبینی کنید. طول مناسب پیام به مخاطب و کاربرد بستگی دارد و یک عدد ثابت برای همهٔ سازمان‌ها وجود ندارد.
نام گزینه‌ها را در مسیرهای مختلف یکسان نگه دارید. اگر در شروع «پیگیری درخواست» گفته‌اید، در مرحلهٔ بعد ناگهان از اصطلاح داخلی دیگری استفاده نکنید. بازگشت به منوی قبل و تکرار پیام باید قابل کشف باشد. پیش از انتشار، متن را با صدای واقعی گوش کنید؛ متن کوتاه روی صفحه ممکن است در شنیدن مبهم باشد. اعداد، نام‌های تخصصی و نشانی‌ها نیازمند توجه جداگانه‌اند. آزمون شنیداری را با آزمون درست بودن مسیر تماس همراه کنید.
۴. سکوت، خطا و انتقال را به حال خود رها نکنید
برای سکوت و ورودی نامعتبر، پاسخ‌های متفاوت تعریف کنید. سکوت ممکن است ناشی از نشنیدن پیام، مشکل دستگاه یا نیاز به زمان باشد؛ انتخاب نامعتبر ممکن است نشان دهد گزینه‌ها روشن نبوده‌اند. در طراحی پیشنهادی، تعداد تلاش مجدد محدود و مسیر خروج مشخص است. تکرار بی‌پایان همان جمله، تعامل را بهتر نمی‌کند. سامانه باید پس از تلاش‌های تعریف‌شده به یک مسیر مناسب برسد؛ مانند منوی ساده‌تر، توضیح تکمیلی یا ارتباط با کارشناس.
در انتقال به کارشناس، نتیجهٔ واقعی انتقال اهمیت دارد. آیا مقصد پاسخ داد، تماس در صف قرار گرفت یا مقصد در دسترس نبود؟ همراه انتقال، زمینهٔ ضروری درخواست را در حدود مجاز منتقل کنید تا کاربر مجبور به تکرار همهٔ مراحل نباشد. اطلاعات شخصی را فقط به اندازهٔ نیاز و با قواعد روشن نگه دارید. نمایش یک برچسب «منتقل شد» بدون بررسی وضعیت تماس، آزمون کافی نیست. برای سناریوی عدم پاسخ، رفتار جایگزین باید از قبل مشخص باشد.
۵. معیار پذیرش را از مسیرهای واقعی بسازید
مجموعهٔ آزمون باید از نیازهای فهرست‌شده در ابتدای طراحی ساخته شود. برای هر نیاز، ورود معمولی، انتخاب اشتباه، سکوت و انتقال ناموفق را امتحان کنید. نتیجه را با معیار همان سناریو ثبت کنید؛ رسیدن به مقصد، شنیدن پاسخ مناسب یا پایان روشن تماس. اگر فقط تعداد تماس‌های پاسخ‌داده‌شده را نگاه کنید، تماس‌های گرفتار در منو پنهان می‌مانند. گزارش آزمون بهتر است محل شکست را هم نشان دهد: دریافت ورودی، تصمیم مسیر یا انتقال تماس.
برای دیدن حوزهٔ محصول، صفحهٔ تلفن گویا را بخوانید. اگر نیاز سازمان از مسیرهای مشخص فراتر می‌رود و پاسخ از دانش داخلی لازم است، معماری تلفن هوشمند سازمانی نقطهٔ شروع بعدی است. راهنمای عامل‌های صوتی OpenAI نیز دو رویکرد صوت مستقیم و زنجیرهٔ تبدیل گفتار و متن را توضیح می‌دهد. انتخاب فناوری باید پس از روشن شدن دامنهٔ پاسخ و معیار پذیرش انجام شود؛ اضافه کردن مدل، ابهام مسیرهای فعلی را خودکار برطرف نمی‌کند.
منابع و مطالعهٔ بیشتر
بررسی منابع: ۲۲ مهر ۱۴۰۵. تحلیل‌ها و پیشنهادهای اجرایی، جمع‌بندی نویسنده‌اند.
