Как первый кабинет INSAL начал заменять Google Таблицы (4 серия)
Первая версия CRM-INSAL не была большой платформой на все случаи жизни. Она решала одну очень земную задачу: убрать ручной хаос из самого частого клиентского сценария — заявки на выкуп товара. Именно с этого началась первая рабочая система, которая стала реальной заменой Google Таблицам, чатам и бесконечным уточнениям по кускам.
Это четвертая статья из серии о том, как шаг за шагом строилась цифровая система INSAL. В первой части был быстрый выход на рынок. Во второй — хаос после первых заявок. В третьей — разбор маршрута заявки, ролей и логики. Теперь — первый кабинет клиента. Не как красивая обложка, а как рабочий инструмент, который начал собирать процесс в одной системе.
Почему начали именно с заявки на выкуп
После разбора бизнес-процесса стало ясно: автоматизировать все сразу бессмысленно. Нужно было выбрать самый частый, самый неудобный и самый ручной сценарий.
Таким сценарием стала заявка на выкуп товара с китайских маркетплейсов.
Именно здесь было больше всего переписки, уточнений, ручных правок, потерь данных и лишних кругов между клиентом, менеджером и таблицей. Клиент присылал информацию кусками. Менеджер дособирал ее вручную. Что-то оставалось в Telegram, что-то — в почте, что-то — в Google Таблице. Итог был знакомый: работа вроде идет, но никто не может быстро показать целостную картину.
Поэтому первой точкой автоматизации стал не весь бизнес, а один конкретный процесс. Это было здравое решение. Не строить космолет, когда сначала надо просто перестать терять гайки.
Что было до кабинета
До кабинета рабочая схема держалась на двух вещах: привычке и терпении.
Заявки приходили с сайта, попадали в Telegram и на почту, дальше шли ручные согласования. Сами заявки на выкуп и часть работы по фулфилменту жили в Google Таблицах. Менеджеры вручную собирали параметры товара, уточняли детали, пересылали сообщения, правили строки, возвращались к клиенту за недостающими данными.
Это работало, пока объем был терпимым.
Но у такой схемы было сразу несколько слабых мест. Данные жили в разных местах. Клиент не видел прозрачного статуса. Менеджер часто становился живым переводчиком между таблицей, чатом и реальностью. Руководитель не получал внятной картины без ручного погружения в детали.
Google Таблицы не были злом. Они были временной опорой. Но как только процесс стал повторяемым и массовым, стало ясно: дальше нужна не просто удобная форма, а нормальный клиентский контур.
Что вошло в первую версию кабинета
Первая версия кабинета не пыталась закрыть весь мир. Она собирала вокруг клиента и его заявки тот минимум, без которого уже нельзя было работать нормально.
Внутри появились регистрация, настройки профиля, личные данные, адреса доставки, создание заявки, режим черновика, отправка на согласование менеджеру, переход заявки в заказ после согласования, статусная логика, фото-подтверждение со склада, история заказов, общие показатели по заказам, уведомления, актуальные тарифы и услуги, новости компании и база знаний.
Позже появились повтор и копирование заказа в один клик, выгрузка в CSV и сценарий создания новой заявки через загрузку CSV. Но в первой версии этого еще не было.
То есть кабинет с самого начала собирался не как одна форма “отправить заявку”, а как рабочая среда клиента.
Как выглядел сценарий клиента
Логика для клиента была простой и понятной.
Сначала регистрация. Потом заполнение профиля: личные данные, контактная информация, адреса доставки. Это убирало необходимость заново передавать базовую информацию в каждом новом диалоге.
После этого клиент мог создать заявку на выкуп товара. Причем не обязательно отправлять ее сразу. Появился режим черновика. Клиент мог спокойно собрать заявку, проверить данные, вернуться к ней позже и только потом отправить на согласование менеджеру.
Это кажется мелочью, но именно на таких вещах и начинается нормальный сервис. Сырая заявка — это почти всегда лишний круг переписки, лишние уточнения и потеря времени для обеих сторон.
После отправки на согласование клиент уже не жил в режиме «я что-то отправил в чат и теперь жду». Появился более понятный сценарий: заявка, согласование, переход в заказ, статус, история.
А это уже другой уровень спокойствия.
Что менялось для менеджера
Для менеджера кабинет был не менее полезен, чем для клиента.
До этого заявка собиралась по кускам. Где-то ссылка, где-то комментарий, где-то уточнение по цвету или размеру, где-то отдельное сообщение про упаковку. Менеджеру приходилось не вести процесс, а сначала восстанавливать его из фрагментов.
После появления кабинета менеджер получал не россыпь сообщений, а структурированную заявку. С понятными полями. С логикой. С понятной отправной точкой.
Это не делало работу магически простой. Но убирало массу ручного шума.
Появился и важный сценарий для VIP-клиентов. Если клиенту было удобнее не собирать заявку самому, менеджер мог выполнять большую часть действий сам, а клиент — только контролировать процесс. Это было правильное решение. Реальный сервис не заставляет всех клиентов работать одинаково. Он подстраивается под зрелость, привычки и формат работы конкретного клиента.
Почему черновик и совместная работа были важнее, чем кажется
Одна из самых полезных вещей в первой версии кабинета — это не “цифровой интерфейс”, а логика совместной работы.
Клиент мог собрать заявку как черновик. Менеджер — доработать ее, внести изменения и уточнения. Клиент видел, что именно поменялось. То есть согласование постепенно уходило из режима «переслали друг другу что-то в чат» в режим «работаем с одним объектом».
Это важный сдвиг.
Пока клиент и менеджер живут в разных каналах и разных версиях реальности, сервис всегда буксует. Как только они начинают работать внутри одного сценария, процесс становится прозрачнее и для клиента, и для команды.
На практике это означало меньше путаницы, меньше уточнений по кругу и меньше зависимости от того, кто именно сегодня ведет заявку руками.
Когда заявка превращалась в заказ
Еще одна важная вещь — кабинет не обрывался на этапе «отправить заявку».
После согласования заявка переходила в заказ. Это уже была не просто форма для сбора данных, а начало полноценного рабочего маршрута.
Дальше включались статусы. Менялся этап работы. Клиент получал уведомления о смене статуса. Появлялись фото-подтверждения со склада. После завершения заказ уходил в историю.
Вот здесь кабинет впервые начал работать не как цифровая замена таблицы, а как реальный клиентский сервис. Потому что у клиента появлялся не только вход в процесс, но и наблюдение за процессом.
А для бизнеса это означало простую вещь: процесс переставал быть одноразовым. Он становился повторяемым.
Что дашборд давал на практике
На дашборде клиент видел рабочий контекст в одной точке: общую сумму заказов, количество товаров, что выполнено, что в работе, персонального менеджера, инструкцию по оформлению заказа, услуги, уведомления и новости компании.
Это снижало количество лишних вопросов. Не потому, что клиенту внезапно “все и так понятно”, а потому что система начинала объяснять себя сама.
Хороший интерфейс не тот, где все красиво. Хороший интерфейс тот, где человеку реже нужно спрашивать: «А что теперь делать?»
Почему внутренний курс валют был важной деталью
Одна из сильных функций первой версии — внутренний курс и автоматические расчеты по юаням.
Для такого бизнеса это не украшение. Это рабочий инструмент доверия.
Когда расчеты по юаням привязаны к актуальному внутреннему курсу, а логика пересчета прозрачна и проверяема, уходит часть ручных пересчетов, споров и недоверия. Клиент видит, на чем строится сумма. Команда не пересчитывает одно и то же вручную в десяти местах. Процесс становится спокойнее.
Иногда именно такие функции и делают систему взрослой. Не большие слова про digital, а банальная возможность быстро проверить расчет и не устраивать арифметический театр в переписке.
Почему база знаний появилась сразу
Один из самых зрелых элементов первой версии — база знаний.
Ее сделали сразу и подробно, со скринами. Не “на потом”, не после релиза и не когда-нибудь, если останется время. Сразу. Логика была простой: если появляется новая система, ей нужен нормальный вход и для клиента, и для менеджера.
На бумаге решение выглядело правильно. В реальности все оказалось сложнее.
Как выяснилось позже, и клиенты, и часть менеджеров базу знаний в основном игнорировали. Это нормальная жизнь, а не провал идеи. Большинство людей не хочет читать инструкцию, пока не упрется в проблему. Поэтому одной базы знаний оказалось мало. Пришлось отдельно учить менеджеров, объяснять, зачем вообще нужен этот слой, и приучать команду не держать все в голове и переписке.
Это был важный урок. База знаний сама по себе не работает только потому, что она существует. Ее нужно встраивать в повседневный процесс. Иначе она превращается в аккуратный раздел полезного контента, мимо которого все вежливо проходят.
Что первая версия не решала полностью
Первая версия кабинета не была финальной платформой. И не пыталась ею казаться.
Она решала одну главную задачу: собрать первый рабочий клиентский сценарий в системе и вытащить его из ручного хаоса. Но внутри этой версии все еще оставалось немало шероховатостей.
Например, создание каждой новой заявки начиналось с нуля. Быстрого копирования в один клик тогда еще не было. Его добавили позже. Возможность выгружать заказ в CSV тоже появилась не сразу, как и сценарий создания новой заявки через загрузку CSV. В карточке товара на старте можно было загрузить только одну фотографию. Для реальной работы это уже было ограничением.
Уведомления тоже сначала жили только внутри кабинета. Это работало, но не всегда было достаточно удобно для клиента. Позже появились уведомления через Telegram-бота, потому что люди все равно хотели получать быстрый сигнал там, где уже привыкли быть внимательными.
То есть первая версия была не “идеальной системой”, а первой нормальной рабочей средой. С ограничениями. С доработками по ходу. С вещами, которые стали видны только после живого использования. И в этом как раз ее нормальность. Хорошие продукты почти никогда не рождаются сразу отполированными. Сначала они начинают работать. Потом — начинают взрослеть.
Вывод
Первый кабинет INSAL не был большим продуктом на все случаи жизни. Но именно он стал первой настоящей заменой ручной схемы, где заявки жили в чатах, почте и Google Таблицах.
Он собрал базовый клиентский маршрут в одной системе: регистрация, профиль, адреса, черновик заявки, согласование, переход в заказ, статусы, фото, история, расчеты, уведомления и база знаний.
Для клиента это означало больше прозрачности и меньше зависимости от ручной переписки. Для менеджера — меньше сбора информации по кускам. Для бизнеса — первый реальный фундамент, на котором уже можно было строить дальше.
И это, пожалуй, главное. Первая версия была важна не тем, сколько функций в ней было. Она была важна тем, что впервые собрала клиента, менеджера и процесс в одной логике.
В следующей статье — о том, как внутри кабинета заявка начала жить как заказ, почему понадобилась статусная модель и как прозрачность процесса стала частью сервиса.
