Переоформление договоров на автопилоте

Каждую весну «ОНЛАЙН-ШКОЛА №1» переоформляет договоры на новый учебный год — сотни заявок в неделю, каждая вручную. Мы собрали сервис, который делает это сам: сотрудник только проверяет и нажимает «Отправить».

Ручная работа
10%
было 100%
Заявок в срок
99%
было 90%
Поток заявок
+24%
отдел не вырос
Долгие заявки
1,1 ч
было 4 часа

Процесс работал. Запаса у него не было

«ОНЛАЙН-ШКОЛА №1» — школа полного цикла в онлайне: дети зачисляются, учатся по программе и сдают аттестацию здесь же. Это не кружки в дополнение к обычной школе, а её замена. За годы работы через неё прошли десятки тысяч учеников, в команде несколько сотен человек.

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

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

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

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

Жёсткое условие

Персональные данные учеников и родителей не должны покидать контур клиента (152-ФЗ). Никаких внешних AI-сервисов для обработки заявок — вообще.

Сервис-прослойка, а не доработка учётной системы

Мы построили сервис между трекером задач, учётной системой 1С и CRM. Он забирает заявку, разбирает её, считает деньги, генерирует документы и создаёт готовый заказ. Сотрудник открывает результат, проверяет и отправляет.

Не трогали 1С

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

Расчёт денег — одна формула на всех

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

Человек остаётся в контуре

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

Данные не покидают периметр

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

Было вся расчётная и документарная работа на человеке
Заявкаприходит в трекер
Сотрудник делает всё сам
  • сверяет тариф с прайсом
  • применяет скидки и акции
  • собирает график платежей
  • заполняет договор и приложение
  • заводит заказ в учётной системе
  • сверяет суммы
15–20 минут · до целого дня на сложных
Пакетуходит родителю
Стало за человеком — проверка и последнее нажатие
Заявкаприходит в трекер
Сервис
  • разбирает заявку
  • считает деньги по справочникам школы
  • генерирует договор и приложение
  • заводит готовый заказ
нетиповое и спорное → человеку, с причиной
Сотрудникпроверяет и жмёт «Отправить»
Пакетуходит родителю

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

Поток вырос на четверть, ручной работы — в десять раз меньше

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

Руками
неделя мая
С сервисом
неделя августа
Поток заявок за неделюбазовый уровень+24%
Заявок сделано руками100%10%
Закрыто в срок90%99%
Медианное время на заявку0,70 ч0,43 ч (−39%)
90-й перцентиль4,01 ч1,11 ч (−72%)
Неделя мая — рукамибазовый поток
вручную 100%
Неделя августа — с сервисомпоток +24%
сервис сам 90%руками 10%
вручную автоматически

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

Вторая по важности строка — 90-й перцентиль. Это про «долгие» заявки, те самые, из-за которых родитель звонит и спрашивает, где документы. Раньше каждая десятая заявка занимала больше четырёх часов — теперь такая же десятая укладывается в час с небольшим. Процесс стал не просто быстрым, а предсказуемым.

На более длинном отрезке

Три недели ручного режима против двух недель августа.

Руками
три недели мая
С сервисом
две недели августа
Недельный потокбазовый уровень+73%
Доля заявок, закрытых без сервиса99%1%
Закрыто в срок91%99%
Медиана0,62 ч0,39 ч (−37%)
90-й перцентиль3,69 ч1,03 ч (−72%)

В мае сервис уже проходил обкатку на отдельных заявках — поэтому на трёхнедельном отрезке 99%, а не ровно 100%.

Один и тот же человек

Чтобы отделить эффект автоматизации от эффекта «наняли ещё людей», мы посмотрели на одного сотрудника, который вёл участок и до, и после. В мае он тратил 0,53 ч на заявку и успевал в срок в 99% случаев. В августе — 0,34 ч, закрывая при этом в полтора раза больше заявок, и все 100% в срок. Тот же человек делает в полтора раза больше, тратя на каждую заявку на треть меньше времени — и это не за счёт спешки.

Что происходит внутри автоматики

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

Полная картина по исходам (устойчивый режим, выборка в несколько тысяч заявок):

ИсходДоляЧто это
Сервис довёл до готового заказа сам85,3%готовый заказ, сотрудник только отправляет
Сработала защита4,7%человек уже оформил заказ — сервис не создал второй
Не хватает данных4,0%ушло сотруднику с объяснением причины
Нетиповой случай1,8%по правилам не наша зона — отдано человеку
Технический сбой0,4%единичные случаи
Сервис не коснулся3,9%заявку закрыли раньше вручную

Сложив всё, что дошло до человека, получаем около 15% за весь устойчивый период — и именно эту долю чувствует отдел. Из них реальные проблемы (нехватка данных плюс сбои) — 4,4%, остальное штатное поведение: сервис намеренно не лезет туда, где не должен.

Доля не стоит на месте и зависит от того, что происходит в сезоне. В июле она была хуже — 20,5% ручной работы: шли акции с непривычными условиями, и сервис чаще упирался в нехватку данных. В августе — 12,0%. Разброс честнее одной усреднённой цифры: он показывает, где у автоматики предел и куда её расширять дальше.

Устойчивость под пиком

Этот эффект не виден в средних, но он и был главной целью. В конце мая, когда недельный поток скакнул примерно на треть, ручной режим просел: 52% в срок, медиана выросла до 3,63 ч, очередь копилась сотнями карточек. В августе школа прошла сопоставимый по нагрузке пик с показателем 99% в срок и медианой 0,39 ч. Очередь при этом не росла, а сократилась более чем в шесть раз.

Раньше сезонный пик ломал процесс. Теперь — нет.

Узнали свой отдел? Разберём ваш процесс так же — на цифрах, а не на обещаниях.

Разобрать наш процесс

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

Как мы это считали

Цифры выше — не ощущения заказчика и не наша оценка. Это сплошная выгрузка из трекера задач за три с половиной месяца, с мая по август 2026 года, из которой исключены тестовые карточки.

Абсолютные объёмы в кейсе намеренно не приводятся — только относительные изменения и порядок величины. Все проценты посчитаны от фактических данных.

О проекте

Клиент«ОНЛАЙН-ШКОЛА № 1»
СфераEdTech, общее образование школьников онлайн — зачисление, полный цикл, аттестация
МасштабДесятки тысяч учеников за годы работы, несколько сотен сотрудников
Что автоматизировалиПереоформление договоров на новый учебный год: от заявки в трекере до готового заказа в учётной системе и пакета документов
Срок до боевого запуска6 недель от старта разработки (планировали 4-5)
СтекPython, FastAPI, PostgreSQL, Docker. Интеграции: 1С УНФ, Яндекс.Трекер, Amo CRM, Google Sheets
ДанныеПолностью в российском контуре, 152-ФЗ, без передачи во внешние AI-сервисы
СтатусРаботает в проде, два сезонных пика пройдено

Посмотрим, где ваша команда теряет время

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

Или пришлите чужой кейс, где обещают процент автоматизации, — разберём методику и скажем, что за цифрой стоит.