AI назвал неверную цену или услугу: регламент исправления без хаотичных правок

Не начинайте с переписывания страницы

Неверный ответ может возникнуть рядом с брендом по разным причинам. На сайте действительно осталась старая версия. Устаревший факт живет во внешнем профиле, архивной публикации или документе. Новая услуга еще не получила подробного объяснения на собственных страницах. Либо вопрос был сформулирован так широко, что ответ смешал несколько разных направлений. Пока команда не разделила эти ситуации, любая правка может оказаться случайной.

Поэтому первым действием должна быть фиксация того, что именно увидели. Сохраните формулировку ответа, дату, вопрос, на который он появился, и конкретный фрагмент, который считаете неверным. Это не бюрократия. Через несколько дней без такого контекста сложно вспомнить, было ли ошибкой название услуги, цена, граница работ или интерпретация вопроса. А от этого зависит весь дальнейший маршрут.

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

«В такой ситуации я начинаю не с поиска виноватого и не с массовой правки текста. Мне важно понять, что именно увидел человек, какой факт мы подтверждаем сегодня и где он должен быть объяснен. Когда эти три точки названы, задача перестает быть тревожным сообщением в чате и становится понятной работой для команды.»

Разделите наблюдение, факт и источник расхождения

В одном инциденте легко смешать три разные вещи. Наблюдение - что именно показал внешний ответ. Актуальный факт - подтвержденная версия от владельца бизнеса. Источник расхождения - место, где могла закрепиться устаревшая или неполная информация. Эти элементы нельзя подменять друг другом.

Например, человек увидел цену, которой уже нет. Наблюдение - конкретная формулировка ответа. Актуальный факт - текущая модель расчета или страница, где условия объяснены. Источник расхождения - старая карточка, опубликованный прайс, архивный материал, внешний профиль или неясный текст на собственной странице. Пока источник не найден, команда не знает, какие точки обновлять и что проверять после изменения.

Правильная задача звучит не «исправить AI», а «убрать расхождение между подтвержденным фактом и доступными источниками информации». Такая постановка не обещает мгновенного изменения внешнего ответа, но дает команде действия, на которые она действительно влияет.

Подтвердите факт у владельца, а не в общей переписке

Если ошибка касается цены, состава услуги, сроков, команды или коммерческого обещания, финальная версия должна прийти от человека, который вправе ее утверждать. Редактор, маркетолог или аккаунт-менеджер может подготовить вопрос и собрать материалы, но не должен сам выбирать между несколькими трактовками. Иначе старая версия будет заменена на новую неподтвержденную.

Для быстрого решения достаточно короткого запроса: какая формулировка является актуальной; где она должна быть подробно раскрыта; какие условия нельзя потерять при сокращении для карточки или профиля; кто подтвердит результат после обновления. Это дает исполнителям не абстрактную просьбу «сделать правильно», а границу работы.

Прежде чем менять публичные тексты, зафиксируйте одну подтвержденную версию факта и владельца, который отвечает за ее смысл.

Проверьте сначала собственные критичные точки

Когда факт подтвержден, логично начать с мест, которые компания контролирует напрямую и где человек принимает решение. Обычно это страница услуги, ее карточка, FAQ, форма обращения, коммерческий материал, актуальный профиль и ключевые экспертные статьи. Порядок зависит от типа ошибки: неверная цена требует быстрой проверки коммерческих точек, неверное описание услуги - страницы, карточек и материалов, неверная роль команды - профилей и раздела о специалистах.

Не стоит обновлять все тексты одинаково. На одной странице понадобится подробное объяснение, на другой - короткая версия и ссылка к источнику. Но смысл должен совпадать. Важно также убедиться, что новая информация не спрятана в середине длинной страницы, а встречает человека в том месте, где у него возникает вопрос.

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

Внешние источники требуют отдельного плана

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

Если внешняя площадка дает возможность отправить обратную связь или запрос на корректировку, его стоит оформлять после того, как собственные источники уже подтверждают актуальную версию. Сообщение должно быть коротким: что именно неверно, какая версия верна и где ее можно проверить. Не нужно переносить во внешний запрос внутренние споры или длинную историю изменений.

В некоторых случаях источник не обновляется быстро или остается в архиве. Тогда задача команды - не делать вид, что его нет, а убедиться, что собственные ключевые точки и актуальные профили дают человеку более точный маршрут. Координатор фиксирует внешний пункт в списке и возвращается к нему в контрольную дату.

«Я бы не обещала клиенту, что чужая площадка или внешний ответ изменится по первому обращению. Зато команда может сразу привести в порядок свои источники, подготовить точную замену и зафиксировать, кто ведет внешний запрос. Такой порядок дает управляемость вместо попытки одновременно контролировать все, что написано о компании.»

Не размножайте ошибку в новых материалах

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

Здесь помогает библиотека доказательств и реестр фактов: у каждого утверждения есть главный источник, владелец и срок проверки. При подготовке новой статьи редактор сверяет спорные данные с этим источником, а не копирует их из предыдущей публикации. В результате ошибка становится поводом улучшить процесс, а не только закрыть один эпизод.

Такой сценарий не требует драматизировать ситуацию. Он превращает ее в последовательность: обнаружить, подтвердить, обновить, проверить, предотвратить повтор.

Назначьте критерий закрытия, а не только список выполненных действий

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

Критерий закрытия помогает различить две ситуации. В первой команда выполнила все доступные действия и ведет внешний запрос отдельно. Во второй она обновила одну точку, но оставила другие критичные расхождения. Внешний ответ может меняться не по расписанию команды, но внутренний маршрут должен быть приведен к подтвержденному факту до того, как проект перейдет к следующей задаче.

Закрывайте инцидент после проверки пути клиента и обновления рабочего источника, а не после первой опубликованной правки.

Держите клиента в курсе по решениям, а не по потоку правок

Когда ошибка касается публичной информации, клиенту не нужен ежедневный перечень технических действий. Ему важно понимать четыре вещи: что именно команда считает неверным; какая версия подтверждена; какие критичные точки уже обновлены; что остается во внешнем контуре и кто ведет этот вопрос. Такой статус помогает сохранить доверие и не создает впечатления, что проблема исчезла только потому, что в задаче появился чекбокс.

Сообщение лучше строить вокруг решений, а не вокруг внутренней переписки. Вместо «мы написали в несколько сервисов и проверяем сайт» сказать: «подтвердили актуальную формулировку услуги, обновили основную страницу и коммерческий материал, подготовили запрос на изменение внешнего профиля, повторно проверим его в согласованную дату». Тогда клиент понимает границу контроля команды и видит, что его задача не потерялась между ролями.

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

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

Как не превратить регламент в лишнюю бюрократию

Для большинства ситуаций достаточно одной карточки инцидента: наблюдение, актуальный факт, владелец, источники расхождения, список действий, ответственные и контрольная дата. Не нужно создавать отдельный комитет или многоступенчатую форму. Ценность регламента не в количестве полей, а в том, что задача не теряет смысл между клиентом, аккаунт-менеджером, редактором и исполнителем.

Если похожие ошибки повторяются, это сигнал посмотреть на общий процесс. Возможно, у команды нет единого источника фактов, новые страницы выходят без проверки коммерческой границы или внешние профили не включены в регулярную сверку. Управление данными бренда помогает выстроить основу, а библиотека доказательств для GEO - хранить подтверждения, которые нужны для точных формулировок.

Спокойный регламент не делает ошибку менее важной. Он позволяет решить ее быстрее и честнее: не обещать то, на что команда не влияет, но довести до конца все действия, которые действительно возвращают человеку актуальный ответ.