04 Systems Lab Demonstration
Working systems, shown with their workings.
The Lab shows how proposed workflows behave on example data. Everything here runs on synthetic data describing a fictional business. Simulation is labelled simulation, in the headings and in the numbers, and nothing in this room is a client result.
Invoice follow-up is one example in the operations toolbox. The production and inventory prototype is a separate local synthetic demonstration.
System 01
Invoice follow-up, operated end to end.
This demonstration explores a common billing task: deciding which unpaid invoices need attention and preparing a follow-up list. The system reads the invoice register, stages every unpaid balance by how late it is, prepares the appropriate follow-up as a draft, and stops. In this simulation, nothing is sent. Any real deployment requires owner review and current payment checks.
This browser simulation demonstrates invoice classification, partial balances and repeat-run handling. Operate it: open the Register, mark INV-2409 paid, run the cycle again and open Drafts. Its simulated draft is removed from the active list and the totals change. In the current workflow code, old email drafts are flagged for the owner to inspect and remove manually. The simulation does not control Gmail or prevent manual sending.
The register: Danforth Mechanical Services, synthetic
Thirteen synthetic invoices for a fictional Toronto mechanical services business, invented for this demonstration. The run date is fixed at November 7, 2026, the date of the verified test run, so the figures reconcile to the dollar. Use Mark paid to record a payment, exactly as the business's own register would change between weekly runs, then run the cycle again.
The register has changed since the last run. Run the weekly cycle to apply the change: affected drafts are withdrawn or restored, and no draft is ever duplicated.
| Invoice | Client | Due | Amount | Paid | Balance | Status | Record a payment |
|---|
All names, addresses, and figures on this page are synthetic. The .example addresses use a reserved example domain and are not delivery addresses.
Classification, computed live from the register
Every invoice is classified by the same rules the tested system runs: paid and disputed invoices are suppressed before anything else is considered; the rest are staged by days overdue (Stage 0 at the due date or within three days ahead, Stage 1 at one to seven days, Stage 2 at eight to twenty-one, Stage 3 at twenty-two or more). An actionable invoice with no email address becomes a phone task, never a draft. This table recomputes the moment the register changes.
| Invoice | Client | Outcome under the rules |
|---|
Suppression rules, applied before any draft exists
What a follow-up system refuses to do matters more than what it does. A paid invoice is never chased. A disputed invoice is never chased: the dispute is settled by a person first. A partial payment is chased for the true remaining balance only, and the draft says so in its own text.
| Invoice | Client | Balance kept out | Reason |
|---|
Drafts prepared for the owner, and nothing else
The register changed after the last run. Run the weekly cycle again: a draft whose invoice has been paid is withdrawn before approval, and the totals move by exactly that invoice's balance.
Each draft below was generated from the register by the stage templates, the same templates the tested system uses, in the business's own details. Select one to read it in full. These are drafts in a list on a web page: the system that produces them has no ability to send anything, and that inability is a design feature.
The owner approval gate, and the journal behind it
Every run ends at a gate, not an outbox. The owner receives one summary, reads it, approves or edits each draft in their own mailbox, and makes the phone calls. There is deliberately no send control here, and none in the system: approval is the product's centre of gravity, because the owner keeps the judgment and the customer relationship.
Idempotency journal · one key per completed draft
A key joins the invoice number, the stage, and the balance in cents. A rerun finds the key and skips the work, so running the cycle twice can never produce two drafts for the same balance. A genuine balance change makes a new key, which is correct: it is new work.
Totals and the run log
Run log · appended every cycle, never rewritten
The figures below are the tested reference implementation's own results on this same register, verified in its test report, and reproduced here exactly. The operating demonstration above runs the same rules in your browser and reconciles with them. Eleven invoices carried unpaid balances totalling $14,525; eight balances totalling $11,350 were past due at the run date, including one disputed invoice of $2,275.
| Measure (simulated) | Result | Note |
|---|---|---|
| Drafts prepared for owner approval | 8 | Covering balances of $10,090 |
| Overdue money placed under active follow-up | $9,075 | The disputed $2,275 is deliberately excluded |
| Phone tasks created | 3 | One with no email address, two at the final-notice stage |
| Follow-ups correctly not prepared | 3 | Two already paid, one disputed |
| Owner time per weekly cycle, manual process | 154 min | Estimate on stated assumptions: 4 min per invoice check, 10 min per written follow-up, calls in both |
| Owner time per weekly cycle, with the system | 52 min | Estimate: 6 min reading the summary, 2 min per draft approval, same calls |
| Simulated difference | 102 min | About two thirds of the follow-up administration, roughly 7.4 hours a month. An estimate, not a measurement |
What this simulation does not show: that customers pay faster. The dataset is static, so no payment behaviour changes inside it. Whether follow-up discipline shortens the wait for payment at a real business is measured during a real engagement, against that business's own baseline, over sixty days.
Further workflow concepts
Inquiry intake and follow-up.
The second system in the toolkit addresses the missed inquiry: messages arriving by form, email, and phone, answered late or not at all, with no single record of who asked what. The design mirrors the first system's discipline: capture everything into one queue, classify it, draft responses for approval, and flag whatever waits too long.
Status: demonstration in development. Inquiry intake remains a development concept here. No live intake automation or client result is presented on this page.
What remains untested, stated plainly
- The local reference and Google Apps Script code have offline tests. The revised Google script has not yet been executed and verified inside the intended Google account. A Make scenario has not been built.
- Real ledger reconciliation. The synthetic data is clean except where testing deliberately dirtied it. A real engagement begins by reconciling the client's actual list, and that work is untested at scale.
- Real-world delivery: sending behaviour, deliverability, customer response, and any change in how fast real invoices get paid. None of that exists yet, because no client engagement has taken place.
- Inquiry intake has not been delivered to, or measured at, a real business in the evidence presented here.