برنامه‌نویسی و شخصی‌سازی سیستم تلفنی شرکت

نیاز کاری را به قابلیت مشخص تبدیل می‌کنیم: کدام اطلاعات در دسترس باشند، تماس چه مسیری را برود و چه نتیجه‌ای برای کاربر ثبت شود. این کار می‌تواند جست‌وجو و ثبت دستی را کمتر کند یا مسیر پاسخ‌گویی را با روند واقعی شرکت هماهنگ کند.

• هدایت تماس بر اساس اطلاعات مجاز سامانه: مثلاً تماس مربوط به درخواست فعال به واحد مسئول همان درخواست برسد.
• ثبت نتیجه در نرم‌افزار پیگیری: اطلاعات پایان تماس در جای مشخص ثبت شود تا همکار بداند چه موردی ادامه کار می‌خواهد.
• گزارش اختصاصی: داده‌های مجاز تماس با ستون‌ها و تعریف‌هایی نمایش داده شوند که برای مدیریت پاسخ‌گویی لازم‌اند.

این‌ها نمونه نیاز قابل بررسی‌اند، نه محصول آماده یا نمونه‌کار مشتری. در گفت‌وگو، کار فعلی و تغییر موردنیاز را روشن می‌کنیم؛ تهیه سند فنی یا انتخاب روش برنامه‌نویسی، شرط درخواست نیست.

در ایزابل، نسخه مرکز، افزونه‌ها، محل نصب و دسترسی مجاز به بخش‌های مرتبط بررسی می‌شوند. سپس مشخص می‌کنیم منطق جدید در مرکز تلفن اجرا می‌شود یا به برنامه‌ای برای ارتباط با سامانه دیگر نیاز دارد. قابل توسعه بودن ایزابل، اتصال آماده به همه نرم‌افزارها نیست.

برای نیاز مرتبط با سیسکو، مدل و نرم‌افزار گوشی و مرکز مقصد هم مهم‌اند. ممکن است تغییر فقط در مرکز تلفن یا نرم‌افزار متصل لازم باشد؛ برنامه جدید لزوماً روی گوشی نصب نمی‌شود. ساخت برنامه برای خود دستگاه یا تغییر نرم‌افزار آن به قابلیت همان مدل وابسته است.

API رابطی برای ارسال و دریافت اطلاعات میان نرم‌افزارهاست. دسترسی به آن، نوع اطلاعات مجاز، محدودیت نسخه خریداری‌شده و همکاری فروشنده بررسی می‌شوند. داشتن API به معنی دسترسی به همه داده‌ها و عملیات نیست. اگر رابط لازم در دسترس نباشد، امکان اجرای محدودتر یا کنارگذاشتن همان بخش پیش از ساخت روشن می‌شود.

اگر برنامه یا افزونه اختصاصی قبلی وجود داشته باشد، مستندات، مجوز تغییر و مسئول نگهداری آن هم در بررسی می‌آیند. مشخصات فنی و نمونه داده آزمایشی را با مسئولان دو سیستم هماهنگ می‌کنیم؛ کار بر اساس دسترسی مجاز انجام می‌شود.

در یک مثال فرضی، تماس مشتری دارای درخواست فعال باید به واحد مسئول آن درخواست برسد. فرض این مثال، وجود راه مجاز دریافت اطلاعات از سامانه شرکت است. اگر شماره ناشناخته باشد یا چند پرونده مرتبط پیدا شود، تماس به مسیر عمومی توافق‌شده می‌رود و پرونده‌ای حدسی انتخاب نمی‌شود.

• اگر سامانه دیر پاسخ دهد یا قطع باشد، حد انتظار و مسیر جایگزین تماس مشخص می‌شوند.
• اگر کارشناس پاسخ ندهد، مقصد بعدی تماس از خطای ارتباط نرم‌افزار تفکیک می‌شود.
• در انتقال تماس، اطلاعات هر مرحله و افراد مرتبط طبق تعریف گزارش ثبت می‌شوند.
• اطلاعات نمایش‌داده‌شده، کاربران مجاز و مدت نگهداری داده با دامنه سفارش هماهنگ می‌شوند.

شماره تماس برای پیدا کردن پرونده یا انتخاب مسیر مفید است، اما به‌تنهایی هویت فرد را ثابت نمی‌کند. در گزارش نیز «پاسخ‌داده‌شده» ممکن است فقط پاسخ منوی صوتی باشد؛ معنی وضعیت‌ها با روند واقعی پاسخ‌گویی تعریف و آزمایش می‌شود.

در همین مثال، نمایش پرونده، ثبت نتیجه فروش یا ساخت داشبورد جزو کار نیستند مگر جدا توافق شوند. قابلیت‌ها، موارد خارج از سفارش و نتیجه مورد انتظار هر آزمون پیش از اجرا ثبت می‌شوند؛ درخواست تازه نیز پیش از اضافه‌شدن، از نظر زمان و هزینه بررسی می‌شود.

• اتصال تلفن به CRM

  نمایش پرونده و ثبت تماس در نرم‌افزار مشتریان.

• تلفن گویا

  انتخاب واحد و مسیر ادامه تماس از منوی صوتی.

• صف تماس

  توزیع تماس میان پاسخ‌گوها و مدیریت انتظار.

• نظرسنجی تلفنی

  دریافت پاسخ پس از تماس و تعیین محل ثبت نتیجه.

برای هرکدام ابتدا امکانات فعلی بررسی می‌شوند. اگر چند نیاز به هم مرتبط باشند، دامنه مشترک آن‌ها در یک سفارش قابل بررسی است؛ وجود چند قابلیت لزوماً چند پروژه جدا نمی‌خواهد.

اگر خط هنوز به مرکز متصل نیست، راه‌اندازی سیپ‌ترانک به‌عنوان پیش‌نیاز مشخص می‌شود. اتصال خط، تنظیمات معمول و توسعه قابلیت اختصاصی کارهای متفاوتی‌اند.

قابلیت جدید، در صورت امکان، ابتدا در محیط یا مسیر جدا با داده ساختگی بررسی می‌شود. رفتار عادی، شماره ناشناخته، بی‌پاسخ‌ماندن و خطای ارتباط، همراه با دسترسی کاربران مجاز و غیرمجاز آزمایش می‌شوند.

در انتقال به مرکز فعال، حفظ تنظیمات و اطلاعات لازم، امکان بازگشت و ادامه پاسخ‌گویی اهمیت دارند. پس از اجرا، هم قابلیت جدید و هم تماس‌های معمول قبلی بررسی می‌شوند.

مدت اجرای فنی و توقف احتمالی تماس‌ها جدا برآورد می‌شوند؛ اجرای بدون قطعی برای همه سیستم‌ها از پیش قابل وعده نیست. اگر بخشی منتظر فروشنده یا مجوز باشد، همان بخش و مسئول پیگیری مشخص می‌مانند. نتیجه یک تماس موفق جای آزمون حالت‌های مهم سفارش را نمی‌گیرد.

اقلام تحویل و اجازه استفاده یا تغییر آن‌ها پیش از اجرا توافق می‌شوند: کد بخش نوشته‌شده، بسته نصب، تنظیمات و راهنمای استفاده یا مدیریت. کد و حقوق محصول یا افزونه شرکت دیگر تابع مجوز همان محصول‌اند و تحویل همه کدهای آن پیش‌فرض نیست.

• قابلیت اجراشده، نتیجه آزمون‌ها، محدودیت‌ها و کارهای باقی‌مانده.
• نسخه‌ها، محل تنظیمات و نرم‌افزارها یا مجوزهای لازم برای ادامه کار.
• راهنمای نصب یا بازگرداندن بخش توافق‌شده و تحویل امن رمزها و کلیدهای اتصال.
• مسئول نگهداری، روش دریافت اصلاحات و شرایط ادامه کار توسط پشتیبان بعدی.

اگر تحویل فقط به شکل بسته نصب باشد، روش دریافت نسخه اصلاح‌شده و امکان نگهداری توسط شخص دیگر در توافق روشن می‌شود. اطلاعات محرمانه اتصال در راهنمای عمومی یا نمونه کد قرار نمی‌گیرند.

به‌روزرسانی مرکز تلفن، نرم‌افزار متصل یا افزونه ممکن است بررسی و آزمون دوباره بخواهد. رفع ایراد بخش تحویل‌شده، سازگارسازی نسخه جدید و افزودن قابلیت تازه دامنه یکسانی ندارند؛ پوشش و هزینه نگهداری هرکدام مشخص می‌شوند.

اجرت توسعه به پیچیدگی رفتار تماس و اطلاعات موردنیاز بستگی دارد، نه فقط تعداد گوشی. یک اتصال محدود با کاری که چند نرم‌افزار، نقش کاربری و مسیر خطا دارد، حجم بررسی و ساخت یکسانی ندارد.

• تعداد قابلیت‌ها، حالت‌های عادی و خطا و سطح دسترسی کاربران.
• رابط‌ها و مستندات موجود و نیاز به همکاری فروشنده نرم‌افزار.
• نمونه آزمایشی، انتقال به سیستم فعال، داده یا زیرساخت موردنیاز.
• اقلام کد و راهنما، دامنه آزمون و نگهداری پس از تحویل.

اجرای قابلیت اصلی و افزودن امکانات بعدی می‌توانند جدا برآورد شوند. نمونه محدود کمک می‌کند سازگاری و عملکرد قابلیت جدید پیش از گسترش آن روشن شود. دامنه توسعه، افزونه‌های لازم و وابستگی به نرم‌افزار دیگر بر هزینه اثر دارند.

برای برآورد متناسب با سیستم فعلی تماس بگیرید. اجرت توسعه و پیاده‌سازی از افزونه، مجوز، سرویس جانبی یا تجهیزات جدا می‌شود. قیمت این اقلام با نوسان ارز و بازار تغییر می‌کند و با استعلام روز و مدت اعتبار مشخص در پیشنهاد می‌آید؛ هزینه دوره‌ای نگهداری نیز جدا روشن می‌شود.

عوامل هزینه راه‌اندازی ویپ اجزای عمومی سیستم تلفنی را توضیح می‌دهد؛ توسعه اختصاصی بر اساس دامنه همان سفارش برآورد می‌شود.