Key Takeaways: Technology and Systems
The one thing
A system is not software.
It is the mechanism by which a finding becomes a change — and a planner without one has a tenth wedding that is their first wedding, ten times.
The ten claims
1. Five reasons a written finding produces no change: found and fixed are the same column · the change lands in the wrong artefact · the artefact is not opened before the next event · it is filed under the wrong heading · and there are too many.
2. Four components — artefacts, triggers, conventions, a closing loop — and none of them is software. A platform without the four is an empty container with a subscription.
3. A system that lives in one person's head is expertise. The test: could somebody competent run your next event from your documents, without you?
4. Intention is not a trigger. Time-based and event-based are reliable; threshold-based are the most valuable and almost nobody has them — guest count moves by more than 10 → re-run catering, floor plan, seating, transport, guarantee.
5. Ten triggers, applied from a template at signing, take four minutes per event — and every one is a finding from an earlier chapter that would otherwise depend on somebody remembering.
6. Choose the stack by function, not by product. Function 8 — the finding log, the venue file, the template library — is free and almost universally absent.
7. The platform question nobody asks: what does it not do that I will therefore stop doing? And run one real event in parallel before deciding.
8. Write the unit next to the number. 89 — seated dinner @ 12 sq ft. Four separate errors in this book were the same error, and four words fix all of them.
9. The second column is the whole mechanism — found, artefact, owner, due, closed. "Be more careful" cannot be closed; "add a flag to the budget template" can. And a log of unclosed findings is worse than no log, because it documents that you knew.
10. A planner will implement three or four changes a season. So the audit is a ranking plus an explicit decision about what does not get done — a change you decided not to make is a decision; a change you forgot is a finding that died.
Threshold concepts
🚪 A system is not software. It is the mechanism by which a finding becomes a change.
🚪 A trigger is a moment at which a document must be opened. Intention is not a trigger.
🚪 A template used unchanged for four years is a snapshot of what you knew in year one.
🚪 A planner cannot implement twenty-two changes, and pretending otherwise is how none of them happen.
The artefacts
Enquiry questionnaire · proposal · contract · budget sheet (with an unallocated flag) · timeline · run sheet · guest list (dietary, access, and an alone column) · vendor tracker and brief · production book · emergency page · debrief and finding log · and the venue file.
And two records nobody keeps: the correspondence log — one line per decision, date, person, where the evidence is — and the decision record, which captures why, for the six decisions per wedding that somebody will ask about later.
The trigger set
−12m venue file, save-the-date access text · −9m category-D check, permissions granted to whom · −6m the access asking, sent by a family member; rain plan · −3m timeline, first production meeting · −8w decision protocol, insurance certificates checked against dates · −2w read-through, final numbers once on the Thursday · −72h emergency page, four-weather review · +2d incident notes, thank-yous, finding log · +2w debrief, reconciliation, systems changes made · +12m the query nobody runs.
Data
You are holding sensitive personal data. Dietary requirements are health information · access lists are disability information · the emergency page names individuals.
Collect the minimum · store it in one controlled place · share only what a vendor needs · delete on a defined schedule · say what you do with it.
And keep the emergency page separate from the run sheet — which Chapter 26 recommended for operational reasons and §39.7 now also requires for data reasons.
What this chapter added
Rasheeda Iyaloo kept a finding log for three years. Ninety-one entries, never missed one, genuinely good. Four documents changed.
"Writing a really good entry felt like dealing with it. The better I described the problem, the more finished it felt — and the ones I wrote best are the ones I did least about."
Four of the eighty-seven, costed: twenty-one recurrences and $3,000–4,500, every one correctly identified in writing the first time it happened.
And the diagnosis of the four that did change: three happened because the artefact was already open, one because somebody else asked, and none because it was on the log. So a system's job is to manufacture both conditions — a scheduled moment with the artefacts open, and an external obligation.
Her retro-processing found 58 assignable, 33 not, 12 already fixed, 46 still worth doing — and she chose five. "Before, I had ninety-one things I felt vaguely bad about. It's the same information. But one of them is a decision and the other one was a debt."
And the book audited itself. Twenty-two systems changes across thirty-eight chapters, totalled for the first time — which is the same failure it has spent the book diagnosing.
Nineteen hours of implementation, which sounds achievable and is exactly why it fails: nineteen hours of unbilled, unurgent, invisible work competing against a season. The hours are not the constraint. The absence of anything that forces them is.
Four chosen: the unit next to the number · the finding log's second column · the venue file · the attribution column. And #2 wins on a different basis from the others — it produces no visible value at all and it is what makes the next four years possible.
Eighteen deferred, with dates and triggers — including the ceremony-hour planning sheet, arguably Part VI's most consequential finding, because a three-hour artefact built in a hurried February is worse than none.
And a year later the list is twenty-one, not zero. Four classes of error stopped happening. Ten items have dates. Nine new findings arrived, which is what a practice paying attention produces.
The number of open findings is not the score. The rate of closure is.
What is still open
| Goes to | |
|---|---|
| The ceremony-hour planning sheet, deferred with a date | Ch.40 |
| Whether a solo practitioner can run a system at all, or whether this is advice written for organisations | Exercise E.3, Ch.41 |
| A log where a third of rows can never close will train you to ignore the column — it needs a noted, no action category | Ch.40 |
| The reader's own version of the twenty-two, with their artefacts and their season's findings | Ch.40 |
Spaced review
From Chapter 26: the production book was the artefact; this chapter builds the conventions and triggers around it — and closes one thing directly: the emergency page is distributed separately, on paper, to five people.
From Chapter 30: §39.8 operationalises "a finding gets an owner and a due date, or it is not logged" — and the load-bearing field is the artefact, because "be more careful with times" cannot be closed.
From Chapter 36: buy the platform fourth, because it encodes a workflow into a business that does not have one and hides the seams. §39.4 adds the question Chapter 36 lacked.
From Chapter 34: the venue file closes the corridor-conversation finding — a venue's institutional knowledge lives in individuals and a planner benefits from it only by accident.
From Chapter 5: the master variable finally gets a mechanism. A threshold trigger.
Before Part IX
Part VIII ends here.
Chapter 40 is the capstone — the complete wedding, start to finish, stress-tested against a scenario designed to break everything this book has built.
And Chapter 41 asks the question none of Part VIII's arithmetic has touched: what this work costs the person doing it, and how long anybody can do it.