Запись перенесли, а в календаре клиента осталось старое время

Выясните, что клиент фактически добавил

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

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

Ниже разбирается календарное представление визита у клиента. Чтение занятости сотрудника для поиска свободного времени — другое направление; для него есть отдельная приёмка внешнего календаря.

Файл: проверьте границы обещания

В справке Google об импорте событий прямо указано: импортированные события не поддерживают синхронизацию между двумя аккаунтами. Поэтому скачанный и импортированный ICS нельзя выдавать за канал последующих изменений. Это перенос снимка данных, а не доказательство действующей связи с записью.

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

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

Подписка: измеряйте ожидание

Microsoft различает импорт и подписку на календарь в Outlook: подписка получает изменения источника, но обновление может занять более 24 часов. Это предупреждение для Outlook, а не единый срок всех приложений. Обещать мгновенный перенос события нельзя.

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

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

Приглашение: сохраняйте связь версий

В iTIP UID связывает версии одного события. По RFC 5546, изменение начала или окончания требует увеличения SEQUENCE; при отмене через CANCEL версия тоже увеличивается. Для обычного переноса разового события проверяйте прежний UID и новую версию. Эти правила не гарантируют одинаковый интерфейс всех приложений.

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

В этом руководстве рассматривается одиночный визит. Серия с изменённым отдельным повторением требует собственной спецификации и испытаний. Нельзя принять её по удачному переносу одной разовой встречи.

Один визит, три независимых испытания

Создайте три одинаковых тестовых визита на 20 ноября 2026 года, 10:00–11:00, в одном явно указанном часовом поясе. Каждый предназначен для отдельного тестового календаря и одного способа передачи. Объект назовите «Проверка мастерской»; используйте вымышленное место. Это испытание, а не история реального клиента.

Сначала подтвердите исходное состояние. Затем согласованно перенесите каждый визит на 11:00–12:00 того же дня. Это сдвиг начала и окончания на 60 минут; длительность остаётся 60 минут. Изменение только начала до 11:00 при старом окончании 11:00 не проходит проверку.

Для дорожки приглашения задайте учебную цепочку: UID неизменен; SEQUENCE 0 при создании, 1 после переноса, 2 при CANCEL.

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

Ведите журнал наблюдений, а не список галочек

Для каждой дорожки сохраните исходную запись, действие администратора, ожидаемый результат, отправленный объект, время проверки и фактическое состояние получателя. В доказательствах полезны снимки экрана до и после, а для приглашения — обезличенные технические поля. Ссылка на внутреннюю карточку сама по себе не показывает чужой календарь.

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

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

Шесть наблюдаемых критериев

1. Создание. Получатель видит нужные дату, часовой пояс, начало, окончание и место. Можно объяснить, каким действием появилась карточка.
2. Перенос. В испытании отдельно записаны принятая договорённость и результат в календаре. Не остаются две действующие встречи, которые клиент примет за два визита.
3. Отмена. Проверены состояние карточки и напоминание. Внешний вид отмены фиксируется для конкретного приложения, без требования одинакового оформления.
4. Старое вложение. Откройте сохранённое исходное письмо после переноса и запишите результат. Если путь позволяет снова получить старое время, инструкция клиенту должна учитывать это.
5. Поздняя версия приглашения. После принятой версии 1 доставьте версию 0 с тем же UID. Старое время не должно заменить более новую версию.
6. Повтор действия. Повторите предусмотренную отправку или получение. Проверьте число событий и отсутствие новой клиентской записи либо лишнего напоминания.

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