Scentia автоматизировала сбор документов, а не решение о докторантуре

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

Scentia — гамбургский сервис, который помогает работающим специалистам с поступлением в докторантуру и работой над диссертацией, — показывает полезную границу такой автоматизации. В опубликованной Make 19 мая 2021 года истории клиента компания описала автоматизацию передачи и сопровождения данных заявителей. В источнике нет автоматизации решения о соответствии требованиям докторантуры, выбора университета или самой консультации.

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

До: заявка начиналась как проблема в почте

До внедрения Scentia использовала форму WordPress, Pipedrive и Office 365. Обращение с сайта приходило через форму, но сотрудник вручную создавал лид в CRM. Последующие изменения статуса, пришедшие по электронной почте, также нужно было переносить вручную.

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

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

Что изменилось: административное состояние стало общим маршрутом

В описании Make показан процесс, который связал уже существовавшие вокруг услуги этапы приёма и сопровождения. Новая заявка из формы направлялась ответственному сотруднику. Данные заявителя через вебхук сохранялись в Airtable. Outlook был подключён для заранее заданных последующих писем, а статусы Pipedrive использовались для отслеживания каждого кандидата и следующего необходимого действия.

1. Потенциальный заявитель отправляет форму на сайте.
2. Процесс направляет заявку ответственному сотруднику и создаёт структурированную запись заявителя в Airtable.
3. Заранее заданные последующие письма Outlook поддерживают запросы и напоминания, относящиеся к административной последовательности.
4. Pipedrive хранит статус кандидата и следующий необходимый шаг, давая команде актуальный рабочий обзор.
5. Сотрудник проверяет документы и выполняет профессиональную работу, которую нельзя безопасно вывести только из состояния процесса.

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

Что не изменилось: экспертиза осталась за пределами правил процесса

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

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

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

Польза — в ресурсе для той работы, за которую платит клиент

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

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

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

Сначала спроектируйте границу, потом соединяйте инструменты

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

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

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

Практический вывод

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

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

Источник: Make, «Customer onboarding automation case study: Scentia», опубликовано 19 мая 2021 года. Make представляет кейс как историю клиента; все заявленные результаты отнесены к этому источнику.