Сценарии внедрения
Как выглядит работа в системе на конкретных примерах
Сразу о том, чем это не является
Ниже четыре СЦЕНАРИЯ. Это не истории клиентов, не кейсы и не результаты внедрения: клиентских внедрений у продукта нет ни одного, и выдуманный кейс был бы подделкой, а не маркетингом.
Единственный настоящий прогон, который у нас есть, — внутренний пилот учебного центра на данных продукта. Он назван своим именем на странице учебного центра, и числа из него не выдаются за чужой результат.
Ни в одном сценарии ниже нет цифры эффекта. Насколько станет быстрее, измеряется на пилоте по времени первого ответа до и после, а не берётся из брошюры.
Один порядок работы во всех четырёх
Сценарии различаются данными и людьми, а не механикой. Механика одна: обращение → AI готовит → человек утверждает → запись в журнале.
- Обращение попадает в систему из канала и получает номер. Потерять его негде.
- AI-сотрудник готовит черновик: тему, ответ по подтверждённой базе, оценку или сводку. Каждое утверждение несёт ссылку на запись, из которой оно взято.
- Человек с правом решения принимает, правит или отклоняет. До его решения черновик не имеет последствий ни для кого.
- Действие наружу выполняет человек. Платформа не отправляет сообщений, не переводит денег и не подписывает документов.
- В журнал попадает, кто, что, когда и на каком основании решил. Стереть запись не может ни ошибка в коде, ни доступ к учётной записи приложения.
Сценарий 1. Застройщик: обращение с сайта до задачи менеджеру
Посетитель оставляет обращение на сайте объекта. Виджет пишет его в проект: номер, согласие на связь, источник. AI-менеджер по продажам определяет предмет обращения и готовит черновик ответа по подтверждённой базе — этапы, документы, условия.
Менеджер открывает черновик, правит и отвечает сам: платформа письмо не отправляет. Одновременно заводится задача со сроком, а если речь о договоре — сроки обязательств вынимаются из документа и попадают в реестр.
Что видно владельцу: сколько обращений пришло, сколько без ответа, где просрочка и кто что решил. Каждое число ссылается на записи, из которых посчитано.
Сценарий 2. Учебный центр: вопросы родителей по базе знаний
Администратор заводит подтверждённые ответы: цены, расписание, запись, возврат, скидки. Подтверждает их второй человек — автор собственный ответ подтвердить не может.
Вопрос родителя получает ответ из этой базы со ссылкой на запись. Вопрос, ответа на который в базе нет, получает честное «данных нет» и передаётся человеку — это не сбой, а правило.
Так это и работало во внутреннем пилоте: десять вопросов из базы получили ответ с источниками, три вопроса вне базы — «данных нет», потерянных вопросов ноль.
Сценарий 3. Клиника: обращение, согласие, след чтения
Пациент пишет через форму на сайте клиники. Обращение попадает в очередь с темой и сроком. Свободный текст проходит правило, помечающее возможно клиническое содержание: помеченное не уходит в черновик, пока его не разберёт человек.
Ответ готовится по подтверждённой базе и отправляется администратором. Запись на приём требует отдельного согласия — без него платформа отказывает, а не подставляет окно.
Отдельно ведётся журнал чтений: кто из сотрудников открывал карточку пациента. Это обычно и есть первый вопрос, который задаёт проверяющий.
Сценарий 4. Сервисная компания: заявка, срок, согласование
Заявка клиента попадает в очередь с приоритетом и сроком первого ответа. AI-операционный менеджер ведёт её по регламенту и отмечает отклонение от срока.
Счёт, который надо оплатить, проходит сверку плана с фактом: перерасход отказывается утвердить одним нажатием и требует явного подтверждения расхождения. Отказ остаётся в журнале строкой с причиной.
Необратимое действие требует решения двух человек. Автор предложения не может его же и утвердить — включая владельца компании.
Основание: docs/SALES_READINESS.md, docs/SCHOOL_PILOT_REPORT.md. Страница описывает то, что есть в этой
сборке, а не то, что запланировано.