Проектируемый сценарий Дирижёра: клиент переносит встречу в чате, агент уточняет часовой пояс, проверяет доступность и меняет событие только после согласования. Это условный разбор, не опубликованный клиентский результат. Реплики и участники вымышлены; наличие конкретного календарного подключения и права на запись проверяется отдельно.
Суть задачи — сохранить одно понятное событие вместо трёх версий времени в переписке. «Давайте завтра в три» звучит дружелюбно, пока один участник работает в Москве, другой находится в командировке, а календарь показывает время домашнего региона. Ниже разберём передачу контекста между чатом, агентом и календарём без обещания волшебной синхронизации.
Что известно до просьбы о переносе
Условная компания проводит демонстрации оборудования. В системе есть встреча с идентификатором, участниками, длительностью, часовым поясом события и подтверждённым временем. В чате менеджер видит связанный контакт. Важно, чтобы агент работал с конкретным событием, а не искал любое похожее название в календаре. У одного клиента могут быть несколько встреч.
До запуска владелец процесса назначает полномочия. Агент может читать доступность определённых календарей и готовить предложение. Запись разрешается после явного подтверждения в согласованном сценарии. Отмена встречи, изменение состава участников и отправка внешних уведомлений рассматриваются отдельно. Право читать свободные слоты не означает право менять любое событие компании.
Сценарий ограничен переносом одной встречи без изменения её длительности. Это полезная граница для пилота: команда проверит временные значения, подтверждение и повторные события. Совместное бронирование нескольких специалистов или помещений можно добавить позже. Иначе неудачу будет трудно объяснить: ошибка в часах, правах, ресурсе или выборе встречи даст один общий красный статус.
В демонстрационных данных нет настоящих адресов почты или закрытой переписки. Для реального запуска нужны утверждённые правила доступа и хранения. Публичная иллюстрация показывает механизм принятия решения. Она не должна становиться способом показать чужой рабочий календарь ради красивого скриншота, даже если персональные данные кажутся несущественными.
Короткий диалог, в котором важно не угадать
Клиент пишет: «Можно перенести завтрашнюю демонстрацию на пятницу, на три?» Агент сопоставляет сообщение с событием и уточняет: «Пятница, 30 октября, в 15:00 по Москве?» Дата здесь условная часть примера. В рабочем интерфейсе она вычисляется из текущего контекста и показывается полностью, чтобы относительное «завтра» не пережило несколько дней переписки.
Клиент отвечает: «Я буду в другом городе, имел в виду три по местному». Это основание уточнить регион, а не самостоятельно определять его по IP или номеру телефона. Агент спрашивает город или часовой пояс и повторяет итоговое время в понятной форме. Необязательные догадки могут быть подсказкой оператору, но не основанием для календарной записи.
После уточнения агент предлагает доступный интервал, а не просто конвертирует желаемые часы. Перевод времени и занятость — разные проверки. Если слот свободен только у менеджера, но занят нужный специалист, предложение пока не готово. Состав ресурсов определяется процессом компании. В пилоте лучше иметь небольшой явный список, чем подразумеваемую проверку «всех нужных людей».
Финальная реплика содержит дату, местное время клиента, опорный пояс и длительность. Например: «Подтвердите перенос на выбранную дату, 15:00 в вашем городе; у менеджера это будет другое местное время. Длительность — 30 минут». В реальном сообщении вместо общего пояснения показываются точные значения. Здесь они не вычисляются без конкретного региона и даты.
Из предложения в одно обновлённое событие
Пока человек не подтвердил предложение, исходная встреча остаётся действующей. Черновик нового времени не должен выглядеть как уже выполненный перенос. Интерфейс показывает состояния «проверяем», «предложено», «ожидает подтверждения», «обновлено» либо «нужна помощь». Разные состояния помогают менеджеру быстро понять, должен ли он вмешаться и что клиент уже увидел.
Перед записью агент повторно проверяет актуальность события и доступность интервала. Между предложением и ответом клиента слот мог занять другой человек. Для защиты от конкурирующих изменений применяется поддерживаемый API механизм проверки версии или другая согласованная операция. Если гарантий нет, это ограничение нужно учесть в процессе, а не скрывать за анимацией успешной галочки.
Изменять следует то же событие, если именно так устроена интеграция, а не молча создавать второе. Идентификатор связывает действие с исходной встречей. Повторная доставка сообщения или повторная обработка задачи не должна давать два переноса и два письма. Журнал операции помогает различить новое решение клиента и технический повтор уже принятого решения.
После записи агент проверяет ответ календаря. Сообщение «готово» допустимо только при подтверждённом результате. Если уведомление участникам отправляется отдельным механизмом, его статус учитывается отдельно. Событие может быть обновлено, а письмо ещё не доставлено. Это не одно состояние, и менеджеру важно видеть, где именно остановился маршрут.
Неопределённости: сезонное время, поездки и длинные паузы
Фиксированное смещение от UTC не описывает все правила региона на будущие даты. Для событий, связанных с местным расписанием, нужен подходящий идентификатор часового пояса и актуальные правила. Не следует вручную зашивать разницу «всегда два часа». На конкретную дату она может отличаться в регионах с сезонными изменениями или после обновления правил.
Если клиент говорит «я сейчас в Лондоне, но встреча нужна на время московского офиса», временное местоположение не меняет желаемую основу записи. Агент должен уточнить смысл времени. Система хранит не только числа, но и договорённость: чьё местное расписание важно. Это особенно заметно у повторяющихся встреч, которые не входят в первоначально ограниченный пилот.
Длинная пауза в чате делает относительные формулировки опасными. Клиент может подтвердить «да» на следующий день, отвечая на конкретное старое предложение. Агент связывает подтверждение с версией предложения и проверяет срок его актуальности. Если связь потеряна, лучше переспросить, чем интерпретировать короткую реплику как согласие на последний автоматически вычисленный слот.
Отмена, просьба сменить специалиста и сообщение другого участника требуют отдельных правил. Например, приглашённый коллега не обязательно имеет право переносить встречу за всех. Разрешение определяется ролью и процессом, а не уверенностью модели. Когда основание неясно, агент готовит задачу менеджеру с кратким контекстом и не меняет календарь самостоятельно.
Приёмка: четыре представления одной договорённости
Проверяется время в сообщении клиенту, в карточке агентской задачи, в календаре менеджера и в итоговом приглашении. Все четыре представления должны описывать один момент и одну длительность. Одинаковые цифры на двух экранах не всегда означают совпадение: у экранов могут быть разные пояса. Сравнение ведётся по нормализованному времени и сохранённой региональной основе.
Тестовые ситуации включают неизменённый пояс, поездку, неоднозначное название города, переход через полночь, длительный ответ и изменение события менеджером. Отдельно проверяются ошибки доступа и повторная обработка. У каждой ситуации есть ожидаемая запись и допустимое сообщение человеку. Положительный разговор без правильного календарного результата не считается успешной приёмкой.
На первом этапе лучше использовать тестовые календари и вымышленные контакты. Проверка отправки приглашений настоящим людям — отдельное разрешённое действие. Для визуальной демонстрации можно показать записи тестового контура с понятной подписью. Не стоит выдавать постановочный календарь за доказательство промышленной работы на клиентской базе.
Итоговый протокол сохраняет версии сценария и интеграции, состав тестов, фактические результаты и нерешённые ограничения. Если обнаружена ошибка в переводе времени или повторная запись, выпуск останавливается до исправления. Средняя оценка вежливости реплик не компенсирует неверно назначенную встречу. Никакие измеренные проценты в этом условном разборе не заявляются.
Что получает менеджер, когда агенту нужна помощь
Хорошая передача содержит исходное событие, просьбу клиента, уточнённый пояс, предложенный интервал и причину остановки. Плохая передача — «клиент хочет перенос, свяжитесь». Во втором случае человек заново собирает весь контекст, а клиент повторяет уже сказанное. Сокращение повторного сбора можно измерять в пилоте, но заранее обещать экономию нельзя.
Для расчёта эффекта сначала фиксируют ручной процесс: время на поиск события, уточнение пояса, проверку участников и уведомление. Затем сравнивают сопоставимый набор задач после подключения. Если агент только готовит черновик, а сотрудник делает запись, результат нельзя описывать как полностью автоматический перенос. Граница работы должна оставаться видимой и в отчёте, и на лендинге.
Переход к запуску возможен после проверки разрешений, исключений, доступности ручного подхвата и контроля повторных операций. Начать можно с одного календаря и одного вида встречи. На странице Дирижёра обсуждается организация общения; статья о часовых поясах онлайн-записи раскрывает временные данные подробнее.
Документация и честные границы
Использованы Google Calendar: события, календари и часовые пояса, база часовых поясов IANA и RFC 3339: представление времени и смещения. Документация проверена 25 октября 2026 года; она не подтверждает настройку конкретного аккаунта Дирижёра.
Разбор описывает требования к проектируемому маршруту. Нет данных о росте встреч, экономии времени или результатах клиента. Чтобы сделать его работающим, нужно проверить продуктовые возможности, календарный API, права и реальные ограничения процесса. Эти действия составляют отдельную техническую и организационную приёмку.