A monthly client deliverable needs a record for the month it belongs to. When November starts, an unfinished October review should remain visible beside the new work. Changing its label to November would erase which promise is late.
This guide works through three fictional clients and two service periods. Use the recurring-deliverables worksheet to define period identity, missed runs, skips and due-date changes before building an app. It is a planning exercise with expected results, not a live scheduler or evidence that messages were sent.
Keep each month attached to its promise.
Plain Harbor Studio · Fictional recurring work
Two obligations for one fictional client. Period identity preserves the unfinished October work while November receives its own record; this is a proposed ledger rule.
Open full-size period diagramDefine the month before generating work
Fictional Plain Harbor Studio prepares one website-review pack per client per service month. Each pack contains a dated review and a list of proposed changes. Completing the pack means recording its version and an internal handoff reference; client approval and delivery are separate steps outside this exercise.
All times use UTC. The month is a service period, not a claim about which dates a report measures. The studio has approved only these two periods:
Scroll horizontally to compare all columns.
| Period ID | Included start | Excluded end | Original due time |
|---|---|---|---|
| 2026-10 | Oct 1, 2026, 00:00 UTC | Nov 1, 2026, 00:00 UTC | Oct 5, 2026, 17:00 UTC |
| 2026-11 | Nov 1, 2026, 00:00 UTC | Dec 1, 2026, 00:00 UTC | Nov 5, 2026, 17:00 UTC |
The sample due rule is the fifth calendar day at 17:00, with no weekend or holiday adjustment. A new period becomes eligible at its opening instant. A late run checks every opened period in this approved list and creates any missing records, including older ones. It does not invent earlier contract months or create December work.
Choose your own named timezone, holiday policy, first eligible period and catch-up range. Keep those decisions in the schedule rule. Do not calculate a month by repeatedly adding thirty days, or calculate the due date from whichever day a delayed run happens to execute.
Give each period a stable identity
The studio has three fictional clients:
Scroll horizontally to compare all columns.
| Client ID | Client | Owner | Service ID |
|---|---|---|---|
| C-01 | Cedar Cycles | Maya | site-review |
| C-02 | Fern Books | Luis | site-review |
| C-03 | Harbor Pottery | Alex | site-review |
One work record is identified by workspace + client ID + service ID + period ID. For example, STUDIO-01 / C-03 / site-review / 2026-10 names Harbor Pottery's October review. Use stable IDs; a renamed client still has the same identity.
The run time, due date, current owner and schedule version are attributes, not parts of that identity. Moving a deadline must update the same record. Running the generator twice must find the same record. A second service for the same client would need its own service ID.
Keep the schedule rule separate from generated records. Each generated record captures the rule version used, its original due date and its current due date. A later change to the default rule should not silently rewrite existing work. An approved correction to one record belongs in that record's history.
Preserve a skipped month explicitly
On October 28 at 12:00 UTC, the studio approves skipping Fern Books' November review because the fictional client requested a pause. Store a schedule exception for C-02, site-review, 2026-11, with the reason, approver and approval time.
That exception is not yet a November deliverable record. When November work is generated, it produces one Skipped period record instead of an open task. Keep that record so a retry cannot mistake the month for missing work. A skipped row is not completed work and needs no invented completion evidence.
This sample permits the skip decision before a period record exists. If work has already been created or started, stop for a separate cancellation decision; do not quietly replace it with a skip. Restoring a skipped month also needs an explicit approved change. An ordinary generation retry cannot reopen it.
Work through the delayed November run
The first run on October 1 at 09:00 UTC creates three open October records. Maya completes Cedar Cycles' pack on October 5 at 16:00. Luis completes Fern Books' pack on October 6 at 09:00, sixteen hours after its due time. Alex's Harbor Pottery review stays open while waiting for client materials.
The November run is missed and catches up on November 3 at 09:00. It checks October and November by their period IDs:
Scroll horizontally to compare all columns.
| Result of the November 3 run | Count | Why |
|---|---|---|
| Existing October records retained | 3 | Two completed, one still open |
| New open November records | 2 | Cedar Cycles and Harbor Pottery |
| New skipped November record | 1 | Fern Books' approved exception |
| Total period records afterward | 6 | Five work records plus one skipped-period record |
Retry that run a minute later. The expected answer is zero new records. Repeating it with a different run ID also creates zero. Completed records stay completed, the skip stays skipped, and the late October item keeps its original period and due date.
At the instant November opens, October ends as a period. That boundary does not complete or delete its unfinished deliverable. Show the October item as prior-period work in the current open-work view. Harbor Pottery's October and November rows may both be open; this sample requires someone to plan capacity rather than merging two obligations.
Change a deadline without losing the original
On November 4 at 12:00 UTC, Maya records an approved extension for Cedar Cycles' November review from November 5 at 17:00 to November 9 at 17:00. Keep the original due time, the new due time, the actor, the reason and the change's stable event ID.
The current due date controls whether an open item is overdue. The original due date remains available for a separate comparison. Because this extension was approved before the original deadline, passing November 5 is not itself evidence of a missed promise under the revised policy.
Use a precise boundary: an open item is overdue only when now > current due. At exactly the due instant it is due, with zero elapsed lateness. One second later it is overdue. A completion at or before the current due instant is on time; afterward, record its lateness against the due date in force at completion.
Here is the expected ledger at November 6, 2026, 09:00 UTC:
Scroll horizontally to compare all columns.
| Client / period | State | Original due | Current due | What the review shows |
|---|---|---|---|---|
| C-01 / October | Completed | Oct 5, 17:00 | Oct 5, 17:00 | Completed Oct 5, 16:00; on time |
| C-02 / October | Completed | Oct 5, 17:00 | Oct 5, 17:00 | Completed Oct 6, 09:00; 16 hours late |
| C-03 / October | Open | Oct 5, 17:00 | Oct 5, 17:00 | Prior-period work; overdue |
| C-01 / November | Open | Nov 5, 17:00 | Nov 9, 17:00 | Extension retained; not overdue |
| C-02 / November | Skipped | Nov 5, 17:00 | Nov 5, 17:00 | Approved pause; no work or completion claimed |
| C-03 / November | Open | Nov 5, 17:00 | Nov 5, 17:00 | Overdue by 16 hours |
There are three open items, of which two are overdue. The skipped row contributes to the six period records but not to the five work records, three open items or two completions. State the denominator whenever you show a completion count.
Make retries preserve decisions
Period identity prevents duplicate work. Change identity prevents duplicate history. Give an approved skip, due-date change or completion its own event ID and retain the original event details.
A retry with the same event ID and identical details should make no further change. If that ID arrives with a different due date, evidence reference or reason, stop for review. Do not overwrite the earlier event. In this sample, a distinct second completion or an edit to a completed record also requires review; ordinary commands cannot reopen or revise completed work.
The client-portal guide covers the request, deliverable version and access model. Add period identity to those records rather than creating an unrelated monthly board. Your actual app must still protect each client's records and enforce unique creation when two runs occur together. A spreadsheet formula or a sequential reference calculation does not prove that protection.
Turn the ledger into a build brief
Build a recurring-deliverables planning view from my completed worksheet.
Keep schedule rules, approved exceptions, period records and change history separate.
Use workspace/client/service/period as the unique work identity.
Capture the rule version, original due time and current due time on each record.
Generate only opened, approved periods. Catch up missing periods by identity.
Preserve completed, skipped and open prior-period records on every retry.
Record a skip without claiming completion. Keep each approved due-date change.
Reject conflicting reuse of an event ID instead of overwriting history.
Use fictional clients and internal evidence labels. Compare the worksheet cases.
Test simultaneous runs and return visits in the actual app. Report observed results.
Do not activate schedules, send client messages or connect billing in this first pass.
Put your policy and expected ledger into an app brief. Overskill's scheduling help is a setup reference for the next stage; the worksheet does not verify a particular scheduler, account limit, failure alert or delivery action. Test the chosen implementation and use the launch checklist before relying on it for client work.