Один показательный случай
Робот консультировал абонента с услугой кабельного телевидения. Баланс был отрицательным, услуга отключена за неуплату, и робот предложил оформить обещанный платеж на несколько дней.
Для клиента и оператора это ошибка: обещанный платеж должен применяться к интернет-доступу, а не к договору, где фактически подключено только кабельное телевидение. Но данные биллинга показывали роботу другую картину.
Почему робот ошибся
В биллинге у части договоров с телевизионным тарифом был также указан технический модуль, который система интерпретировала как признак интернета.
Ошибка возникла потому, что данные договора формально говорили одно, а реальная бизнес-логика означала другое.
Масштаб проблемы
Проверка одного массового телевизионного тарифа показала, что неоднозначность затрагивает небольшую долю договоров, но этого достаточно для систематических ошибок робота.
| Статус среди 118 неоднозначных договоров | Количество |
|---|---|
| Активны | 70 |
| Отключены за неуплату | 39 |
| Приостановлены | 3 |
| Другой статус | 6 |
Именно эти 118 договоров создают риск: робот может принять их за интернет-договоры и предложить действие, которое для кабельного телевидения применяться не должно.
Человеку очевидно — роботу нужно правило
Оператор знает, что конкретный тариф относится к телевидению, смотрит на карточку целиком и понимает, что обещанный платеж здесь неуместен. Роботу недостаточно инструкции «посмотри, есть ли интернет». Условие должно быть формализовано.
Если тариф относится к кабельному телевидению, обещанный платеж не предлагать и не оформлять, даже если в карточке договора присутствует технический интернет-признак.
Как исправить
Такую проблему нельзя надежно решить попыткой «договориться» с нейросетью в промпте. При внедрении робота невозможно заранее предусмотреть все сочетания тарифов, технических модулей, статусов и исторических особенностей карточек.
Основное решение — привести данные в биллинге к однозначной бизнес-логике. Должен существовать достоверный признак фактически подключенной услуги, по которому телевизионный договор нельзя принять за интернет-договор.
Порядок в биллинге
Нужно устранить противоречивые признаки, определить достоверный источник типа услуги и привести классификацию договоров к единому правилу.
Проверка операции в коде
До завершения очистки данных программный guard может повторно проверять тип договора и запрещать обещанный платеж для КТВ-only.
Защитная проверка снижает риск в конкретном сценарии, но не устраняет источник проблемы. Если противоречия остаются в биллинге, они будут проявляться в других ответах и операциях робота.
Вывод
В процессе внедрения невозможно найти и описать в промптах все исторические исключения биллинга. Для каждого нового противоречия придется добавлять отдельное условие, логика робота будет усложняться, а ошибки — возникать в новых местах.
Поэтому правильный результат такого разбора — не только исправить сценарий обещанного платежа, а навести порядок в самом биллинге: однозначно определить подключенные услуги, убрать конфликтующие признаки и зафиксировать единые бизнес-правила.
Нужно устранить этот беспорядок в биллинге. Тогда и робот, и сотрудники будут опираться на одну достоверную картину договора и принимать одинаковые решения.
Обсудить подготовку биллинга к внедрению голосового робота
Оставьте контакты — обсудим, какие данные, признаки услуг и защитные проверки нужно подготовить для корректной работы робота.