Дякую!
Форма успішно надіслана
Форма успішно надіслана
На жаль! Щось пішло не так, будь ласка, спробуйте ще раз

Якщо подивитися на дзвінки в розрізі дня, видно, що однаковий трафік дає різний результат. Вчора 60% з’єднань, сьогодні 48%. При цьому команда не змінювалась, скрипти ті самі.
Такі коливання зазвичай не пов’язані з продажами. Вони з’являються на етапі, який не видно в звітах – як саме виклик проходить до абонента.
Частина дзвінків довше встановлюється, частина не доходить, частина потрапляє в менш стабільні маршрути. У статистиці це виглядає як звичайні виклики, але по факту це різна якість контакту.
При обсязі кількох сотень дзвінків на день навіть невелика різниця в цих процесах дає відчутний розрив у результаті.
SIP trunk відповідає саме за цей етап. Він визначає, як обробляється голосовий трафік, як розподіляються дзвінки і чи доходять вони до відповіді при реальному навантаженні.
Без контролю цього рівня частина викликів втрачається, навіть якщо команда і трафік залишаються незмінними.

SIP trunk підключає телефонію компанії до зовнішніх мереж через IP. Кожен дзвінок проходить не напряму до абонента, а через кілька рівнів обробки.
Типовий шлях виглядає так: A-number → транзитні маршрути → точка термінації → внутрішня система.
На кожному з цих етапів формується результат:
Саме тут виникають втрати, які не видно в CRM, але впливають на ASR і конверсію.
У традиційній телефонії кількість одночасних дзвінків обмежена лініями. Якщо навантаження перевищує цей ліміт, частина викликів не доходить до обробки або потрапляє в чергу.
SIP trunk знімає це обмеження. Кількість каналів змінюється під поточний обсяг без заміни обладнання або перебудови системи.
При навантаженні 200–300 одночасних дзвінків це критично. Без масштабування частина трафіку губиться ще до контакту, навіть якщо оператори доступні. З SIP trunk система розподіляє виклики і обробляє їх у потоці без накопичення.

Основна різниця формується на міжнародних дзвінках. Передача голосу через IP дозволяє обходити класичні тарифи операторів.
У залежності від напрямку економія становить 30–60%. При обсязі кількох тисяч хвилин на місяць це відчутно впливає на витрати.
Окрім цього, витрати стають прозорими. Є зрозуміла вартість по кожному напрямку і прогноз при збільшенні трафіку. Це дозволяє планувати бюджет, а не реагувати на рахунки постфактум.
Якість дзвінків визначається тим, як проходить виклик, а не тільки інтернетом.
Є кілька показників, які дають реальну картину:
SIP trunk дозволяє керувати цими параметрами через маршрутизацію. Трафік розподіляється між напрямками, а система вибирає більш стабільні маршрути.
У проєктах DID Global це дає приріст ASR на 10–15%, що при 500 дзвінках на день означає десятки додаткових контактів без змін у трафіку.
Ключовий елемент — failover. Якщо один маршрут дає збій або перевантажений, трафік автоматично переходить на інший. Без цього частина викликів втрачається саме в пікові періоди.
SIP trunk підключається до CRM, dialer і аналітики без додаткових рішень.
Усі дзвінки фіксуються автоматично. Дані передаються в систему без ручного введення. Розподіл викликів будується за заданою логікою.
Це дає контроль над процесом: видно, хто обробляє дзвінки, скільки часу займає контакт, де виникають затримки.
Телефонія перестає бути окремим каналом і вбудовується в роботу команди.
SIP trunk дає доступ до міжнародних напрямків без фізичної присутності.
Можна підключати локальні номери в різних країнах, запускати inbound і outbound дзвінки і тестувати нові GEO без затримок.
Для компаній, які працюють з кількома ринками, це скорочує час запуску з днів або тижнів до годин.
У результаті нові напрямки можна перевіряти швидко, без вкладень в окрему інфраструктуру.

У одному з проєктів DID Global клієнт працював з outbound-трафіком у Європі з обсягом близько 600 дзвінків на день. При такому навантаженні ASR тримався на рівні 50–52%, що означало, що майже кожен другий виклик не переходив у розмову.
У звітах це виглядало як нестабільна конверсія, але аналіз показав іншу картину. Частина трафіку йшла через перевантажені маршрути, PDD перевищував 4–5 секунд, а відсутність резервних каналів не дозволяла системі компенсувати ці просідання. У пікові години це давало додаткові втрати до 10–15% від загального обсягу дзвінків.
Після перебудови routing і підключення failover схема обробки змінилася. Трафік почали розподіляти між кількома маршрутами, а при перевантаженні одного з них система автоматично переключалася на альтернативний.
У результаті ASR виріс до 64–67%. При тому самому обсязі це дало додатково 80–100 з’єднань на день. PDD скоротився до стабільного рівня близько 2–3 секунд, що напряму вплинуло на кількість успішних контактів.
При середній конверсії в угоду 5–7% ці додаткові з’єднання означають 4–7 угод щодня без змін у трафіку, команді або скриптах.
У цьому кейсі результат сформувався не за рахунок збільшення обсягу дзвінків, а за рахунок того, що більша їх частина почала доходити до розмови.
Якщо при зростанні навантаження частина дзвінків не доходить до розмови, проблема знаходиться на рівні routing.
DID Global може показати, який відсоток викликів втрачається і на якому етапі це відбувається.
Підключення займає від кількох годин до одного дня.
Ключовий етап – тестування під навантаженням. Саме воно показує, як система поводиться при реальному обсязі дзвінків.
Без цього неможливо оцінити якість routing.

Якщо показники по дзвінках нестабільні, почніть із інфраструктури.
Залиште запит – перевіримо routing, latency і ASR у вашій системі і покажемо, де втрачаються контакти.