Запись как операция в расписании
Подходит процессу, где известны услуги, длительность, ресурсы и правила переноса. В диалоге можно уточнить услугу, предложить допустимое время и получить намерение клиента; факт записи должен появиться в системе расписания.
ЛидПоток проектирует индивидуальный процесс. Эта страница описывает состав обсуждения и проектирования; готовность конкретного подключения подтверждается отдельной проверкой прав, API и тестов в вашей конфигурации. Наличие документации сервиса не означает выполненное подключение.
Что проектируем и где останавливаемся
Проверку доступности слота, создание записи, перенос, отмену и актуальность напоминаний. Каждое действие имеет отдельные права и подтверждение. Если ответ сервиса потерян, сначала проверяем статус операции, а не бронируем повторно. При конфликте слота предлагаем альтернативу; поздние изменения идут администратору по согласованному правилу.
Подключение зависит от системы записи
Таблицу можно прокрутить по горизонтали.
| Контур | Статус и ограничение |
|---|---|
| Расписание / календарь | Проектируемая интеграция; наличие API само по себе не доказывает защиту от двойной записи. Нужны права, часовой пояс и проверка конкурирующих запросов. |
| CRM | Может хранить контекст обращения, но не заменяет источник доступности времени. Контракт полей и событий проверяется отдельно. |
| Напоминания / оплата | Отдельный согласованный контур. После переноса устаревшее напоминание отменяется; платёж не подтверждается текстом агента. |
Этапы и поставка
- Описать услуги, длительность, часовой пояс и ресурсы.
- Утвердить правила создания, переноса и отмены.
- Проверить API и источник истины для записи.
- Прогнать конфликт слота, потерю ответа и повтор.
- Согласовать протокол и регламент администратора до запуска.
Поставка по ТЗ: матрица действий и прав, карта статусов записи, правила уведомлений, тесты и инструкция восстановления.
Приёмка: запись, перенос и визит
Два запроса на один слот дают одну бронь и один конфликт; повтор с тем же ключом возвращает исходную запись. При переносе сохраняется связь с прежней записью и обновляется напоминание. Метрики раздельные: подтверждённая запись, отмена, состоявшийся визит. Не включаем будущие визиты в расчёт явки.
Стенд конкуренции за слот
Два потока обращаются к временной SQLite-базе с уникальным слотом. Получаются accepted и conflict; повтор первого ключа возвращает прежний booking ID. Это ограниченная модель равных слотов, без внешнего календаря, пересечений длительностей и ИИ. Код и результаты стенда.
Сопровождение и следующий шаг
Порядок поддержки, срок, состав изменений и ответственность фиксируются в договоре и ТЗ. При изменении условий, знаний или API повторяем затронутые приёмочные сценарии. Бизнес-эффект измеряется отдельно и не гарантируется фактом запуска.
Для первого разговора достаточно схемы процесса, списка систем и обезличенного примера. Не передавайте пароли, токены и клиентские выгрузки через форму.