A household has a regular walking arrangement on selected weekdays. One week they are away, another week they request a different time, and a walker needs cover for one visit. If staff edit copies of last week's calendar, those exceptions can easily become permanent changes or duplicate visits.
A recurring schedule needs two layers: the standing arrangement and the individual occurrences it produces. The arrangement describes the rule. Each visit records what is actually planned and what happened. Keeping them separate makes a one-off exception possible without rewriting the agreement or regenerating work already completed.
Define the standing arrangement precisely
Record the household, relevant pets, local time zone, recurrence rule and effective period. Include the service details and access instructions through appropriate linked records. A phrase such as every weekday is not enough unless the business has decided how holidays and closures affect it.
Keep assignment policy separate from recurrence. The household may have a usual walker, but cover can change for one occurrence. If every generated visit copies an unchangeable name from the series, staff will work around the software whenever someone is unavailable.
Make the arrangement's current state visible: proposed, active, paused or ended according to the business's workflow. A paused arrangement should preserve its history and expected resumption rather than disappearing from the customer record.
Generate visits with stable identities
Each occurrence needs an identifier derived from the arrangement and its intended position in the schedule, or another stable generation key. Running the scheduler again should find the existing visit instead of creating another one for the same occurrence.
Store the rule version that produced the visit. If the standing arrangement changes, staff can see which future visits were generated under the old terms and decide how to update them. Completed visits should retain their original context.
Use a defined planning horizon rather than generating an unlimited future. Extend it through a repeatable job and monitor whether generation succeeds. An empty calendar can mean no work is due or that the scheduler failed; the operator needs to distinguish those cases.
A one-off change is an exception record
When a customer moves one visit, attach the change to that occurrence. Preserve the original scheduled time and the approved replacement. The next ordinary occurrence should still follow the standing arrangement unless the customer explicitly requests a series change.
For a cancellation, record the outcome and any policy handling separately from deleting the visit. Deleting it can cause the generator to recreate it later because the system no longer knows the occurrence was deliberately cancelled.
Make the scope of an edit clear in the interface: this visit, this and later visits or the standing arrangement from an effective date. Do not hide that distinction behind a vague save button. Staff should be able to preview which future visits will change.
Holidays and pauses need boundaries
A pause should identify the affected period and whether the customer expects the arrangement to resume automatically. Show the first expected visit after the pause so both staff and customer can catch a misunderstanding before that day arrives.
If an organisation observes closure dates, decide whether visits are cancelled, moved or held for review. A holiday calendar should not silently make that business decision. Preserve the rule used and any approved exception for the household.
For a pause entered after some visits are already assigned, notify the affected walker and track acknowledgement where the operation requires it. Updating the office calendar does not establish that an offline mobile device has received the cancellation.
Cover changes more than the name
A replacement walker needs the approved information and access required for that specific visit. Check eligibility and assignment conflicts before confirmation. Do not publish sensitive access details to everyone who receives a general cover offer.
Keep access instructions current and appropriately restricted. If a household changes a key arrangement or contact route, the cover workflow should surface the change to the accepted replacement. An old downloaded note should not be treated as permanently authoritative.
Record the transfer of any physical access item if that is part of the operation. A cover assignment can be accepted while the handover is still pending. Showing that dependency helps the coordinator avoid confusing willingness to attend with readiness to perform the visit.
Completion should follow the occurrence
Record the visit outcome against the occurrence identifier, including a cancellation or inability to gain access. A late mobile submission should update the correct visit even if the next week's schedule has already been generated.
If staff discover that a visit was recorded against the wrong day, provide a reviewed correction path. Do not move timestamps until the report appears plausible. Preserve the original submission and the reason for reassignment so customer reporting and any entitlement records remain traceable.
Financial or prepaid-session handling should consume the approved visit outcome rather than guessing from the presence of a calendar entry. Scheduled does not necessarily mean delivered, and a cancellation policy may require a separate decision.
Test a month containing real exceptions
Create a test arrangement with a pause, a one-off time change, a cover visit and a permanent change starting midmonth. Run generation repeatedly and confirm that no occurrence duplicates or reappears after cancellation.
Then reconnect a device holding an old assignment after the office has withdrawn it. The system should explain the current state while retaining any useful submitted information for review. A dependable recurring schedule is one that makes the exceptional week understandable without damaging the ordinary weeks around it.