Нейминг B2B-продукта с первого дня должен иметь одного ответственного

Когда слова перестают совпадать с продуктом

B2B-команды часто называют одно и то же по-разному и не замечают этого, пока на несоответствие не указывает клиент. Продажи говорят «клиент», поддержка — «аккаунт», а инженерная команда — «тенант». Внутри компании это может казаться безобидным. Для покупателя это выглядит как неаккуратность.

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

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

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

Типичный пример выглядит так:

• Продажи закрывают «клиента»
• Онбординг создаёт «компанию»
• Приложение создаёт «аккаунт»
• Биллинг продлевает «подписку»

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

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

Что должно называться одинаково

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

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

Например, аккаунт — это компания, которая платит за продукт. Рабочее пространство — это место, где эта компания работает. Пользователь — это один человек, который может войти в систему. Админ — это пользователь, который может менять настройки и управлять людьми. Триал — это ограниченный период до старта платного тарифа.

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

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

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

Рабочее правило простое: у каждого термина должно быть одно название, одно определение и одно место, где команда может проверить его перед выпуском.

Дайте одному человеку последнее слово

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

У одного человека должно быть последнее слово по продуктовым терминам и определениям. В небольшой компании это часто основатель, руководитель продукта или CTO. В более крупной команде эта ответственность может лежать на product operations. Название роли не так важно, как правило: один человек решает, оставить ли название, изменить его или отклонить.

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

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

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

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

Постройте карту терминов на основе того, что уже есть

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

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

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

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

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

Командам, которые используют ИИ для написания кода и документации, такая дисциплина нужна ещё сильнее. Хаотичный термин быстро расползается в промпты, сгенерированные тесты, названия API и release notes. Ранний порядок в нейминге экономит переделки позже и снижает число багов, которые начинаются с простого несовпадения слов.

Откуда начинается дрейф названий

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

Одна из частых причин — страницы с ценами. Маркетинг хочет, чтобы названия тарифов звучали ярко, поэтому простое слово вроде «team» на разных страницах превращается в «workspace», «studio» или «business hub». Это может помочь заголовку, но одновременно учит покупателей слову, которого в самом продукте может никогда не быть.

Сценарии демо дрейфуют ещё проще: продажи на ходу сокращают язык. Если продукт называет что-то «customer account», в демо это превращается в «client», потом в «company», а на следующем звонке уже в «org». Никто не планирует создавать путаницу. Так выходит потому, что повседневная речь движется быстрее, чем управление продуктом.

В кодовой базе старые названия часто живут дольше, чем изменения в интерфейсе. Команда продукта переименовывает «tenant» в «workspace» в UI, а API всё ещё возвращает tenant_id, и база данных по-прежнему хранит tenant_status. Инженеры знают обе версии. Все остальные вынуждены угадывать.

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

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

Как только это происходит, нейминг перестаёт быть вопросом стиля. Он превращается в ошибки настройки, неправильные права доступа и длинные письма, где каждый уверен, что говорит об одном и том же.

Как названия превращаются в баги

Обычно нейминг ломается задолго до появления сообщения об ошибке. Всё начинается в тот момент, когда продажи называют объект аккаунтом, поддержка — рабочим пространством, а продуктовая команда — организацией. Люди думают, что говорят об одном и том же. Это не так.

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

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

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

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

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

Представьте простой пример жизненного цикла. На одном экране написано «trial». В биллинге — «pilot». В договоре — «evaluation period». В CRM — «lead». Это не безобидные синонимы. Они заставляют людей гадать, описывают ли слова один этап или четыре разных.

Решение простое и немного жёсткое. Выберите один термин, определите его один раз и удалите лишнее. Если слово меняется в приложении, обновляйте документы, договоры и скриншоты в том же релизе.

Проверяйте названия до выпуска

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

Короткая проверка терминов перед выпуском помогает поймать удивительно много хаоса. Для этого не нужен марафон встреч.

• Попросите одного человека из продаж, одного из поддержки и одного из инженерной команды определить каждый основной термин в одном предложении. Если ответы различаются, исправьте термин до выпуска.
• Проследите один объект через продукт, документы, демо и счёт. Если по пути одно и то же меняет названия, выберите одно и придерживайтесь его.
• Прочитайте каждое название роли глазами нового клиента. «Админ» и «менеджер» могут звучать похоже, хотя означают совсем разные права.
• Дайте одному человеку финальную проверку release notes, сценарию демо и договору. Отдельные проверки не замечают расхождения между командами.

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

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

Что делать дальше

Начните с малого. Выберите десять слов, которые чаще всего путают клиентов, а не пятьдесят терминов, о которых команда спорит на встречах. Хорошие места для поиска — заметки продаж, вопросы на онбординге, тикеты поддержки, счета и экраны, где пользователи колеблются перед нажатием.

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

Сначала исправляйте поверхности, которые видит клиент. Обновите названия в продукте. Синхронизируйте сценарий демо. Потом перепишите документацию и тексты онбординга. Затем наведите порядок в договорах, формах заказа и языке биллинга. Такой порядок делает работу управляемой и уменьшает путаницу там, где клиент чувствует её первым делом.

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

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

Если проблема уже затронула продукт, продажи, договоры и код, внешний Fractional CTO часто разберёт всё быстрее, чем комитет. Oleg Sotnikov на oleg.is работает именно с такой кросс-функциональной уборкой в продукте и системах, а именно этим дрейф названий обычно и оказывается, когда он уже разросся.