Менеджер больше не сверяет скриншоты оплат: автоматизация платежей в языковой школе на n8n и GPT-4 Vision

Sami Residence - языковая школа для эмигрантов в Тбилиси. У школы много групп, преподавателей и учеников, а оплаты приходят самым обычным способом: человек пишет в Telegram-аккаунт школы и отправляет скриншот банковского перевода.

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

Если коротко

Я собрала для Sami Residence self-hosted n8n-бота, который читает скриншот или PDF оплаты, распознаёт сумму, дату и реквизиты через GPT-4 Vision, находит ученика в МойКласс, создаёт абонемент, проводит платёж и пишет логи.

За май 2026 бот обработал 144 платежа: 139 провёл полностью автоматически, 5 спорных отдал менеджеру. Потерянных платежей: 0.

Почему это не просто распознавание чеков

В интернете много шаблонов в духе «пришлите чек в Telegram, мы положим сумму в Google Sheets». Это полезно, но для бизнеса этого мало.

Задача Sami была не в том, чтобы распознать картинку. Задача была в том, чтобы закрыть весь денежный процесс:

1. понять, что в сообщении действительно оплата;
2. достать из чека сумму, дату и реквизиты;
3. понять, какой это ученик;
4. найти или создать его в CRM;
5. создать абонемент;
6. провести платёж на правильные реквизиты;
7. оставить лог для команды;
8. ответить ученику, что оплата внесена.

То есть бот не «читает чек». Он доводит оплату до состояния, когда она уже лежит в CRM и с ней можно работать дальше.

Что было до

Когда в Telegram прилетал скриншот оплаты, менеджер каждый раз делал руками один и тот же набор действий:

1. открывал сообщение и понимал, кто написал;
2. выяснял, в какой группе находится ученик;
3. находил его в МойКласс;
4. создавал абонемент;
5. проводил платёж;
6. выбирал нужные реквизиты, потому что у школы несколько счетов;
7. отвечал ученику, что всё хорошо и оплата внесена.

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

Проблема была не только во времени. В такой рутине легко пропустить сообщение, перепутать группу, не туда посадить платёж или оставить оплату «в голове менеджера», а не в системе.

Самый неприятный сценарий: ученик заплатил, но в CRM этого не видно.

Было и стало

До автоматизации	После автоматизации
Менеджер вручную разбирал каждый скриншот	Бот проверяет входящие сообщения 24/7
Нужно было искать ученика и группу руками	Бот ищет ученика в МойКласс сам
Если ученика нет, процесс стопорился	Бот создаёт карточку и помечает, что нужна проверка
Абонемент и платёж создавались вручную	Абонемент и платёж создаются автоматически
Нужно было помнить, на какие реквизиты пришли деньги	Бот берёт реквизиты из чека
Состояние оплаты жило в переписках и голове менеджера	Каждый шаг сохраняется в логах

Как работает сейчас

Для ученика ничего не изменилось. Он пишет в тот же Telegram-аккаунт школы и отправляет скриншот или PDF оплаты, как раньше.

Разница в том, что теперь этот аккаунт проверяет бот, подключённый через Telegram Business. Он работает 24/7 и разбирает входящие сообщения сам:

1. проверяет, есть ли в сообщении файл, скриншот или PDF;
2. определяет, похоже ли вложение на платёж;
3. отправляет файл на распознавание;
4. достаёт сумму, дату платежа и реквизиты получателя;
5. ищет ученика в МойКласс;
6. если ученик уже есть в CRM, использует существующую карточку;
7. если ученика нет, создаёт нового и помечает, что нужна проверка менеджера;
8. создаёт абонемент;
9. проводит платёж с нужными реквизитами;
10. сохраняет лог каждого шага;
11. уведомляет менеджера;
12. отвечает ученику: «спасибо за оплату».

Флоу в n8n получился не из трёх нод. Там обработка файлов, распознавание, проверки, ветки для разных сценариев, интеграция с МойКласс, логи, уведомления и фолбэки на человека.

Как мы учли редкие сценарии

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

Разные форматы оплат. Ученики присылают и скриншоты, и PDF. Банки грузинские и русские, чеки выглядят по-разному. Бот приводит это к одному процессу.

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

Новый ученик. Если ученика нет в МойКласс, бот не падает и не теряет платёж. Тут есть нюанс: по нашей договорённости абонемент можно создавать только когда ученик привязан к группе. Поэтому, если группа неизвестна, бот определяет ученика в группу «без группы», создаёт абонемент и помечает менеджеру: проверить на дубль и перенести в нужную группу.

Несколько реквизитов. У школы несколько счетов. Если посадить платёж не туда, потом поедет сверка. Поэтому бот определяет реквизиты получателя из чека и проводит платёж на нужный тип оплаты.

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

Логи: чтобы автоматизация не была чёрным ящиком

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

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

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

Для команды это важно. Если менеджер хочет проверить конкретную оплату, он видит не только итог, но и следы процесса.

Что осталось у команды после внедрения

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

Для Sami Residence документация лежит в общей папке Google Drive: обзор системы, инфраструктура, сценарии по платежам, событиям и напоминаниям, runbook и отдельный файл с доступами.

Файлы с ключами и чувствительными данными передаются отдельно через секретный файл, а не открытым текстом в переписке. Да, это менее эффектно, чем «смотрите, какой умный бот». Но именно такие скучные вещи делают автоматизацию рабочей системой, а не игрушкой.

Сколько стоит поддерживать такого бота

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

В этом проекте постоянные технические расходы примерно такие:

Статья	Примерная стоимость
VPS-сервер для self-hosted n8n	около $8 в месяц
Распознавание скриншотов и PDF	около $4-5 в месяц
Итого за инфраструктуру	около $12-13 в месяц

Это не отдельный сервер только под один бот. На этом же n8n у Sami работают и другие сценарии: запись на мероприятия, напоминания о задолженностях, напоминания о старте групп. То есть эти $8 за сервер закрывают не один процесс, а всю связку автоматизаций школы.

Почему для них это выгодно: у школы много входящих сообщений. Если запускать такой процесс в облачном n8n или в конструкторах ботов, лимиты быстро становятся важными. Например, у n8n Cloud тариф Starter на момент написания стоит около $30 в месяц и идёт с лимитом по числу запусков сценариев. А в платёжном боте каждое входящее сообщение сначала нужно проверить: это оплата, вопрос менеджеру или просто обычная переписка, и эти проверки тоже расходуют лимит.

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

Self-hosted n8n в таком сценарии даёт нормальную экономику: можно запускать несколько ботов, не бояться, что обычная переписка быстро съест облачный лимит, и держать данные на инфраструктуре клиента.

Результат

За май 2026 бот обработал 144 платежа.

Метрика	Результат
Всего платежей за май 2026	144
Проведены автоматически	139
Ушли на ручной разбор	5
Доля автоматической обработки	96,5%
Потерянные платежи	0
Время на проводку одного платежа	около 5 минут → 0
Статус	Работает в проде ежедневно

Главное здесь не только 96,5%. Главное, что оставшиеся 3,5% не потерялись. Бот отдал их менеджеру, как и должен был.

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

Куда это можно перенести

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

• онлайн-школы и курсы;
• языковые школы;
• студии и секции;
• локальные сервисы;
• мероприятия и клубы;
• небольшие бизнесы, где CRM уже есть, но оплаты всё ещё разносят руками.

CRM тоже не обязана быть МойКласс. Если у системы есть API или хотя бы понятный способ принимать данные, можно собрать похожий процесс под GetCourse, BotHelp, amoCRM, HubSpot или кастомную базу.

---

Если у вас оплаты тоже копятся скриншотами, а кто-то разносит их руками, такую схему можно собрать под ваши инструменты: Telegram, WhatsApp, GetCourse, МойКласс, BotHelp, amoCRM, HubSpot или вашу внутреннюю CRM.

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