Кейс ЦСБ: как клиентское приложение убрало обмен из рабочего дня бухгалтера

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

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

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

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

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

Отсюда наш способ смотреть на такие проекты: предел масштабирования сервисной практики задаёт объём коммуникации вокруг работы, и эта часть автоматизируется лучше, чем сам учёт.

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

Клиентская часть видна снаружи, а эффект для команды даёт административный контур: чаты и уведомления, доступ к платежам, документам и задачам в реальном времени, единое хранение с комментариями и ответственными. Разница в одном: обсуждение привязано к документу и задаче, а не рассыпано по мессенджерам. Там, где люди уходят в отпуск посреди сезона, это не удобство, а управляемость: при передаче клиента история переезжает вместе с ним.

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

Отдельно — требования, которых не бывает у сайта: хранение финансовых данных в зашифрованном виде, работа с операциями через API с контролем транзакций, разграничение доступа между клиентом, его сотрудниками и командой ЦСБ. Биометрический вход — следствие этих требований, а не их суть: сам он подключается быстро, а недели уходят на то, чтобы описать, кто какие объекты видит и что происходит с доступом, когда у клиента меняется бухгалтер. Автоматическая синхронизация с бухгалтерскими системами снимает ручной перенос данных и сверку. Распространяется приложение через App Store и Google Play как корпоративный продукт, по закрытой ссылке: заказчик сам управляет подключениями и добавляет клиентов по мере необходимости.

В кейсе ЦСБ измеренного эффекта нет, а вопрос «на сколько быстрее стало» вы зададите. Честный ответ — показать проект, где замер был, и оговорить его границы. Медицинская группа EMC принимала заявки от агентов через почту, звонки и мессенджеры. Единой системы не было: заявки задерживались, информация терялась или дублировалась.

Сервис собрали из двух модулей: для агентов — заявка по стандартизированной форме с документами и статусом в реальном времени; для сотрудников клиники — автоматическое распределение задач с учётом загрузки и экспертизы, уведомления и напоминания по срокам. Внутри статусы «Новая», «В работе», «Требуется дополнительная информация», «Завершена», встроенный чат и разграничение прав. После запуска время от поступления запроса до предоставления медицинского заключения сократилось на 60%, а сотрудники отметили снижение рутинной нагрузки.

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

Будем честны, вы всё равно спросите это на встрече. В опубликованном кейсе ЦСБ нет показателя вида «клиентов на одного специалиста выросло на столько-то», нет замера сэкономленных часов и нет порога, начиная с которого кабинет окупает себя. Подставлять туда красивое число ради статьи мы не станем: нужна цифра для внутреннего обоснования — запросите отдельно, мы либо дадим её с согласия клиента, либо скажем, что замера не было.

Ещё две оговорки. Прямой речи собственника ЦСБ в кейсе нет: формулировка задачи и мотив «начал с клиентского сервиса» — наш пересказ, а не его цитата; цитату мы запросим у клиента. И у нас нет публичного порога вида «при таком-то фонде времени кабинет имеет смысл» — мы считаем его на ваших цифрах и не выдаём за отраслевую норму.

Что известно точно — механика: какие шаги ушли из процесса. Ушла ручная сверка и перенос данных между системами. Ушли устные напоминания о сроках — они стали лентой задач на экране клиента. Ушёл поиск документа в переписке и вопрос «какой у меня остаток»: клиент видит его сам.

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

Арифметика простая: строка 2, умноженная на число специалистов, — фонд времени, который уходит на обмен. Строка 3 показывает, какая его часть поддаётся переносу: вопросы про остаток, платёж и документ переносятся, разбор нестандартной ситуации — нет. Цель проекта стоит формулировать в этих единицах — освобождённые часы и клиенты на человека, — а не в «удобстве клиента»: удобство нельзя защитить перед операционным директором.

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

Объём честнее измерять в месяцах работы и числе потоков обмена, а не в экранах. Приложение ЦСБ со всей начинкой — клиентская часть, админконтур, интеграции, публикация в двух сторах — заняло двенадцать месяцев. Кабинет агента EMC, где контур у́же, — девять месяцев. Это сроки проекта целиком; как внутри них шли промежуточные релизы, мы не публикуем и подставлять красивое «первая версия через три месяца» не станем.

Вопросы собраны под бухгалтерскую специфику. По ответам видно, работал человек с учётным контуром или впервые про него слышит.

Что увидит клиент, если выгрузка пришла с расхождением или не пришла вовсе — цифру прошлого дня, пустой экран или честную пометку? Из каких источников берётся каждый блок данных — остатки, статусы платежей, документы, сроки отчётности — и какой у каждого период обновления? Есть ли тестовый контур, на котором можно гонять выгрузку, не трогая боевой учёт? Как кабинет ведёт себя в пик, когда в один день заходят все клиенты? Можно ли вести подключение волнами и остановить его на середине? Где лежат персональные и финансовые данные и кто из сотрудников подрядчика имеет к ним доступ? Что остаётся у вас при расставании — код, учётные записи в сторах, сертификаты подписи, документация по обмену?

Последний пункт проверяйте до подписания. Если учётная запись в сторе и сертификаты остаются у подрядчика, вы не выпустите обновление в сезон без его участия — а понадобится оно именно в сезон.

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