Booking rollout: a readiness checklistЗапуск записи: проверка готовности
A booking rollout changes where the team checks availability and makes commitments to customers. Its central task is to carry future visits forward accurately and show employees how to handle ordinary appointments and exceptions. Before opening new intake channels, define the release scope, calendar ownership and readiness evidence that can be checked against individual appointments rather than a general interface demonstration.Запуск записи меняет место, где команда проверяет свободное время и даёт обещание клиенту. Главная задача внедрения — перенести будущие визиты без расхождений и показать сотрудникам, как действовать при обычной записи и исключении. До открытия новых каналов определите границы запуска, владельца расписания и доказательства готовности, которые можно проверить по конкретным записям, а не по общей демонстрации интерфейса.
Define scope and ownershipЗафиксируйте границы запуска
The rollout owner lists the services, locations, staff and channels included in the first operating configuration. Assign one schedule authority for each calendar. If an existing service remains alongside it, specify how changes travel between them and who resolves discrepancies. Concurrent editing of two unrelated calendars without that process produces two different answers about the availability of the same employee.Руководитель запуска перечисляет услуги, локации, сотрудников и каналы, которые входят в первую рабочую конфигурацию. Для каждого календаря назначается единственный источник расписания. Если старый сервис остаётся рядом, опишите направление переноса изменений и человека, который разбирает расхождения. Одновременное редактирование двух несвязанных календарей без такого порядка создаёт два разных ответа на вопрос о доступности одного специалиста.
Separate responsibility for data, configuration and operating acceptance. A receptionist verifies future visits, the service lead approves durations and resources, and the implementation owner collects test results. The person configuring a rule should not be its only approver. Establish who can pause intake when a conflict appears and where staff send an urgent question during the operating shift.Разделите ответственность за данные, настройку и рабочую приёмку. Администратор подтверждает будущие визиты, руководитель услуг утверждает длительности и ресурсы, ответственный за внедрение собирает результаты проверок. Человек, меняющий настройку, не должен единолично считать её принятой. Перед запуском согласуйте, кто может остановить приём записей при конфликте и куда команда передаёт срочный вопрос в течение смены.
Prepare services and constraintsПодготовьте услуги и ограничения
For each service, define its name, delivery time, preparation, reset, eligible employees and required resources. Check variants that change duration, such as additional work, consecutive services or travel between locations. Migrating a service name alone does not communicate its restrictions. Keep an unverified variant out of self-service selection until the service owner has resolved it and the complete scenario has been tested.Для каждой услуги заполните название, рабочую длительность, подготовку, завершение, допустимых исполнителей и необходимые ресурсы. Проверьте варианты, которые меняют время: дополнительная работа, последовательность услуг или переход между локациями. Нельзя переносить только название услуги и рассчитывать, что новая система угадает ограничения. Непроверенный вариант временно исключите из самостоятельного выбора до решения владельца услуги и проверки полного сценария.
Location opening hours do not replace employee schedules. Check breaks, absences, rooms and unavailable equipment separately. Illustrative acceptance case: a service takes 50 minutes and needs 10 minutes of reset, so a one-hour interval fits one appointment. A second customer requesting the same resource within that hour should receive another valid arrangement. This is an acceptance requirement, not a claim that validation happens automatically.Рабочие часы локации не заменяют графики сотрудников. Отдельно проверьте перерывы, отсутствие, помещения и недоступное оборудование. Условный пример проверки: услуга занимает 50 минут и требует 10 минут завершения после визита, поэтому часовой интервал вмещает одну такую запись. Второй клиент на тот же ресурс внутри этого часа должен получить другой допустимый вариант. Это приёмочное условие, а не обещание автоматической проверки.
Reconcile future appointmentsСверьте будущие визиты
Agree on a snapshot time for the original calendar and a way to track later changes. Carry across the appointment identifier, time with the location’s time zone, service, customer, employee, resource and current confirmation state. Reconcile payment references and verified amounts separately against available sources. Do not reconstruct cancellation terms from memory or notify every customer again merely because records have moved.Согласуйте момент снимка исходного календаря и способ учёта изменений после него. Переносите идентификатор записи, время с часовым поясом локации, услугу, клиента, исполнителя, ресурс и текущий результат согласования. Платёжные ссылки и подтверждённые суммы сверяйте отдельно по доступным источникам. Не восстанавливайте условия отмены по памяти и не отправляйте повторные подтверждения всем клиентам только из-за технического переноса данных.
Before accepting time conversion, check time zones and daylight-saving cases across the branch, employee and customer views.До приёмки пересчёта времени проверьте часовые пояса и перевод часов в представлениях объекта, сотрудника и клиента.
Compare record identities as well as totals by date, location and state. Equal totals can conceal one missing appointment and one duplicate. An illustrative set contains 12 future records: 8 confirmed, 3 awaiting a response and 1 rescheduled with its history linked. Acceptance requires the same 12 identifiers and their correct states, not merely the number 12 in the replacement system.Сравните не только общее количество записей, но и состав по датам, локациям и статусам. Одинаковые итоги могут скрывать пропущенный визит и лишний дубль. Условный набор содержит 12 будущих записей: 8 подтверждены, 3 ждут ответа, 1 перенесена с сохранённой связью. Приёмка требует те же 12 идентификаторов и те же состояния, а не только число 12 в новой системе.
Data acceptanceПроверка данных
The reviewer records each discrepancy and its source. An unclear appointment receives a decision owner instead of an arbitrary edit made only to match the total count.Сверяющий сотрудник отмечает каждое расхождение и его источник. Непонятная запись получает владельца решения, а не произвольное исправление ради совпадения общего количества.
Process acceptanceПроверка процесса
An operating employee follows the instructions to book, reschedule and cancel. An observer records each outcome, the employee’s questions and any instructions that need revision.Рабочий сотрудник выполняет запись, перенос и отмену по инструкции. Наблюдатель фиксирует результат каждого шага, вопросы исполнителя и необходимость правки инструкции.
Test exceptions before opening intakeПроверьте ошибки до открытия
Test competing requests for one resource, duration changes, employee absence and moves between days. Define the expected result, operator and evidence for each case in advance: calendar state, a linked record or a message outcome. Repeat an interrupted action and check that resubmission has not created another visit. Use approved test contacts for notifications so real customers are not disturbed.Проверяйте конкурентные запросы на один ресурс, изменение длительности, отсутствие сотрудника и перенос между днями. Для каждого теста заранее напишите ожидаемый результат, исполнителя и доказательство: состояние календаря, связанная запись или итог сообщения. Повторите действие после прерывания и убедитесь, что повторная отправка не создала новый визит. Тесты уведомлений проводите на согласованных проверочных контактах, чтобы не тревожить реальных клиентов.
Before opening self-service intake, review accessibility of the customer booking form across all five stages, including error recovery.До открытия самостоятельной записи проверьте доступность клиентской формы записи на всех пяти этапах, включая исправление ошибок.
Check access boundaries and connectivity failures separately. Employees need to know what they can correct and what belongs with a manager. Where external synchronization is included, establish its observed update sequence and delayed-update behavior instead of assuming instant exchange. Treat an unresolved time conflict or unclear payment state as a blocker for the affected release scenario; another successful booking does not resolve it.Отдельно проверьте ограничения прав и недоступность связи. Сотрудник должен понимать, что можно исправить самому, а что передать руководителю. Если внешняя синхронизация предусмотрена, измерьте фактический порядок обновления и поведение при задержке, не предполагая мгновенный обмен. Нерешённый конфликт времени или непонятный статус оплаты фиксируйте как препятствие соответствующему сценарию запуска; успешная запись в другом сценарии эту проблему не закрывает.
Hand the calendar to the teamПередайте расписание команде
At cutover, constrain edits in the old source through the agreed procedure, transfer remaining changes and reconcile again. Staff should know where availability is now confirmed. If intake must be paused, the owner selects the operating source, retains new enquiries and reconciles changes since the snapshot. Returning to an earlier calendar without accounting for newly accepted appointments does not restore an accurate schedule.В момент перехода ограничьте изменения в старом источнике по согласованному порядку, перенесите оставшиеся события и повторите сверку. Команда должна знать, где теперь подтверждать свободное время. Если запуск требуется остановить, руководитель выбирает рабочий источник, сохраняет новые обращения и вручную разбирает изменения после снимка. Возврат к прежнему календарю без переноса новых записей не является восстановлением корректного расписания.
After the first shift, review appointments without outcomes, duplicates, reschedules and undelivered messages. Give each problem an action and owner, then repeat the failed test after correction. Readiness means reconciled schedules and staff who can perform the work independently. Verify SABSUS import, integration and notification behavior in the selected configuration. Add the next intake channel after accepting those same conditions along its own booking path.После первой смены разберите записи без результата, дубли, переносы и недоставленные сообщения. Для каждой проблемы назначьте действие и владельца; затем повторите неудавшийся тест после исправления. Готовность подтверждается согласованным расписанием и самостоятельной работой команды. Возможности импорта, интеграций и уведомлений SABSUS проверяются в выбранной конфигурации. Следующий канал подключайте после приёмки тех же условий на его собственном пути записи.
ImplementationПорядок внедрения · Booking contextВозможности записи
Quick answersКороткие ответы
Are matching appointment totals enough?Достаточно ли совпадения количества записей?
No. Reconcile identities, times, resources, states and changes made after the original snapshot.Нет. Сверьте идентификаторы, время, ресурсы, состояния и изменения после исходного снимка.
Can two calendars remain in use?Можно ли оставить два календаря?
Only with an agreed schedule authority, update process and discrepancy owner. Compatibility needs its own verification.Можно только при согласованном источнике расписания, порядке обмена и владельце расхождений. Совместимость проверяется отдельно.
What should block the release?Что должно остановить запуск?
An unresolved discrepancy that prevents a correct time commitment or an accepted operating scenario.Нерешённое расхождение, которое мешает корректно обещать клиенту время или выполнить принятый сценарий.