Владелец «Кодиума» прислал список полей для кабинета. В нём тридцать строк: дата рождения ребёнка, школа, класс, любимый предмет, откуда узнали, имя второго родителя, номер договора, промокод… «Сделай как в amoCRM, с воронкой». Можно молча начать собирать. Тогда через месяц менеджеры будут заполнять пять полей, а остальные двадцать пять так и останутся пустыми.
Чему научишься в этом уроке:
• отбирать поля заявки по правилу «что влияет на запись»;
• описывать роли таблицей «кто что может»;
• понимать, зачем журнал изменений и что в нём писать;
• рисовать схему двух серверов с ключом приёма.
Пять полей вместо тридцати
В блоке «Клиенты и деньги» есть приём для таких случаев. Клиент говорит: «Мне нужна CRM с 50 полями». Ты отвечаешь: «Понял. Давайте разберёмся, какие поля реально влияют на ваш доход». Это не отказ, а переформулировка задачи. Подробно разберём её в уроке про клиентов и деньги, а здесь применим сразу.
Что нужно менеджеру, чтобы записать человека на курс? Позвонить, понять, какой курс, знать, откуда пришёл человек и на каком шаге разговор. Получилось пять полей:
- имя и телефон: чтобы позвонить;
- курс: о чём говорить (Python, веб-разработка, нейросети, пока не знаю, как в боте из П1);
- источник: бот или сайт, чтобы владелец видел, откуда идут заявки;
- статус: новая, в работе, записан, отказ.
Плюс служебные: номер заявки, время создания и время согласия на обработку данных (consent_at, из урока 2.4). Без согласия кабинет заявку не примет. Комментарий менеджера живёт отдельно, у карточки.
Правило отбора: поле остаётся, если без него менеджер не сможет записать клиента или владелец не поймёт, откуда клиенты. Всё остальное можно спросить на звонке. Каждое лишнее поле с данными о человеке ещё и лишняя ответственность по 152-ФЗ.
Роли: кто что может
Роль похожа на ключи от кабинетов в офисе. У менеджера ключ от комнаты с заявками, у владельца связка от всех дверей. В кабинете «Кодиума» две роли:
- список заявок, фильтр, поиск, карточка: менеджер да, владелец да;
- сменить статус, написать комментарий: менеджер да, владелец да;
- удалить заявку: менеджер нет, владелец да;
- пользователи (создать, отключить, сбросить пароль): менеджер нет, владелец да;
- выгрузка в xlsx: менеджер нет, владелец да;
- мини-аналитика (заявки по источникам, доля «записан»): менеджер нет, владелец да.
Главное правило ролей: права проверяет сервер при каждом действии. Спрятать кнопку «Удалить» от менеджера мало. Если он наберёт адрес удаления руками, сервер должен ответить отказом (код 403, «доступ запрещён»). Скрытая кнопка похожа на дверь, занавешенную шторкой: снаружи не видно, но открыть можно.
Журнал: кто, когда, было, стало
Помнишь Ольгу, которой позвонили дважды? Журнал отвечает на вопрос «что тут произошло». Каждая смена статуса и каждое удаление пишут строку:
2026-10-10 13:40 МСК · manager · заявка №2 · статус: новая → в работе
2026-10-10 15:05 МСК · owner · заявка №1 · удалена (была: новая, источник test)Пример условный, но поля именно такие: время, кто, какая заявка, что было и что стало. Пароли и ключи в журнал не попадают никогда. Удаление тоже пишется, иначе пропажу заявки не объяснить.
Схема двух серверов
В прошлом уроке решили: кабинет в Москве, бот и форма в Амстердаме. Теперь подробно, как заявка доходит. Это похоже на приём формы с сайта из урока 3.3, только теперь принимает кабинет:
- Бот или форма получили заявку и сразу отправляют её в кабинет: адрес
/api/zayavka, поля name, phone, course, source, consent_at. - В заголовке запроса лежит ключ приёма
X-Ingest-Key. Это как пароль на служебном входе: без верного ключа кабинет отвечает 401 («не авторизован»), без согласия 400 («неверный запрос»). - Кабинет возвращает номер заявки. Бот шлёт владельцу в Telegram: «Новая заявка №N, курс, источник» и ссылку на карточку. Имени и телефона в сообщении нет.
- Если кабинет не ответил за 10 секунд, бот пробует ещё 2 раза. Не вышло: владельцу в Telegram уходит имя и телефон, чтобы внести вручную, а на сервере в Амстердаме остаётся только номер попытки, курс и время, без ПД.
А может, взять готовую CRM?
Честный вопрос, и его стоит задать заказчику до работы. Готовые CRM вроде amoCRM и Битрикс24 хороши, если клиенту хватает их возможностей и он готов платить подписку. Свою пишем, когда нужна связка с его ботом и формой, когда работают 2–3 человека и важна простота: пять полей, две роли, ничего лишнего. Если готовая подходит, скажи это прямо. Доверие дороже одного заказа.
Модель на одну страницу
Итог проектирования помещается на страницу: поля заявки, статусы, роли с таблицей прав, что пишет журнал, схема серверов. Эту страницу ты отдашь агенту в следующем уроке как основу задания.
Контрольный вопрос. Менеджер набрал в браузере адрес удаления заявки, хотя кнопки «Удалить» у него нет. Что должно произойти?
Подсказка: Где проверяются права: в браузере или на сервере?
На курсе задания проверяются автоматически. Решить первое задание бесплатно → · Подобрать курс
Контрольный вопрос. Заказчик хочет в заявке поле «дата рождения ребёнка». Как решить по правилу урока?
Подсказка: Нужно ли это поле, чтобы позвонить и записать?
На курсе задания проверяются автоматически. Решить первое задание бесплатно → · Подобрать курс
Контрольный вопрос. Кабинет не ответил боту за 10 секунд и после двух повторов. Что происходит с заявкой по схеме урока?
Подсказка: Что можно хранить за рубежом, а что нельзя?
На курсе задания проверяются автоматически. Решить первое задание бесплатно → · Подобрать курс
Задание. МИССИЯ «Кабинет на одной странице». 1. Для своего заказчика выпиши поля заявки (или клиента, заказа) и оставь только те, без которых нельзя довести клиента до оплаты. Для каждого вычеркнутого поля напиши одной строкой, почему. 2. Задай статусы (3–5 штук). 3. Нарисуй таблицу ролей «действие → кто может». Отметь, что видят только старшие. 4. Напиши, какие события пишет журнал. 5. Нарисуй схему: где кабинет, откуда приходят заявки, какой ключ на входе, что уходит в уведомление. 6. Ответь честно: подошла бы заказчику готовая CRM? Почему да или нет. Сделай в среде: Запиши поля и роли в schema.sql (попроси агента или напиши сам) и проверь его на настоящей базе: дай агенту задание «создай test.db из schema.sql через модуль sqlite3 Python и выведи список таблиц с колонками». Отдельно ставить sqlite3 не нужно. Принято, если: приложена одна страница с полями (и списком вычеркнутых с причиной), статусами, таблицей ролей, событиями журнала, схемой и ответом про готовую CRM; приложен вывод списка таблиц, где видны таблицы заявок и пользователей, и схема совпадает с полями на странице.
Подсказка: В таблице ролей у каждого действия должен быть ответ «да» или «нет» для каждой роли.
✅ Готово, если: программа запускается без ошибок и выводит то, что просят в задании.
На курсе задания проверяются автоматически. Решить первое задание бесплатно → · Подобрать курс
Что дальше
Проект готов. В следующем уроке отдадим его агенту одним заданием и посмотрим, что получится и что придётся убирать за ним.
Итог:
• пять полей (имя, телефон, курс, источник, статус) плюс согласие вместо тридцати;
• две роли, права проверяет сервер, удаление только у владельца;
• журнал пишет кто, когда, было, стало;
• заявка идёт в кабинет по ключу X-Ingest-Key, уведомление без ПД.
