مشتری تماس می گیرد، تلفن کارشناس زنگ می خورد و پرونده ای روی نمایشگر باز می شود؛ اما نام نمایش داده شده متعلق به فرد دیگری است. همین اشتباه کوچک کافی است تا کارشناس درباره سفارش یا درخواست پشتیبانی شخص اشتباهی صحبت کند. اتصال برقرار شده است. بااین حال، اتصال سانترال به دیتابیس مشتریان هنوز درست کار نمی کند.
در یکپارچه سازی سیستم های تلفنی، نمایش شماره تماس گیرنده فقط نقطه شروع است. تیم فنی باید شماره را تفسیر کند، رکورد مرتبط را پیدا کند، مسیر تماس را دنبال کند و نتیجه مکالمه را در پرونده مناسب بنویسد. انتقال تماس، شماره های مشترک، قطعی شبکه و رویدادهای تکراری این مسیر را پیچیده می کنند. اگر طراحی فقط تماس مستقیم میان مشتری و یک داخلی را پوشش دهد، خطاها هنگام استفاده روزمره خودشان را نشان می دهند.
SIP چه نقشی در اتصال به بانک اطلاعاتی دارد؟
آیا پروتکل SIP خودش اطلاعات مشتری را از دیتابیس استخراج می کند؟ چنین قابلیتی در وظیفه اصلی آن تعریف نشده است. SIP برای ایجاد، تغییر و پایان دادن به نشست ارتباطی به کار می رود و پیام هایی مانند INVITE و BYE را میان تجهیزات جابه جا می کند. اطلاعات موجود در پیام های سیگنالینگ می تواند ورودی فرایند شناسایی تماس گیرنده باشد، اما توسعه دهنده باید منطق جست وجوی مشتری و اتصال به بانک اطلاعاتی را جداگانه پیاده سازی کند.
این تفکیک در طراحی اهمیت دارد. وقتی یک تماس وارد سانترال می شود، سرویس واسط می تواند رویداد مربوط به آن را دریافت کند و شماره استخراج شده را برای جست وجو به سامانه مشتریان بفرستد. سپس رابط کارشناس، پرونده مرتبط را نمایش می دهد. قرار دادن این مسئولیت ها در یک سرویس مشخص، عیب یابی را هم ساده تر می کند؛ چون می توان فهمید خطا در دریافت تماس رخ داده، در تطبیق شماره یا در نمایش پرونده.
RTP مسئول انتقال رسانه هایی مانند صداست و RTCP اطلاعات کنترلی و گزارش هایی درباره دریافت رسانه فراهم می کند. این دو پروتکل جایگزین رابط اتصال به دیتابیس نیستند. برای نمایش نام مشتری، معمولاً نیازی به بررسی محتوای بسته های صوتی نداریم؛ داده های سیگنالینگ و رویدادهای سانترال مسیر مناسب تری فراهم می کنند.
در پروژه هایی که تجهیزات قدیمی دارند، ممکن است تیم با H.323 یا رابط اختصاصی سازنده هم روبه رو شود. بنابراین، پیش از انتخاب روش اتصال باید قابلیت های مدل سانترال، نسخه نرم افزار و مجوزهای فعال آن بررسی شود. عبارت «پشتیبانی از وی او آی پی» به تنهایی درباره امکانات یکپارچه سازی اطلاعات کافی نمی دهد.
انتخاب رابط اتصال؛ رویداد زنده یا گزارش پایان تماس؟
فرض کنید مشتری پیش از پاسخ کارشناس، ده ثانیه در صف منتظر می ماند. اگر سامانه فقط گزارش نهایی تماس را دریافت کند، پرونده او هنگام زنگ خوردن باز نمی شود. اطلاعات دیر می رسد. برای شناسایی لحظه ای باید رابطی انتخاب شود که وضعیت تماس جاری را در اختیار سرویس واسط بگذارد.
در سانترال های مبتنی بر Asterisk، رابط AMI رویدادهای مدیریتی و اطلاعات کانال ها را ارائه می کند. ARI نیز رابط REST و رویدادهای JSON روی WebSocket دارد و برای ساخت برنامه هایی با کنترل کانال، پل ارتباطی و رسانه کاربرد دارد. انتخاب میان آن ها به میزان کنترل موردنیاز بستگی دارد؛ نمایش پرونده مشتری لزوماً به همان معماری ای نیاز ندارد که برای ساخت یک جریان تماس اختصاصی لازم است.
گزارش نهایی همچنان کاربرد دارد. Asterisk برای ثبت اطلاعات تماس از CDR و CEL استفاده می کند و CEL جزئیات بیشتری از تغییر وضعیت کانال ها فراهم می کند. تیم توسعه می تواند رویدادهای زنده را برای نمایش پرونده و داده های ثبت شده را برای بررسی و تکمیل سوابق به کار بگیرد.
پیش از اجرا، چند سؤال باید جواب مشخص داشته باشد: رابط انتخابی انتقال تماس را چگونه گزارش می کند؟ آیا قطع و وصل ارتباط باعث ازدست رفتن رویدادها می شود؟ محدودیت تعداد اتصال چیست؟ پاسخ این پرسش ها باید از مستندات همان نسخه و آزمایش روی سانترال هدف به دست بیاید.
شماره تلفن، کلید ساده ای که دردسر درست می کند
یک شماره موبایل ممکن است در پرونده مشتری با صفر ابتدایی ذخیره شده باشد، اما اپراتور مخابراتی همان شماره را با کد کشور تحویل دهد. گاهی هم کاربر آن را با فاصله، خط تیره یا ارقام فارسی وارد کرده است. مقایسه مستقیم رشته ها شکست می خورد. پیش از جست وجو، باید شماره ورودی و شماره ذخیره شده طبق یک قاعده مشترک نرمال سازی شوند.
برای شماره های قابل تبدیل به قالب بین المللی، نگهداری نسخه ای مطابق ساختار E.164 انتخاب مناسبی برای طراحی است. شماره خام را هم حفظ کنید. این مقدار هنگام بررسی اختلاف میان داده اپراتور، خروجی سانترال و رکورد مشتری کمک می کند و مانع از آن می شود که تیم پشتیبانی فقط نتیجه تبدیل را ببیند.
اما پاک سازی شماره باید محتاطانه باشد. حذف بی قاعده صفر، افزودن خودکار کد کشور یا بریدن چند رقم ابتدایی می تواند دو شماره متفاوت را به مقدار مشابه تبدیل کند. داخلی های سازمانی و شماره های کوتاه خدماتی نیز به قواعد جداگانه نیاز دارند.
مشکل بعدی، شماره مشترک است. تلفن یک شرکت ممکن است در پرونده مدیر خرید، حسابداری و مسئول انبار ثبت شده باشد. در چنین وضعیتی بهتر است رابط کارشناس چند گزینه را نمایش دهد و دلیل تطبیق را بنویسد. انتخاب خودکار اولین نتیجه، احتمال ثبت سابقه در پرونده اشتباه را بالا می برد؛ به خصوص وقتی ترتیب نتایج دیتابیس بعد از یک تغییر فنی عوض شود.
نمایش پرونده پیش از پاسخ؛ بودجه زمانی را کجا مصرف می کنیم؟
شناسایی لحظه ای یعنی پرونده در زمانی باز شود که هنوز برای کارشناس کاربرد دارد. عدد هدف را باید تعریف کرد. برای نمونه، تیم می تواند نمایش اولیه را در صدک ۹۵ کمتر از یک ثانیه هدف بگذارد؛ این عدد یک معیار پیشنهادی برای پروژه است و باید با شبکه و حجم تماس واقعی ارزیابی شود.
زمان دریافت رویداد، جست وجوی شماره، کنترل دسترسی و ارسال نتیجه به مرورگر را جداگانه اندازه بگیرید. میانگین کافی نیست. اگر بیشتر درخواست ها سریع باشند اما بخشی از تماس ها چند ثانیه تأخیر داشته باشند، کارشناس همان موارد کند را در گفت وگو با مشتری احساس می کند.
ساخت ایندکس روی شماره نرمال شده، نقطه شروع مناسبی است. جست وجوی شماره در ستونی که برای آن ایندکس ندارید، با افزایش تعداد پرونده ها می تواند هزینه بیشتری پیدا کند. همچنین بهتر است ابتدا نام، شناسه مشتری و وضعیت درخواست باز را دریافت کنید؛ بارگذاری پیوست ها و تاریخچه طولانی می تواند پس از نمایش اولیه انجام شود.
کش هم مفید است، ولی سیاست اعتبار آن اهمیت دارد. اگر مشتری شماره خود را تغییر دهد و کش قدیمی باقی بماند، سرعت بیشتر به نمایش پرونده نادرست منجر می شود. زمان انقضا و روش حذف داده تغییرکرده باید در طراحی مشخص باشد.
اتصال مستقیم به دیتابیس یا استفاده از API؟
در یک نصب فرضی، برنامه نویس برای سرعت کار، دسترسی نوشتن به جدول مشتریان را به سرویس سانترال می دهد. چند ماه بعد، تیم سامانه مشتریان ساختار جدول فعالیت ها را تغییر می دهد. تماس ها برقرار می شوند، اما ثبت سوابق خطا می دهد. این وابستگی هزینه دارد.
استفاده از API سامانه مشتریان، مسیر قابل کنترل تری برای بسیاری از پروژه ها فراهم می کند. رابط می تواند مجوزها، اعتبارسنجی و قواعد ثبت فعالیت را اعمال کند و تغییرات داخلی دیتابیس را از سرویس تلفنی پنهان نگه دارد. البته API نیز به قرارداد مشخص، نسخه بندی و مدیریت محدودیت درخواست نیاز دارد.
در اتصال سانترال به نرم افزار CRM، بهتر است عملیات جست وجوی مشتری از عملیات ثبت تماس جدا باشد. سرویس شناسایی به داده محدودی نیاز دارد، درحالی که ثبت سابقه باید شناسه تماس، زمان ها، کارشناس و نتیجه را اعتبارسنجی کند.
گاهی اتصال مستقیم اجتناب ناپذیر است. در این حالت، دسترسی خواندن را به جدول یا نمای مشخص محدود کنید و عملیات نوشتن را از مسیر کنترل شده انجام دهید. اجرای کوئری سنگین و هم زمان در مسیر حساس پردازش تماس، وابستگی نامناسبی میان پاسخ گویی تلفنی و عملکرد بانک اطلاعاتی ایجاد می کند.
یک تماس چرا چند شناسه دارد؟
مشتری با واحد فروش تماس می گیرد، کارشناس او را به پشتیبانی منتقل می کند و نفر دوم برای مشورت، داخلی دیگری را وارد مکالمه می کند. برای مشتری یک گفت وگو رخ داده است. در سانترال، این مسیر می تواند چند کانال و چند رویداد ایجاد کند.
در Asterisk، مقدار Uniqueid شناسه کانال است و Linkedid برای مرتبط کردن کانال های وابسته به یکدیگر کاربرد دارد. بنابراین، ذخیره هر رویداد کانال به عنوان یک تماس مستقل ممکن است تعداد سوابق را بیشتر از تماس های واقعی نشان دهد.
مدل داده باید این تفاوت را پوشش دهد. می توان یک رکورد اصلی برای تعامل مشتری ساخت و مراحل تماس، داخلی های درگیر و انتقال ها را زیر آن نگه داشت. در این طراحی، گزارش مدیریتی تعداد تعامل ها را از تعداد تلاش های پاسخ گویی جدا می کند.
شناسه SIP Call-ID هم برای بررسی سیگنالینگ مفید است، اما نباید بدون آزمایش آن را کلید مشترک سراسر مسیر فرض کرد. رفتار تجهیزات واسط و نحوه ایجاد بخش های مختلف تماس را بررسی کنید. افزودن شناسه سانترال به کلید داخلی نیز کمک می کند داده دو مرکز تلفن هنگام تجمیع با هم تداخل پیدا نکند.
ثبت خودکار سوابق در پرونده و برچسب مرتبط
برچسب «تماس بی پاسخ» چه زمانی باید اضافه شود؟ وقتی یک داخلی جواب نمی دهد، ممکن است داخلی دیگری همان تماس را پاسخ دهد. اگر سرویس با نخستین رویداد بی پاسخ، وضعیت نهایی بسازد، پرونده مشتری اطلاعات گمراه کننده خواهد داشت.
بهتر است ثبت سابقه در چند مرحله انجام شود. هنگام ورود تماس، یک فعالیت اولیه با وضعیت موقت ساخته شود؛ پس از پاسخ، اطلاعات کارشناس به آن اضافه شود و در پایان، نتیجه بر اساس مسیر کامل تماس به روزرسانی شود. برای تماس خروجی نیز شماره مقصد و ارتباط آن با پرونده باید پیش از ثبت نهایی کنترل شود.
برچسب ها به قواعد روشن نیاز دارند. «تماس ورودی»، «درخواست فروش» و «نیازمند پیگیری» از یک جنس نیستند؛ اولی جهت تماس را توصیف می کند، دومی موضوع گفت وگو را و سومی اقدام بعدی را. بهتر است این اطلاعات در فیلدهای جداگانه نگهداری شوند و برچسب صرفاً برای دسته بندی موردنیاز تیم استفاده شود.
موضوع مکالمه را از شماره تلفن حدس نزنید. می توان انتخاب مشتری در منوی صوتی را به عنوان نشانه اولیه ثبت کرد، اما تأیید کارشناس یا قواعد معتبر کسب وکار برای تعیین موضوع نهایی لازم است. همچنین منشأ برچسب، زمان ثبت و عامل تغییر را نگه دارید تا اصلاح خطا امکان پذیر باشد.
رویداد تکراری و قطعی شبکه را جدی بگیرید
اگر ارتباط سرویس واسط قطع شود، چه چیزی از تماس باقی می ماند؟ پاسخ به قابلیت سانترال و معماری ثبت بستگی دارد. دریافت رویداد زنده به تنهایی تضمین نمی کند که سرویس پس از اتصال مجدد، رویدادهای زمان قطعی را بازیابی کند.
برای کاهش ازدست رفتن اطلاعات، سرویس می تواند رویدادهای دریافتی را پیش از پردازش در صف یا مخزن پایدار نگه دارد. سپس پردازشگر، فعالیت مشتری را ثبت کند. بااین حال، قطعی پیش از دریافت رویداد همچنان به سازوکار تطبیق با گزارش های سانترال نیاز دارد.
ثبت باید تکرارپذیر باشد. یعنی ارسال دوباره یک رویداد، سابقه دوم نسازد. کلید مناسب می تواند از شناسه مرکز تلفن، شناسه تعامل و شناسه معتبر رویداد تشکیل شود؛ انتخاب جزئیات آن به داده های رابط بستگی دارد.
یک خطای ظریف زمانی رخ می دهد که سرویس رکورد را ذخیره می کند، اما پاسخ موفقیت در شبکه گم می شود. فرستنده دوباره تلاش می کند. اگر کنترل یکتایی وجود نداشته باشد، کارشناس دو سابقه مشابه می بیند و گزارش تعداد تماس ها هم اشتباه می شود.
ترتیب رویدادها را نیز بررسی کنید. پردازش موازی ممکن است ثبت پایان تماس را جلوتر از به روزرسانی پاسخ انجام دهد. نگهداری وضعیت نهایی معتبر و کنترل انتقال وضعیت ها، از برگشت یک تماس پایان یافته به وضعیت «در حال مکالمه» جلوگیری می کند.
شناسایی تماس گیرنده با احراز هویت فرق دارد
نمایش نام مشتری به کارشناس کمک می کند گفت وگو را شروع کند، اما شماره ورودی برای اجازه دسترسی به اطلاعات حساس کافی نیست. تلفن مشترک، واگذاری شماره و امکان جعل هویت تماس از دلایل این محدودیت هستند. برای تغییر اطلاعات مهم، باید فرایند احراز هویت جداگانه وجود داشته باشد.
استاندارد SIP Identity سازوکاری برای هویت تأییدشده در سیگنالینگ تعریف می کند، ولی وجود استاندارد به معنی پشتیبانی آن در تمام مسیر تماس نیست. تیم فنی باید امکانات اپراتور و تجهیزات را بررسی کند و نتیجه شناسایی شماره را با سطح اعتماد مناسب نمایش دهد.
مجوز مشاهده پرونده هم اهمیت دارد. کارشناس یک صف نباید صرفاً به دلیل دریافت رویداد تماس، اطلاعات واحد دیگری را ببیند. سرویس واسط باید هویت کاربر و سطح دسترسی او را هنگام نمایش داده کنترل کند.
برای فایل ضبط شده نیز همین قاعده را به کار ببرید. لینک عمومی یا آدرس قابل حدس انتخاب مناسبی نیست؛ دسترسی زمان دار، ثبت مشاهده و محدودکردن مجوز دریافت فایل، کنترل عملی تری فراهم می کند. رمزگذاری مسیر ارتباطی هم باید متناسب با رابط های مورد استفاده انجام شود، چون حفاظت از سیگنالینگ، API و رسانه تنظیمات یکسانی ندارد.
آزمون نهایی را با تماس های دردسرساز انجام دهید
یک تماس مستقیم موفق، برای تأیید پروژه کافی نیست. شماره ناشناس را آزمایش کنید. سپس تماس با شماره مشترک، انتقال میان دو داخلی، قطع در صف، تماس هم زمان و پاسخ دیرهنگام API را بررسی کنید؛ همین سناریوها ضعف مدل داده و منطق برچسب گذاری را آشکار می کنند.
در یک آزمایش فرضی، ارتباط سامانه مشتریان را هنگام مکالمه برای سی ثانیه قطع کنید. بعد از بازگشت ارتباط، بررسی کنید سابقه چند بار ثبت شده، مدت مکالمه چه مقداری دارد و نتیجه تماس در کدام پرونده قرار گرفته است. عدد مدت انتظار را هم با مدت گفت وگو اشتباه نگیرید.
شاخص های پایش باید با هدف پروژه ارتباط داشته باشند. زمان نمایش پرونده، تعداد تطبیق های مبهم، سوابق تکراری، خطاهای ثبت و حجم صف پردازش، اطلاعات کاربردی تری از یک پیام کلی «سیستم فعال است» می دهند. برای هرکدام آستانه و مسئول پیگیری مشخص کنید.
یکپارچه سازی قابل اتکا زمانی شکل می گیرد که تیم بتواند مسیر تماس را از ورود به سانترال تا ثبت نتیجه در پرونده مشتری دنبال کند. برای مطالعه مطالب مرتبط با زیرساخت های ارتباطی و سامانه های سازمانی، بخش فناوری را ببینید. گزارش ها و مطالب دیگر این حوزه نیز در سایت خبری غرب پرس در دسترس است.
