Как поддерживать и обновлять сценарии бота со временем

Почему устаревшая цена хуже, чем её отсутствие

Если бот честно не знает цену и говорит «уточню у менеджера» — клиент понимает, что информации пока нет, и либо ждёт, либо пишет ещё раз. Это неудобно, но не вредно. Если бот уверенно называет цену, которая была верна полгода назад, — клиент действует на основе неверных данных: планирует бюджет, приходит с ожиданием конкретной суммы, записывается на услугу, которой больше нет в прежнем виде. Конфликт в этом случае случается не в переписке с ботом, а позже, лицом к лицу — и выглядит уже не как «бот чего-то не знал», а как «нас обманули». Разница между пробелом и враньём, даже непреднамеренным, для клиента ощущается совершенно по-разному.

Что на самом деле запускает обновление

Ждать «планового пересмотра раз в год» — плохая стратегия, потому что бизнес меняется не по календарю. Практичнее привязать обновление описания к конкретным событиям, которые и так происходят в бизнесе:

• Изменилась цена любой позиции, которую бот называет клиентам напрямую.
• Появилась новая услуга или товар, а старая — снята с продажи или изменилась по составу.
• Сдвинулся график работы: сезонные часы, временное закрытие, новый выходной день.
• Стартовала или закончилась акция, которую бот упоминает как актуальную.
• Изменилась политика возврата, отмены записи или любое другое правило, о котором бот сообщает как о действующем.

Если что-то из этого списка случилось — обновление описания должно происходить в тот же день, а не при следующей случайной проверке бота.

Кто должен за это отвечать

Логичнее всего закрепить обновление описания за тем же человеком, который и так решает вопросы цен, услуг и графика — а не отдавать это отдельному «техническому» сотруднику, который узнаёт об изменениях последним. Если решение об изменении цены принял владелец, обновление описания бота должно идти тем же действием, а не отдельной задачей, которая забывается через неделю после того, как изменение вступило в силу.

CRM-переписка как сигнал, что описание устарело

У бота, подключённого хотя бы к одному реально работающему каналу, есть вкладка CRM с полной историей переписки. Это не только инструмент для перехвата диалога оператором — это ещё и единственный доступный сегодня способ заметить, что описание разошлось с реальностью. Если бот раз за разом спотыкается на вопросе, на который раньше отвечал без проблем, — это не случайный сбой, а сигнал: что-то в бизнесе изменилось, а в описании это изменение не отражено. Стоит периодически просматривать переписку не только в поисках жалоб, но и в поисках таких повторяющихся заминок — они обычно указывают точнее, чем любая внутренняя догадка о том, что пора обновить.

Как выглядит одно такое обновление на практике

Стрижка подорожала с 1200 до 1500 рублей с первого числа. Если это изменение внести в описание бота в тот же день — правка занимает буквально одну строку: «стрижка — 1500 рублей» вместо старой цифры. Если отложить на потом, бот две недели называет клиентам сумму, которую администратору потом придётся объяснять на месте — либо доплата, либо неловкое «извините, цена уже другая». Само обновление тривиально; цена задержки — нет.

Итог

Сценарий бота — не то, что настраивают один раз при запуске, а то, что требует такого же регулярного внимания, как прайс-лист или расписание на сайте. Устаревший ответ бота вредит больше, чем отсутствующий, потому что звучит одинаково уверенно в обоих случаях, и клиент не может отличить актуальную информацию от забытой на полгода. Привязать обновление к реальным событиям бизнеса и время от времени просматривать переписку в CRM — дешевле, чем разбираться с недовольным клиентом, который пришёл на условия, которых уже нет.