База подтверждённых знаний о клиенте

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

База знаний о клиенте должна сохранять связь между утверждением и основанием. Это не просто архив разговоров. В ней видно, что известно, откуда известно, к каким обстоятельствам относится и когда потребуется повторная проверка.

Храните одно проверяемое утверждение в записи

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

Не усиливайте смысл при переносе. Если человек сказал, что тратит два часа, подтверждено его сообщение об оценке времени. Для утверждения о фактически измеренных двух часах нужно другое основание. Если покупатель попросил цену, подтверждён запрос, а не готовность оплатить.

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

Добавьте происхождение и границы

Для записи нужны идентификатор, формулировка, тип основания, ссылка на разрешённый источник, дата, контекст и ответственный. Укажите, относится ли знание к одному клиенту, роли внутри компании, определённой задаче или исследуемой группе.

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

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

Сделайте статус понятным

Можно использовать несколько рабочих состояний: наблюдение зафиксировано; объяснение предполагается; вывод подтверждён в указанных условиях; сведения устарели; есть противоречащие данные. Важна не красота названий, а правило перехода между ними.

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

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

Сохраняйте противоречия

Учебная ситуация: владелец мастерской говорит, что ему нужен ежедневный отчёт. Администратор использует его только перед еженедельной встречей. Это не повод выбрать удобный ответ и удалить другой. Возможно, роли решают разные задачи или желаемая частота не совпадает с реальным процессом.

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

Отчёт

Владелец говорит, что нужен ежедневный отчёт. Администратор открывает его перед еженедельной встречей. Оба свидетельства хранят до наблюдения. Удобный ответ второе свидетельство не удаляет.

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

Свяжите знания с решениями

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

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

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

Поддерживайте управляемый объём

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

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

Практическое задание

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