На зимнем CX Camp 2024 проводил мастер‑класс «IT для CX».
Ключевая формулировка здесь такая: цифровой клиентский опыт нельзя полностью «отдать в IT». Но и CX‑директору не нужно пытаться стать вторым CIO.
Что тогда нужно? Уметь проектировать требования к системе через клиентский и бизнес‑результат.
Обычная ошибка выглядит так: компания составляет длинный список платформ — CRM, CDP, контакт‑центр, helpdesk, KMS, LMS, WFM, QA, BI, чат‑боты, GenAI — и называет это архитектурой. На самом деле это перечень закупок. Архитектура начинается со связей.
Я предлагаю идти в другом порядке:
Определить клиентскую задачу и путь.
Описать процесс и точки принятия решений.
Понять, какие данные нужны в каждой точке.
Найти системы, где эти данные создаются и хранятся.
Зафиксировать разрывы: нет данных, плохое качество, нет интеграции, знание устарело, действие невозможно выполнить.
Только после этого выбирать изменение и технологию.
Например, Клиент повторно обращается по статусу заказа. Можно купить нового бота. А можно сначала обнаружить, что статус в ERP обновляется с задержкой, CRM его не получает, а база знаний предлагает сотруднику уточнять информацию вручную. В этом случае разговорный интерфейс — последняя часть решения, а не первая.
У CX‑руководителя есть важная роль переводчика. Он переводит проблему Клиента на язык процесса и данных, а техническое ограничение — на язык влияния на опыт и экономику. С CIO и IT он должен обсуждать не «хотелки», а сценарии, SLA, контекст, интеграции, безопасность и критерии результата.
ИИ делает эту дисциплину ещё важнее. Модели нужен контекст: достоверные знания, история взаимодействия, правила и права на действие. Если такого контура нет, магии не произойдёт.
Короче, не рисуйте идеальный стек. Соберите карту текущей экосистемы, выберите один важный путь и спроектируйте следующий управляемый шаг.