Почему я сделал свою CRM

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

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

Что я хотел видеть перед собой

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

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

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

Почему я не остановился на готовом наборе

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

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

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

Одна очередь ещё не делает историю единой

В ранней версии появились работающие обращения и переписка из Авито, затем развивались другие каналы и воронка. Это дало конкретную основу для работы. При этом отдельной задачей оставалось объединение человека, который обращается через разные каналы.

Здесь и обнаруживается важное различие. Можно собрать сообщения на одном экране, но продолжать видеть одного клиента как несколько несвязанных карточек. А можно ошибочно объединить разных людей. Сама идея общей очереди не решает вопрос: откуда система знает, что это тот же человек?

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

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

Для чего здесь ИИ

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

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

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

Что проверить до покупки или разработки

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

• Где появляется обращение и кто замечает, что оно ждёт ответа?
• Как найти договорённости, если разговор продолжился в другом канале?
• Кто отвечает за следующий шаг и где это видно?
• Какое конкретное действие должен облегчить ИИ: прочитать историю, найти пробел, подготовить ответ?

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