Terminautomatik ·
Treat rescheduling as its own workflow
A change affects more than the time: resources, confirmations and ownership need to stay aligned.
Separate the original and requested states
For a rescheduling request, first record the existing appointment and then the requested outcome. Which service stays the same, what time should change and which person or resource is needed? Separating these states prevents a request from being mistaken for a completed change. The existing appointment should remain clearly identifiable until the agreed decision process has finished.
Check the alternative completely
Review the proposed replacement using the same rules as a new request. Include duration, buffers, opening hours and required resources. If the service changes as well, the previous duration may no longer apply. An apparently free time slot is therefore not enough to confirm the change. Keep unresolved conditions visible rather than silently assuming that they have been satisfied.
Assign a responsible person
Decide who reviews the request and who may confirm the change. Explain how a colleague takes over when necessary. The internal note should contain the reason, proposed replacement and processing status. Avoid several parallel lists where the same request can be handled independently. A shared status makes the handover between team members easier to follow.
Rehearse failure cases
Test an alternative that has become occupied and a request that cannot be clearly matched to the original appointment. Also try a second change arriving while the first is still being processed. Which information now applies, and who updates the person making the request? These examples expose missing rules before a connection begins performing real changes.
Check completion and communication
After a confirmed reschedule, the authoritative appointment and the response must show the same outcome. Check whether earlier holds or internal tasks are still open. A local simulation can illustrate these states but does not change a calendar. A later integration needs explicit handling for failed steps so the team can recognise when personal follow-up is required.