portfolio cases

10 кейсов в формате "как было / как стало"

Это понятные портфолио-кейсы о том, как хаотичные и ручные процессы превращаются в спокойные, управляемые цифровые маршруты.

Автоматизация записи клиентов

Как было

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

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

Как стало

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

После проверки расписания клиент подтверждает конкретный слот, получает фиксацию записи и напоминание. Если ответа на напоминание нет, запускается повторный контакт, а если речь о переносе, отмене или сложной коммуникации, администратор отдельно утверждает решение. В результате меньше пустых окон, меньше потерянных заявок и выше доходимость до визита.

Схема

flowchart LR A1[Сайт] --> B[Единая точка приема] A2[Instagram] --> B A3[Мессенджеры] --> B B --> C[Уточнение услуги] B --> D[Уточнение филиала] B --> E[Сбор пожеланий по времени] C --> F{Сценарий типовой?} D --> G[Проверка расписания] E --> G F -->|Да| G F -->|Нет| H[Администратор получает контекст] G --> I{Слот подтвержден клиентом?} I -->|Да| J[Подтверждение записи] I -->|Нет| K[Повторный подбор окна] H --> L[Перенос, отмена или сложный диалог] L --> M["APPROVAL
Администратор подтверждает решение"] J --> N[Напоминание перед визитом] M --> N N --> O{Клиент ответил на напоминание?} O -->|Да| P[Визит закреплен] O -->|Нет| Q[Администратор перезапускает контакт]

Автоматизация заявок на выездные услуги

Как было

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

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

Как стало

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

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

Схема

flowchart LR A1[Звонок] --> B[Цифровая приемка] A2[Форма на сайте] --> B A3[Сообщение в мессенджере] --> B B --> C[Тип проблемы] B --> D[Адрес и зона] B --> E[Срочность] C --> F[Матрица специализаций] D --> G[Карта мастеров] E --> H[Приоритет заявки] F --> I{Есть подходящий мастер?} G --> I H --> I I -->|Да| J[Оптимальное назначение] I -->|Нет| K[Менеджер собирает ручное решение] J --> L{Клиент подтверждает выезд?} L -->|Да| M[Готовая карточка заявки] L -->|Нет| N[Переназначение времени] K --> O["APPROVAL
Менеджер утверждает исполнителя"] O --> M M --> P{Нужен допуск на объект?} P -->|Да| Q[Отдельное согласование доступа] P -->|Нет| R[Бригада едет по маршруту]

Автоматизация коммерческих предложений

Как было

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

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

Как стало

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

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

Схема

flowchart LR A1[Заявка клиента] --> B[Структурирование параметров] A2[Прайс-листы] --> C[Расчетный блок] A3[Правила скидок] --> D[Проверка ограничений] A4[Шаблоны КП] --> G[Сборка КП в шаблон] B --> C B --> D C --> E[Авторасчет стоимости] D --> F{Маржа в норме?} E --> F F -->|Да| G[Сборка КП в шаблон] F -->|Нет| H[Менеджер проверяет вручную] G --> I{Нужен special offer?} I -->|Нет| J[Черновик письма] I -->|Да| K[Добавление ручных условий] H --> L["APPROVAL
Менеджер подтверждает условия"] K --> L J --> M[Отправка клиенту] L --> N[Финальный контроль формулировок] N --> O[Отправка клиенту] O --> P{Клиент просит правки?} P -->|Да| Q[Менеджер пересобирает КП] P -->|Нет| R[КП зафиксировано в работе]

Автоматизация первой линии поддержки

Как было

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

Основные силы специалистов уходили на бесконечный поток однотипных обращений вместо решения сложных случаев.

Как стало

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

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

Схема

flowchart LR A1[Чат] --> B[Определение темы] A2[Почта] --> B A3[Форма поддержки] --> B A4[Телефон] --> B B --> C[Данные клиента] B --> D[Данные заказа] B --> E[Приоритет] C --> F[Поиск в базе знаний] D --> F E --> G{Кейс типовой?} F --> G G -->|Да| H[Готовый ответ] G -->|Нет| I[Черновик и найденные статьи] I --> J[Передача специалисту] H --> K{Нужна эскалация?} K -->|Нет| L[Клиент получает решение] K -->|Да| M[Передача на 2 линию] J --> N[Сбор дополнительного контекста] M --> N N --> O["APPROVAL
Специалист утверждает финальный ответ"] O --> P[Человек видит весь контекст] O --> Q[Клиент получает итоговый ответ] Q --> R{Проблема решена?} R -->|Да| S[Тикет закрыт] R -->|Нет| T[Запускается повторная диагностика]

Автоматизация обработки счетов и документов

Как было

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

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

Как стало

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

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

Схема

flowchart LR A1[Почта] --> B[Определение типа] A2[Переписки] --> B A3[Файловые папки] --> B A4[EDI поток] --> B B --> C[Извлечение реквизитов] B --> D[Определение маршрута] C --> E[Связка с заказом] C --> F[Связка с договором] D --> G{Совпадения найдены?} E --> G F --> G G -->|Да| H[Автосогласование по маршруту] G -->|Нет| I[Человеку уходит расхождение] H --> J{Нужна финальная подпись?} J -->|Нет| K[Статус и история обновлены] J -->|Да| L["APPROVAL
Ответственный подтверждает документ"] I --> M[Ручная корректировка данных] M --> L L --> N[Архив и журнал изменений] N --> O[Статус и история обновлены] O --> P{Нужен возврат на доработку?} P -->|Да| Q[Документ возвращается инициатору] P -->|Нет| R[Документ уходит дальше по циклу]

Автоматизация обращений арендаторов

Как было

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

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

Как стало

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

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

Схема

flowchart LR A1[Почта] --> B[Классификация обращения] A2[Мессенджер] --> B A3[Звонок] --> B A4[Личное сообщение сотруднику] --> B B --> C[Тип проблемы] B --> D[Приоритет SLA] B --> E[Объект и арендатор] C --> F[Назначение исполнителя] D --> G[Контроль срока] E --> F F --> H{Есть реакция?} G --> H H -->|Да| I[Обновление статуса] H -->|Нет| J[Напоминание подрядчику] J --> K[Эскалация управляющему] I --> L{Нужно подтверждение закрытия?} L -->|Нет| M[Арендатор видит прогресс] L -->|Да| N["APPROVAL
Управляющий подтверждает закрытие"] K --> N N --> M M --> O[История обращения закрыта] O --> P{Арендатор подтверждает устранение?} P -->|Да| Q[Кейс окончательно закрыт] P -->|Нет| R[Запускается повторный выезд]

Автоматизация возвратов и типовых вопросов в интернет-магазине

Как было

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

На один и тот же тип запроса тратились одни и те же действия снова и снова.

Как стало

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

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

Схема

flowchart LR A1[Чат магазина] --> B[Определение сценария] A2[Почта] --> B A3[Форма возврата] --> B A4[Колл-центр] --> B B --> C[Данные по заказу] B --> D[Правила возврата] B --> E[История обращения] C --> F[Проверка статуса и сроков] D --> G{Сценарий типовой?} E --> G F --> G G -->|Да| H[Инструкция и следующий шаг] G -->|Нет| I[Спорный кейс] H --> J[Создание возврата или обмена] I --> K[Сотрудник получает всю историю] J --> L{Возврат подтвержден?} L -->|Да| M[Клиент видит статус процесса] L -->|Нет| N["APPROVAL
Менеджер подтверждает исключение"] K --> N N --> O[Платеж на возврат или обмен] O --> P[Уведомление складу и клиенту] P --> Q[Клиент видит статус процесса] P --> R[Обновление CRM и истории заказа] Q --> S{Деньги уже отправлены?} S -->|Да| T[Кейс закрыт] S -->|Нет| U[Финансовая команда подключается]

Автоматизация первичного отбора кандидатов

Как было

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

Это была тяжёлая рутинная часть процесса, которая отнимала время у живой работы с сильными кандидатами.

Как стало

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

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

Схема

flowchart LR A1[hh.ru] --> B[Единая структура резюме] A2[Telegram] --> B A3[Почта] --> B A4[Рекомендация] --> B B --> C[Опыт и навыки] B --> D[Локация и формат] B --> E[Язык и стек] C --> F[Обязательные критерии] D --> G[Желательные критерии] E --> F F --> H{Проходит порог?} G --> H H -->|Да| I[Карточка кандидата] H -->|Нет| J[Пометка риска] I --> K{Звать на следующий этап?} J --> L[Ручной разбор рекрутером] K -->|Да| M[Следующий этап] K -->|Нет| N[Архив с меткой] L --> O["APPROVAL
Рекрутер утверждает решение"] O --> P[Интервью или short-list] O --> Q[Резервный пул] P --> R{Нужен второй фильтр нанимающего?} R -->|Да| S[Hiring manager принимает решение] R -->|Нет| T[Кандидат идет дальше сразу]

Автоматизация онбординга новых сотрудников

Как было

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

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

Как стало

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

Когда требуется доукомплектация, включается отдельный цикл и approval готовности. После него могут запускаться дополнительные действия: назначение buddy, отправка welcome pack, сигнал руководителю, что человек действительно готов к первому дню. Поэтому онбординг становится управляемой адаптацией.

Схема

flowchart LR A1[Оформление] --> B[Определение роли] A2[HR-данные] --> B A3[План выхода] --> B A4[Запрос руководителя] --> B B --> C[Маршрут онбординга] C --> D[Доступы] C --> E[Техника] C --> F[Документы и вводные] D --> G[Контроль сроков] E --> G F --> G G --> H{Есть задержка?} H -->|Нет| I[Этап закрыт] H -->|Да| J[Напоминание ответственным] I --> K{Сотрудник готов к старту?} K -->|Да| L[HR видит статус] K -->|Нет| M[Дополнительные вводные] J --> N[Руководитель видит задержку] M --> O["APPROVAL
HR подтверждает готовность"] O --> P[Назначение buddy] O --> Q[Welcome pack отправлен] P --> R[HR видит статус] Q --> R Q --> S[Руководитель получает сигнал о готовности] R --> T{Первый день прошел нормально?} T -->|Да| U[Онбординг идет по плану] T -->|Нет| V[Подключается HR и руководитель]

Автоматизация регулярных отчётов

Как было

Отчёты собирались вручную из CRM, таблиц, задач, рекламных кабинетов и переписок. Чтобы сделать один нормальный отчёт, нужно было долго вытягивать цифры из разных мест, приводить их к одному периоду и потом уже пытаться объяснить, что происходит.

Это занимало много времени и сильно зависело от конкретного сотрудника, который умел всё это правильно свести.

Как стало

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

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

Схема

flowchart LR A1[CRM] --> B[Проверка периода] A2[Таблицы] --> B A3[Рекламные кабинеты] --> B A4[Задачи и переписки] --> B B --> C[Раскладка по разделам] C --> D[Сравнение с прошлым периодом] C --> E[Поиск отклонений] C --> F[Сбор пояснений] D --> G[Рост и просадка] E --> H[Риски и аномалии] F --> I[Контекст по причинам] G --> J[Черновик отчета] H --> J I --> J J --> K{Нужна ручная правка?} K -->|Нет| L[Проверка и отправка] K -->|Да| M[Ответственный дополняет выводы] M --> N{Выводы согласованы?} N -->|Да| O["APPROVAL
Руководитель утверждает отчет"] N -->|Нет| P[Доработка формулировок] O --> Q[Дашборд и письмо собраны] P --> R[Повторная сверка] Q --> S[Проверка и отправка] S --> T{Нужен комментарий руководителя?} T -->|Да| U[Добавляется управленческий комментарий] T -->|Нет| V[Отчет уходит получателям]