Когда заявки пошли, а процессов еще не было

Это вторая статья из серии о том, как шаг за шагом строилась цифровая система INSAL (первая тут). В первой части речь шла о старте: быстрый запуск сайта, первая реклама, блог, первые сигналы рынка. Во второй — о том, что обычно скрыто от клиента. О внутренней кухне, где накапливается хаос, если внешний рост идет быстрее, чем процессы внутри.

Как на самом деле приходили и распределялись заявки

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

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

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

Почему Telegram не работает как система

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

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

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

И здесь важен уже не только вопрос удобства, но и вопрос управления. Когда мы строили этот контур, никто не думал, что Telegram в России станет зоной постоянных ограничений и регуляторных рисков. Но к 2025–2026 году стало совсем ясно: опираться на чужую платформу как на основу клиентского процесса — плохая привычка. Telegram может быть сильным каналом для охвата, общения и быстрых касаний с аудиторией. Но история клиента, логика продаж, статусы, документы и рабочий процесс должны жить на своем поле: на своем сайте, в своей системе, в своей базе. Аудиторию можно собирать где угодно. Управление отношениями с клиентом лучше держать у себя. Иначе бизнес растет не на фундаменте, а на арендованной территории.

Как Google Таблицы стали временной опорой

Следующий слой этой системы назывался Google Таблицы.

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

У многих тогда было вполне искреннее ощущение, что по-другому и нельзя. Или можно, но это сложно и дорого. Когда у бизнеса нет собственного опыта в IT, такие мысли приходят быстро. И держатся долго.

Поэтому таблицы не были ошибкой. Они были переходным решением. Тем самым костылем, на котором бизнес какое-то время действительно может идти.

Вопрос только в том, как долго.

Что таблицы реально давали

Чтобы не делать из таблиц виновника всех бед, надо сказать честно: они решали часть задач.

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

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

Это не красиво. Но это правда.

Где таблицы начали ломаться

Проблемы начались там, где закончился маленький масштаб.

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

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

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

Когда таблица начинает напоминать простыню со столбцами в духе «а это зачем здесь вообще», это уже не инструмент. Это испытание на внимательность.

Проблема была не в таблицах

Вот здесь и произошел важный поворот.

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

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

Все как будто под контролем. Но контроля нет.

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

Когда стало ясно, что пора становиться сервисной компанией

В какой-то момент стало понятно: если компания хочет быть сервисной, сервис должен жить не в словах, а в процессе.

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

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

И если внутри компании лид распределяется реакцией в Telegram, а согласование живет в перегруженной таблице, то никакой внешний «сервис» долго не продержится. Потому что рано или поздно клиент упрется в отсутствие ясности.

А отсутствие ясности в сервисе — очень дорогая штука. Оно съедает доверие быстрее, чем рекламный бюджет.

Первое осознание: автоматизировать хаос нельзя

Именно здесь случилось первое зрелое осознание.

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

Это классическая ошибка. Компания устает от ручной работы, решает: надо автоматизировать. Заказывает кабинет, CRM или сервис. А потом с удивлением обнаруживает, что проблемы остались. Только теперь они завернуты в интерфейс и выглядят чуть дороже.

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

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

Без этого любой новый инструмент был бы просто красивой витриной поверх старых проблем.

Почему первой точкой автоматизации стал именно выкуп товара

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

Такой точкой стало формирование заявки на выкуп товара с 1688, Taobao и Alibaba.

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

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

Это важный момент. Не «сразу построили экосистему». Не «сделали платформу под все». Начали с самого частого и самого неудобного сценария. Это и был здравый путь.

Сначала убрать самую понятную боль. Потом расширять систему дальше.

Что это дало на уровне мышления

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

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

Это и есть настоящий переход. Не от Telegram к кабинету. И не от таблиц к интерфейсу.

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

У INSAL этот момент наступил тогда, когда стало ясно: сайт и маркетинг уже начали тянуть компанию вперед, а внутренняя логика работы осталась на уровне «разберемся по ходу».