Scheduled Suspension

Background

Temporary suspension pauses a contract for a period before service resumes. The start date could only be today, so operators had to change the contract status on the day of the pause, even when the date was already known. Weekend starts required the same manual action.

Suspensions for non-payment or temporary closures involved accounting, CX, and operations. Without reservations, operators had to remember the start date and manually align the contract status and collection schedule that day.

A setting split out of contract status

Accepting a future date was not enough. Marking a contract suspended today when the pause starts next week could stop collections that should still run. I separated the reservation from the current contract status, with a scheduled job applying the transition on the start date.

Instead of selecting suspension directly in the status field, a dedicated setting captures whether to use it, the period, non-payment status, and reason. Keeping only one start/end pair on the contract would overwrite earlier pauses as service stopped and resumed, so I separated the history for later billing checks.

I led the planning and worked with accounting, CX, and operations to define reservation conditions and exceptions. I checked the effects on dates, contract status, billing, work shown in the driver app, and re-contracts, then agreed on the handling rules with designers and developers and followed through with QA.

Start-date & state-transition rules

Saving a reservation and stopping service are separate events. A future reservation should not change the current contract state.

A contract can change before its reserved date arrives, so saving a reservation does not settle its future state. A provisional contract has not started service: it stays provisional when the pause date arrives and is evaluated again when activated. An ended contract is no longer something to pause and resume, so it is excluded from configuration.

Changing contract status during collection also caused problems. In one issue, suspending a contract during a schedule containing completed work made its work location inaccessible in the driver app. I blocked immediate suspension and release while a schedule was in progress, and verified that work before the pause could still be performed.

Re-contracts and renewals may inherit a past start date. This is distinct from allowing a user to enter a new past date. Only present/future history is editable, past history is protected, and every change is logged.

Billing-aggregation conflicts

Suspension dates are part of the basis for a billed amount. Deleting or extending them after an invoice is issued can make the recorded operating days disagree with the amount already charged. I blocked changes affecting issued invoices until the affected invoice is removed and the history can be corrected.

An existing invoice should not block every future reservation. I compared the old and new suspension dates with each invoice’s billing period and restricted edits only when an already-billed period would change. Unbilled periods remain adjustable.

Entering a new past date changes the basis of earlier collections and billing. But refusing to carry over the start date of an ongoing pause could interrupt it when the contract changes. Normal input is limited to today or later, while a date inherited from the previous contract can be retained.

Suspension reasons and billing rules

Operations did not bill suspension periods, but a “continue settlement” option remained in the interface and caused incorrect charges. Billing was aligned to the pause dates, while non-payment remained a separate classification for receivables management.

Accounting needed to know whether non-payment caused a pause, not whether to keep charging during it. I removed the unused billing choice and retained non-payment versus other reasons for receivables management. Base and subscription plans prorate by excluding suspended periods for both reasons.

When a pause crosses months, each invoice must deduct only the dates within its own billing period. The example excludes 15 days from October without deducting November’s days there, so the charge reflects the period when service was provided.

Connect the driver app, re-contracts, and renewals

A reservation must also affect the work list drivers see. Re-contracting or renewing during a pause must not restart collection.

Losing a pause setting during re-contracting can restart dispatch to a site that should still be suspended. Copying past history, however, mixes the old contract’s dates into the new contract’s billing basis. I therefore carried forward applicable settings while creating separate history for the new contract. QA also caught missing scheduled-pause data and unspecified end dates during copying, which were corrected.

• Driver app: schedules before the suspension start still run; those after it stop appearing
• Re-contract: the suspension setting is copied, but not its past history — a fresh one is created
• Renewal: suspension is decided at the moment the contract goes active, creating a new history entry
• A warning dialog confirms with the user when a re-contract/renewal carries a suspension

Replaced same-day manual work with advance reservations

Operators can register the dates in advance and have the pause applied automatically, instead of waiting to change the status that day. Collections before the pause continue, and the suspension period and billing rules carry into re-contracts and renewals, reducing the separate checks and adjustments teams had to make.

After launch, operational records showed that weekend and holiday work fell from 1.6% to 1.0% of all suspension activity.

Based on suspension creation, update, and cancellation records. The observation windows cover approximately ten months before and two months after the change, so the comparison uses the share of total activity rather than raw counts.