Історія записів фіксує кожну значущу дію над записом — хто його створив, хто переніс чи скасував, коли надсилалися нагадування, підтвердження RSVP, позначки про відвідуваність — і показує цю хронологію власникам та адміністраторам. Використовуйте її, коли клієнт скаржиться, що не отримав нагадування, коли вам потрібно зʼясувати, хто скасував бронювання, або коли ви розбираєте випадок неявки.
1. Що саме фіксується
Кожен запис в історії запису — це одна з фіксованого переліку дій:
- Запис створено. Запис було створено. Фіксується канал джерела (публічна сторінка бронювання, вбудований віджет, API, MCP, чат-агент або оператор на сторінці розкладу).
- Підтверджено електронною поштою. Клієнт прийняв RSVP запрошення в календар.
- Відхилено електронною поштою. Клієнт відхилив RSVP запрошення в календар.
- Перенесено. Змінено час початку, учасника команди або необхідний ресурс. У записі показано попереднє та нове значення.
- Скасовано. Запис було скасовано. Причина фіксується, якщо ініціатор скасування її вказав.
- Нагадування надіслано. Надіслано нагадування — або автоматичним cron-завданням, або вручну оператором.
- Позначено як розпочате / Позначено як завершене. Дії оператора з відстеження в день запису.
- Позначено відвідуваність / Відвідуваність скинуто. Оператор позначив присутність чи неявку або скасував попередню позначку.
Записи про перенесення, скасування та відвідуваність також показують невелике порівняння «було → стало» для змінених полів під реченням про дію, тож вам не доведеться гадати, що саме змінилося.
2. Кожен запис показує, хто виконав дію
Кожен запис історії належить до одного з трьох типів виконавців. Анонімних записів не буває.
- Користувач. Автентифікований власник, адміністратор або учасник персоналу, що діє з панелі або сторінки розкладу. У записі відображається імʼя користувача станом на момент виконання дії — подальші перейменування не змінюють історії.
- Клієнт. Клієнт запису, що діє через RSVP в електронному листі, посилання на перенесення чи скасування з листа-підтвердження або публічну сторінку керування. У записі відображається «Клієнт (email)», тож ви можете перевірити особу навіть тоді, коли імʼя не було збережено.
- Система. Автоматизований процес. У записі відображається назва завдання (наприклад, cron:sms-reminders, cron:auto-reminders), щоб ви могли розрізняти різні фонові завдання.
3. Відкриття історії одного запису
На сторінці розкладу або в порядку денному на панелі натисніть на запис, щоб відкрити спливаюче вікно з деталями. Якщо в запису є хоча б один елемент історії, у заголовку спливаючого вікна зʼявляється невелике посилання «Історія ›». (Нові записи без жодної зафіксованої дії посилання не показують — немає сенсу відкривати порожню хронологію.)
Натискання «Історія ›» відкриває ширше спливаюче вікно поверх деталей запису з хронологією, де найновіші події йдуть першими. Закриття цього ширшого вікна (кнопкою закриття, клавішею Escape або кліком по фону) повертає вас до деталей запису — ваша позиція не втрачається.
4. Перегляд історії по всій організації
Відкрийте сторінку «Історія» в меню користувача, щоб побачити повносторінковий перегляд із фільтрами для всіх зафіксованих змін по всіх записах організації. Ця сторінка існує саме тому, що скасовані та видалені записи зникають із порядку денного — без цього перегляду ви не зможете відкрити їхнє спливаюче вікно, щоб прочитати історію.
Фільтруйте за дією, фрагментом email клієнта, фрагментом імені виконавця та діапазоном дат. Кожен запис посилається на відповідний запис на прийом, тож ви можете перейти з огляду по організації до деталей конкретного запису.
5. Хто має доступ до історії
- Власники та адміністратори бачать історію кожного запису в організації на обох поверхнях — у спливаючому вікні окремого запису та на сторінці по всій організації.
- Роль «персонал» (учасник) НЕ бачить історії. Посилання «Історія ›» приховане у спливаючому вікні з деталями запису, а сторінка «Історія» в меню користувача недоступна з облікового запису персоналу.
- Жодна роль ніколи не бачить історії записів іншої організації.
Якщо учаснику персоналу потрібна відповідь з журналу аудиту, він звертається до власника або адміністратора, щоб ті відкрили історію за нього.
6. Чого історія НЕ робить
- Клієнти ніколи не бачать історії. Її немає ані в листах-підтвердженнях, ані на сторінці керування, ані на жодній публічній поверхні.
- Історія не доступна через публічний API чи вебхуки. Це журнал аудиту для операторів, а не поверхня для розробників.
- Історія не діє заднім числом. Записи, що існували до запуску цієї функції, матимуть порожню хронологію до наступної зафіксованої дії; починаючи з цього моменту журнал заповнюється у звичайному режимі.
- Скасування запису не видаляє його історії. Журнал зберігається, тож ви можете розібрати причини скасування пост-фактум.
7. Вимоги до тарифу
Історія записів доступна на всіх тарифах, зокрема на безкоштовному. Для цієї функції немає обмежень за тарифом.
8. Підсумок
Натисніть на запис, натисніть «Історія ›», перегляньте хронологію. Для видалених чи скасованих записів, яких уже немає в порядку денному, скористайтеся сторінкою «Історія» в меню користувача, щоб їх знайти. Власники та адміністратори бачать повну картину; персонал ескалює запит, коли потребує відповіді з журналу аудиту.