Chapter 39: Technology and Systems — Software, CRM, and Going Digital

"It's on the list." — the last thing anybody ever says about it

Chapter Overview

Five things this book found, wrote down, and never fixed.

Every one of those was noticed by a competent person, written down correctly, and produced no change.

And the mechanism is identical in all five: caught and fixed were the same column.

This chapter is about the machinery that turns the second column into the third.

And it opens by refusing the thing the title implies. A system is not software. You can run an excellent practice on a spreadsheet and a notebook, and you can run a chaotic one on a $200-a-month platform — and the difference between them has almost nothing to do with the tools.

A system is the mechanism by which a finding becomes a change.

In this chapter, you will learn to:

• Explain why a written finding does not become a change, and fix it
• Map a stack by function, not by product
• Evaluate a platform against your actual workflow
• Build a document architecture that survives a busy September
• Handle the sensitive data you are holding, which is more than you think
• Become replaceable on a task and irreplaceable on judgment
• Recognise where technology makes things worse

🏃 Fast Track: Read §39.1–39.2 (why findings die), §39.8 (the second column), and §39.10 (where tech makes it worse) in full. Then do B.1, B.7, and D.3.

📖 Standard: Everything.

🔬 Deep Dive: case-study-02.md takes every systems change this book has accumulated across thirty-eight chapters — there are twenty-two — and finds that no planner can implement twenty-two things.

39.1 Why Findings Die

🚪 Threshold Concept: a system is not software. It is the mechanism by which a finding becomes a change

Chapter 30 established that a finding which does not change a document, a template, or a checklist has not been learned — it has been noticed, felt, and lost.

This chapter is about why that happens to competent people who write things down.

⚡ Quick Reference: the five reasons a written finding produces no change

		The fix
1. Found and fixed are the same column	A row containing a finding looks handled	Two columns, an owner, and a date. §39.8
2. The change lands in the wrong artefact	"Ask about access earlier" is a note; the RSVP template is the artefact	Name the document the change goes into
3. The artefact is not opened before the next event	A brilliant template nobody reaches for	Attach it to a trigger, not to intention
4. The finding was filed under the wrong heading	Chapter 35's four lonely travellers were a carbon finding that was a guest-experience one	Log it where it belongs, not where it was found
5. There are too many	The honest one. Thirty-eight chapters produced twenty-two changes	§39.11's capacity problem

Reasons 1 and 3 account for most of it. Reason 5 is the one nobody admits.

🎤 From the Field

I kept a beautiful finding log for three years.

Ninety-one entries. Genuinely good observations, written the night of, exactly as this book recommends.

I changed four documents in three years.

The log was doing something and it was not what I thought. It was letting me feel that I had dealt with something by describing it well — and the better the entry, the more finished it felt.

39.2 What a System Actually Is

⚡ Quick Reference: four components, and only one of them is software

		Example
1. Artefacts	The documents that carry the knowledge	The run sheet, the budget sheet, the RSVP template, the venue file
2. Triggers	The moments at which an artefact must be opened	−6 months → send the access text. A trigger, not a reminder to be diligent
3. Conventions	How things are named, stored, and versioned	§39.5
4. A closing loop	The mechanism by which a finding changes an artefact	§39.8

Software is a delivery mechanism for the four. It is not a fifth.

Which is why Chapter 36 said buy the platform fourth: a platform without artefacts, triggers, conventions, and a loop is an empty container with a subscription.

⚠️ Common Pitfall: the system that lives in one person's head

A planner who knows exactly how everything works, in what order, with what to watch for, has expertise and does not have a system.

The test is simple and unpleasant: could somebody competent run your next event from your documents, without you?

If the answer is no, then a broken ankle is a business failure — and Chapter 27's handoff already established that a solo planner whose absence means no planner has sold something they cannot always deliver.

39.2a Triggers

The component people leave out, and the reason good artefacts sit unopened.

🚪 A trigger is a moment at which a document must be opened. Intention is not a trigger

"Send the access text at −6 months" is a note.

"−6 months" as a recurring, dated task attached to every event, that appears without being remembered, is a trigger.

The difference is who is doing the remembering.

⚡ Quick Reference: the four kinds, and only one of them is reliable

		Reliability
Time-based	−12 months, −6, −3, −8 weeks, −2 weeks, −72 hours, +2 days, +12 months	High. Set once per event, from a template
Event-based	When the venue is signed → open the venue file	High, and harder to automate
Threshold-based	When the guest count moves by more than 10 → re-run the catering and the floor plan	Medium, and the most valuable
Intention-based	"I must remember to ask about access"	Zero

The threshold trigger is the one almost nobody has and it is where Chapter 5's master variable actually gets managed — because a guest count that drifts from 100 to 118 across nine months never triggers anything, and it changes the catering, the floor plan, the seating, the transport, and the guarantee.

✅ Best Practice: the trigger set, applied to every event on signing

−12 months	Venue file opened · save-the-date with the access text (Ch.29)
−9 months	Vendor category D check (Ch.28) · permissions: granted to whom, extendable?
−6 months	The access asking, sent by a family member (Ch.29) · rain plan drafted (Ch.28)
−3 months	Timeline built (Ch.25) · first production meeting if the build is large (Ch.34)
−8 weeks	Decision protocol (Ch.27) · insurance certificates checked against dates (Ch.9)
−2 weeks	Production book read-through (Ch.26) · final numbers, once, on the Thursday (Ch.30)
−72 hours	Emergency page distributed · weather review, all four kinds (Ch.28)
+2 days	Incident notes, thank-yous, finding log written up (Ch.30)
+2 weeks	Debrief, reconciliation, and the systems changes made (Ch.30, §39.8)
+12 months	The query nobody runs (Ch.32)

Ten triggers. Applied from a template at signing, to every event, forever.

It takes about four minutes per event and it is the single highest-return item in this chapter, because every one of those rows is a finding from an earlier chapter that would otherwise depend on somebody remembering.

39.3 The Stack, by Function

Choose functions first and products second, because functions are stable and products are not.

⚡ Quick Reference: nine functions

		Note
1. Money	Invoicing, payments, bookkeeping, reconciliation	Ch.36's first purchase. Non-negotiable
2. Agreements	Contracts, e-signature, storage, retrieval
3. Files	Cloud storage with a convention	The convention matters more than the product
4. Time	Calendar, tasks, triggers	Triggers are the point. §39.2
5. Clients	Enquiries, pipeline, communication history, attribution	Ch.38's column
6. Planning artefacts	Budget, timeline, run sheet, guest list, vendor tracker, floor plan	Parts II–VI built all of these
7. Design	Proposals, floor plans, signage, mood boards
8. Knowledge	The finding log, the venue file, the template library	The one nobody has and the one this chapter is about
9. Comms	Email, messaging, and whatever your clients actually use

Functions 1–4 are about $60 a month and are non-negotiable (Chapter 36). Function 8 is free and almost universally absent.

💰 Run the Numbers: what a stack actually costs

	Monthly
Accounting and invoicing	$32
E-signature	$22
Cloud storage	$12
Calendar and tasks	$0–10
Planning platform (if any)	$45–120
Design tools	$0–55
Email and domain	$8
TOTAL, minimal	$74–84
TOTAL, with a platform and design	$174–259

📜 Tier 3 — illustrative; prices move constantly.

Against Chapter 36's $12,100 of annual fixed costs, a full stack at $250 a month is $3,000 — a quarter of everything.

Which makes function 8, at $0, the best-value line in the table by an enormous margin.

39.4 Evaluating a Platform

Against your workflow, not against its feature list.

⚡ Quick Reference: the six questions

1. What are the three things I do most, and does it do them faster?	Not "can it do them." Faster
2. What does it force me to do differently, and is that better?	A platform encodes a workflow. Sometimes theirs is better than yours and you should know which
3. What happens to my data if I leave?	Export format, and try it before committing. This is the question people ask last and should ask second
4. Does the client-facing part improve their experience or mine?	Portals frequently improve the planner's life and complicate the client's
5. What does it not do that I will therefore stop doing?	The most important question and nobody asks it
6. Can I run one real event in it, in parallel, before deciding?	If the answer is no, the answer is no

Question 5 is the one that matters. A platform without a floor-plan tool means you will stop drawing floor plans, and Chapter 11 established what that costs.

⚠️ Common Pitfall: buying before you have a workflow

Chapter 36 said buy the platform fourth, and this is the reason.

A platform bought in month one encodes somebody else's workflow into a business that does not have one, and it hides the seams: a spreadsheet you built is transparent, and when a column turns out to be wrong you know what to change.

Run three or four events on documents you made. Then buy — and you will choose differently.

✅ Best Practice: the parallel event

Run one real event in the new system alongside your existing one.

It is genuinely double work for six weeks and it is the only way to answer questions 1, 2, and 5 honestly — because a demo answers can it, and a real event answers does it, for me, in September.

And most planners who do this discover the same two things: the migration is worse than promised, and one specific daily task is dramatically better. Whether the second is worth the first is a real question and cannot be answered from a website.

39.5 Document Architecture

Unglamorous, free, and it is what actually survives a busy September.

✅ Best Practice: the four conventions

1. One place	Every document for an event lives in one folder tree	The commonest failure is a run sheet that exists in email, in a platform, and on a desktop
2. A naming convention	2026-09-12_Reyes-Whitfield_RunSheet_v4.pdf	Date first, so things sort. Version last, so the current one is obvious
3. One current version	Old versions in an _archive folder, immediately	Chapter 26's whole read-through problem
4. The same tree, every event	Identical folder structure, always	So that "where is the vendor tracker" has one answer forever

And the folder tree, which takes ten minutes to define and is worth more than any software decision:

2026-09-12_Reyes-Whitfield/ 01_client/ contract, proposal, correspondence log 02_budget/ budget sheet, invoices, reconciliation 03_vendors/ contracts, briefs, contact sheet 04_venue/ site notes, drawings, photographs, permissions 05_planning/ timeline, run sheet, guest list, floor plans 06_day/ production book, emergency page, assignments 07_after/ finding log, debrief, wrap-up, photographs _archive/ every superseded version

Alt-text: a folder structure for a single event, with seven numbered folders — client, budget, vendors, venue, planning, day, after — plus an archive folder for superseded versions.

⚠️ Common Pitfall: versioning by feeling

RunSheet_FINAL.pdf. RunSheet_FINAL_v2.pdf. RunSheet_FINAL_USE_THIS.pdf.

Everybody laughs at this and everybody does it, and on a document that fourteen people are working from it is a Chapter 26 failure waiting to happen.

The fix is v1, v2, v3 and an archive folder, and it is entirely a discipline rather than a tool.

🚪 And the convention this book has earned: write the unit next to the number

89 becomes 89 — seated dinner @ 12 sq ft.

300 bottles becomes 300 bottles — scoped at 60% participation, guest count 500.

Contingency $826.69` becomes `Contingency $826.69 — net of explicit decisions only; excludes line variance.

Three separate errors in this book — Chapter 28's barn, Chapter 32's wine pull, Chapter 34's gaffer tape, and Chapter 30's contingency — were the same error, and this convention is the whole of the fix. It costs four words.

🔄 Retrieval Practice

Without looking back:

1. State the threshold concept, and give the five reasons a written finding produces no change.
2. Name the four components of a system. Which is software?
3. Give the four document conventions and the unit convention.

Check

1. A system is not software; it is the mechanism by which a finding becomes a change. Found and fixed in the same column · the change lands in the wrong artefact · the artefact is not opened before the next event · the finding is filed under the wrong heading · and there are too many.
2. Artefacts · triggers · conventions · a closing loop. None of them is software — software is a delivery mechanism for the four, not a fifth.
3. One place · a naming convention with the date first and the version last · one current version with an immediate archive · the same tree every event. And write the unit next to the number, which fixes four separate errors this book made.

39.5a The Two Records Nobody Keeps

Both are free, both take seconds, and between them they solve most of what a planner cannot remember in month eleven.

The correspondence log

⚡ One line per decision, in one file, per event

14 Mar Venue confirmed 7am access, $300. Email from Lena, in 04_venue. 22 Mar Couple: no floral arch. Their words: "nothing bought for a wedding." 09 Apr Marguerite: family style confirmed. 1.2775 load factor re-checked. 17 Apr Alicia asked for Rosa to speak. Told Rev. C — needs his agreement.

Not a transcript. A decision, a date, a person, and where the evidence is.

What it is for, and it is three separate things. Month eleven, when nobody remembers whether the 7 a.m. access was agreed or discussed. Chapter 30's wrap-up, where "you'll misremember" is stated as fact. And Chapter 9, if anything becomes a claim.

It takes about twenty seconds per entry and perhaps forty entries per wedding.

The decision record

⚡ And a second file, shorter, for the decisions that will be questioned

A decision record is different from a log entry: it captures why, not just what.

The decision	Ceremony moved from 5:00 to 4:15
When and who	14 April, planner, agreed with couple
Why	Beach club 90 m north plays amplified music from 5 p.m. Saturdays; resort cannot stop it
What was rejected	Screening, a later start, asking the club — all considered, none workable

Write one only for decisions that (a) somebody will ask about later, or (b) cost money, or (c) went against somebody's preference.

Perhaps six per wedding.

And their value is almost entirely in one moment: when a client, a family member, or you in eight months asks "why did we do it that way?" — because the reasoning evaporates and the decision remains, and a decision without its reasoning is indistinguishable from an arbitrary one.

🎤 From the Field

A mother of the bride asked me, four months after the wedding, why the ceremony had been so early.

She was not complaining. She genuinely wanted to know, because her sister had asked her.

I could not remember. I knew there had been a reason and it had been a good one, and the best I could produce was "there was something about the sound."

That is a small failure and it made me look like somebody who does things for no reason — to a person who talks to a lot of other people.

39.6 Templates That Improve

🚪 The difference between a template and a system is that a template changes

A template used unchanged for four years is a snapshot of what you knew in year one.

A template that gains a line after every event is the mechanism this whole chapter is about.

⚡ Quick Reference: the twelve artefacts worth templating

Enquiry questionnaire · proposal · contract	Ch.36, 37, 38
Budget sheet — with an unallocated-remainder flag	Ch.30's finding
Timeline and run sheet	Ch.25, 26
Guest list — with dietary, access, and an alone column	Ch.14, 29
Vendor tracker and brief	Ch.12
Production book and emergency page	Ch.26
Debrief and finding log	Ch.30
Venue file	§below

And the one that is new to this chapter and closes a Chapter 34 finding: the venue file.

✅ Best Practice: the venue file

One document per venue, kept forever, added to every time you work there.

Access — dock, height, width, turning circle, and how a vehicle gets out	Ch.13, 34
Power — supply, board locations, and what shares a circuit with what	The Cascadia's kitchen and ballroom
Capacities, with units and assumptions	§39.5
The people — who is actually asked the question, who has authority, who lets a truck in	Ch.38
Curfews, restrictions, exclusive suppliers, handback times
What goes wrong here	Ch.34's corridor conversation, written down at last

Chapter 34 found that a venue's institutional knowledge lives entirely in individuals and a planner benefits from it only by accident.

A venue file is the fix, it is free, and it compounds — and by the fifth event at a venue it is worth more than any software in this chapter.

39.7 Data and Privacy

The section planners skip, about information they are definitely holding.

⚠️ You are holding sensitive personal data and you probably have not thought of it that way

A guest list with dietary requirements contains health information. An access list contains disability information. Chapter 26's emergency page contains medical facts about named individuals. Chapter 29's alone-list contains inferences about people's lives.

In many jurisdictions several of those categories attract specific legal protection — and the fact that a couple gave them to you does not remove your obligations.

📜 Tier 2 and jurisdiction-dependent. Find out what applies where you work. GDPR-style regimes, and their equivalents, are specific about health data, and "I'm a small business" is not an exemption anywhere the author is aware of.

✅ Best Practice: five things that are true almost everywhere

Collect the minimum	You need "tree nut, anaphylactic, table 6." You do not need a medical history
Store it in one place and control access	Not in email, not in a shared spreadsheet with a public link
Share only what a vendor needs	A caterer needs the allergy and the table. They do not need the guest list
Delete it when the event is over	A defined retention period, written down. Financial records are different — Ch.30
Say what you do with it	A short, plain paragraph in your contract or on your site

And the one people get wrong: photographs. The right to use images of a client's wedding is a contractual matter (Ch.36), and images of guests are a different question again — particularly children, and particularly in jurisdictions with strong image-rights law.

⚠️ Common Pitfall: the shared link that never expires

A run sheet on a link-shareable document, sent to fourteen people, is a run sheet that is public to anybody who ever received the link, forever.

On a document containing an emergency page, that is a real problem — and the fix is: share the run sheet, and keep the emergency page separate, distributed on the day, on paper, to five people.

Which Chapter 26 already recommended for completely different reasons.

🔄 Retrieval Practice

Without looking back:

1. Name the four kinds of trigger and say which is most valuable and which is not a trigger at all.
2. What are the six platform-evaluation questions for, and which one does nobody ask?
3. Give the four document conventions.

Check

1. Time-based · event-based · threshold-based · and intention, which is not a trigger. Threshold triggers are the most valuable and almost nobody has them — guest count moves by more than 10 → re-run catering, floor plan, seating, transport, guarantee. Intention is a personality trait pretending to be a mechanism.
2. To choose a stack by function rather than by demonstration. Nobody asks question 5: what does it not do that I will therefore stop doing? — a platform with no floor-plan tool means you will stop drawing floor plans, and Chapter 11 established what that costs.
3. One place · date first, version last · an archive folder for every superseded version · and the same tree for every event, forever. Ten minutes to define, and it survives changing platforms — which the platform does not.

39.8 The Second Column

The mechanism this whole chapter exists for, and it is one column and two fields.

✅ Best Practice: the finding log that closes

Found	Finding	Artefact to change	Owner	Due	Closed
12 Sep	Stationery line $300 out since booking	Budget template — add unallocated flag	Me	30 Sep	✅ 26 Sep
12 Sep	Barn rafter line wrong on drawing	Venue file — Wildrye	Me	30 Sep	✅ 19 Sep
12 Sep	Combination 8 recorded as moved, never happened	Shot-list template — "moved" requires a new time and owner	Me	30 Sep

Four things make it work and only one is obvious.

A separate closed column, so an open row is visibly unfinished forever.

A named artefact, because "be more careful" cannot be closed and "add a flag to the budget template" can.

A due date, which for a solo planner is almost always "before the next event of this type."

And an owner, which on a solo practice is always you — and writing your own name in a column is a surprisingly effective act.

🚪 The rule Chapter 30 arrived at and this chapter operationalises: a finding logged in an audit gets an owner and a due date, or it is not logged

Because a log of unclosed findings is worse than no log.

It documents that you knew, and it produces the feeling of having acted — which is the "From the Field" note's ninety-one entries and four changes.

39.9 Replaceable on a Task, Irreplaceable on Judgment

🚪 The goal of a system is not to make you unnecessary. It is to make the right parts of you unnecessary

Chapter 27 distinguished the fifteen-second decisions from the ninety-second ones. The fifteen-second decisions were the ones made in month six, and they are exactly the ones a document can carry.

A system should absorb: sequencing, arithmetic, remembering, checking, and anything with a right answer.

It cannot absorb: reading a room, deciding what a client actually wants, holding a difficult conversation, and knowing which rule to break.

⚡ Quick Reference: what to systematise, in order of return

	Return
Anything you have done more than three times	Highest
Anything with a right answer you keep re-deriving	Chapter 34's dependency map, Chapter 18's load factor
Anything a mistake in which is expensive	The guarantee, the contract, the insurance dates
Anything that must happen at a specific time regardless of your attention	Triggers
Anything you would have to explain to a substitute	Ch.27's handoff

And the honest limit: systematising judgment produces a checklist that is wrong in the interesting cases — which is Chapter 21's whole argument and Chapter 28's type-3 crisis.

39.9a Automation and AI, Honestly

A section that will date faster than anything else in this book, written to be useful anyway.

⚡ Quick Reference: where automation genuinely helps

Payment reminders	Ch.36's finding — most late payment is somebody who has not looked at their email
Trigger scheduling	§39.2a. A recurring task set is automation
Document assembly — proposals and contracts built from a template and a data set	Real time saved, and low risk
Transcription and summarising your own notes	Useful, and check it
First drafts of repetitive writing — vendor briefs, guest information, timelines from a structure	Where a tool is fastest
Data reformatting — a guest list into a seating chart into a caterer's format	Tedious, mechanical, and error-prone by hand

⚠️ Where it makes things worse, and three of these are specific to this trade

Anything client-facing that should be a person. Chapter 32's forty-second board-member call, Chapter 30's Monday message, and a condolence. An automated version of any of those is worse than nothing, because it signals that the moment was processed rather than noticed.

Anything that produces confident output you cannot check. A generated timeline looks like a timeline. A generated load calculation looks like a load calculation. Chapter 18's arithmetic and Chapter 34's dependency map are exactly where an unchecked plausible answer is most dangerous, because the error surfaces on site.

Anything involving the sensitive data in §39.7. A guest list with medical and dietary information pasted into a third-party tool is a disclosure, and "it was just to reformat it" is not a defence. Know where your data goes.

And the one that is subtlest: anything that removes the act of thinking that was the point. Chapter 34's dependency map takes fifty minutes and its value is not the diagram — it is that somebody had to work out what depends on what. A generated version produces the artefact and not the understanding, and the understanding is what catches the thing the tool did not know about.

🚪 The test: does this remove typing, or does it remove judgment?

Removing typing is almost always good. Removing judgment is almost always the beginning of a Chapter 28 incident.

And the practical rule that follows: a tool may draft anything and may decide nothing — and anything it drafts that will be relied on by somebody else is checked by a human who understands why it is right.

And one honest note about the market. A great deal of software is currently sold to this industry on the promise of removing work that Part VI spent six chapters establishing is the job. The timeline, the run sheet, and the production book are not overhead — they are the mechanism by which the fifteen-second decisions become possible, and a tool that generates them without you having thought about them has produced Chapter 27's document without Chapter 25's understanding.

🧩 Productive Struggle

It is January. You are a solo planner with nine weddings booked and about 40 hours of non-billable time available for systems work before March.

Here is your finding log from last season. Every entry is real and correct.

	Finding	Source
1	A guest count moved 96 → 118 across seven months and nobody re-ran the floor plan	Two events
2	Insurance certificate for a venue expired four days before the event; discovered on site	One event
3	You have no record of where any of last year's nine bookings came from	All
4	The same caterer's final-numbers deadline was missed three times	Three events
5	A generator was under-specified because you re-derived the load factor from memory	One event
6	Two clients asked for the same thing you had already built for somebody else and you rebuilt it	Two events
7	Your run sheet exists in three versions in two places	Ongoing
8	You have never once written down what goes wrong at Ashcombe	Ongoing

You can do three or four. Choose, and say what you defer and why.

Think for at least five minutes before opening this

First, apply §39.11's criteria rather than picking the ones that annoy you most — which would be 6 and 7.

Prioritise: prevents an expensive error · compounds · caught you twice · under thirty minutes · closes an old finding.

The four:

2 — the insurance certificate. Highest expected cost by a wide margin. An expired certificate is a venue refusing entry, a Chapter 9 exposure, and a possible cancellation. The fix is a trigger (§39.2a, −8 weeks) and it takes four minutes to add to the template. Prevents an expensive error, under thirty minutes, done.

1 — the guest-count threshold. Caught you twice, and it is Chapter 5's master variable going unmanaged. A threshold trigger: guest count moves by more than 10 → re-run catering, floor plan, seating, transport, guarantee. Thirty minutes to define, and it compounds across every future event.

8 — the venue file. The highest-compounding item on the list. You will work at Ashcombe again, and again. Start one file, today, from memory, badly — and add to it after every event. It also absorbs finding 5, because the load factor lives in it.

3 — the attribution column. Two fields on your enquiry form and one question in the discovery call. Under twenty minutes, and without it Chapter 38's entire CPA analysis is unavailable to you forever. You cannot recover last year; you can start today.

What you defer, and why it must be written down:

4 — the caterer's deadline. Real and it belongs in the trigger set, which item 1's work is already touching — so it is nearly free once the template exists. Do it as a rider on 1 if the time is there; defer explicitly if not.

6 — the template library. Genuinely valuable and it is a big job. Deferred to next January, with a date, and in the meantime a single folder called _reusable costs nothing.

7 — the run sheet versions. This one is a convention, not a project (§39.5) — and the honest answer is that it is fifteen minutes of discipline rather than forty hours of work. Do it, but do not count it against your forty hours.

The thing to notice about your own answer: if you picked 6 and 7, you chose the two that irritate you daily over the one that could stop a wedding. If you picked all eight, you have described the reason this chapter's last section exists. And if you deferred without dates, you have converted four findings into four that will die — which is §39.1's first mechanism, happening to your own systems work.

39.10 Where Technology Makes It Worse

⚠️ Six places, and every one is common

1. The client portal nobody opens. It moves communication from where the client is to where you want them to be, and most couples want to text you. Chapter 3's client management, defeated by a login.

2. Notifications as a substitute for a schedule. A stream of alerts feels like attention and is the opposite — Chapter 27's attention, fragmented on purpose.

3. The platform that hides the arithmetic. A budget tool that produces a total without showing the working makes Chapter 30's reconciliation harder, not easier, and Chapter 28's re-derivation impossible.

4. The automation that removes a human moment. An automated thank-you is worse than none. Chapter 32's forty-second board-member call is the counter-example, and it does not scale, and that is the point.

5. The document that is too easy to change. A run sheet edited live during an event, with no version, is a Chapter 26 failure — and printing it is not backwardness, it is a freeze.

6. The tool that makes bad work look finished. A beautifully rendered floor plan is not a checked floor plan, and a template's polish is frequently mistaken for its correctness.

🎤 From the Field

The best-run wedding I ever saw was run by a woman with a ring binder, a highlighter, and a paper diary.

Her binder had tabs. Every tab had the same tabs as every other wedding's binder. She had done four hundred of them and the ninety-first tab was in the same place as it had been in 2009.

That is a system, and there was not a single piece of software in it.

39.11 The Capacity Problem

And the honest end of the chapter, because it is the reason most systems work fails.

🚪 A planner cannot implement twenty-two changes, and pretending otherwise is how none of them happen

This book has accumulated twenty-two systems changes across thirty-eight chapters. Every one is correct and cheap.

And a working planner, in a season, will implement three or four.

Which means the systems audit is not a list of changes. It is a ranking, followed by a decision about what does not get done this year — and that decision has to be made explicitly, or it gets made by attrition and you lose the important ones along with the rest.

✅ Best Practice: how to choose

Prioritise	Defer
Anything that prevents an expensive error	Anything that saves minutes
Anything that compounds — a template, a venue file	A one-off fix
Anything you have now been caught by twice	Anything from a single event
Anything that takes under thirty minutes	Anything that requires a new tool
Anything that closes an open finding from more than a year ago

And write down the deferred list, with a date. A change you decided not to make is a decision; a change you forgot is a finding that died.

39.11a Practical Notes

On the backup. A single laptop failure two days before a wedding should be an inconvenience and not a catastrophe. Cloud storage that syncs, plus a printed production book (Chapter 26), is the whole of it.

On working offline. Every rural venue in this book has poor signal. Anything you need on the day must exist without a network — which is the operational half of §39.10's fifth item.

On the phone as an artefact. Photographs of a venue, a whiteboard, a delivery note, a damaged chair. They are the cheapest records you have and they belong in the folder tree within a day, because a phone with 4,000 photographs is not a record.

On somebody else's system. A corporate client will have one and you will have to use it — a supplier portal, a procurement system, a shared drive with their conventions. Comply cheerfully; keep your own record in parallel.

On the system you inherit. If you ever take over another planner's practice or their event, the first hour is spent finding out where things are, not what they say. Chapter 27's handoff.

On changing tools mid-season. Do not. A migration in July is a Chapter 34 threshold problem in your own business — two systems needing the same attention at the same time.

On what to keep forever. The finding log, the venue files, the template library, and your own hours data (Chapter 37). Everything else has a retention period.

On the audit itself. Once a year, in the same month, ninety minutes. §39.11 — and it is the same discipline as Chapter 37's annual fee review, and it should be the same afternoon.

39.12 Summary

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.

Five reasons a written finding produces nothing: found and fixed in 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.

Four components — artefacts, triggers, conventions, and a closing loop — and none of them is software. A platform without the four is an empty container with a subscription.

A system that lives in one person's head is expertise, not a system. The test: could somebody competent run your next event from your documents, without you?

Choose the stack by function, not by product. Nine functions; four are non-negotiable at about $60 a month; and function 8 — the finding log, the venue file, the template library — is free and almost universally absent.

Evaluate a platform with six questions, and the one that matters is what does it not do that I will therefore stop doing? Run one real event in parallel before deciding.

Four document conventions: one place · date first and version last · one current version with an immediate archive · the same tree every time.

And 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.

A template used unchanged for four years is a snapshot of what you knew in year one. The venue file is the artefact this book has been asking for since Chapter 34, it is free, and by the fifth event at a venue it is worth more than any software here.

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, and say what you do with it.

The second column is the whole mechanism: found, artefact, owner, due, closed. A named artefact, because "be more careful" cannot be closed. And a log of unclosed findings is worse than no log, because it documents that you knew.

Systematise sequencing, arithmetic, remembering, checking, and anything with a right answer. You cannot systematise reading a room, or knowing which rule to break.

And six places technology makes it worse, of which the sharpest is the tool that makes bad work look finished.

Finally: a planner cannot implement twenty-two changes. Three or four a season. So the audit is a ranking and an explicit decision about what does not get done — because a change you decided not to make is a decision, and a change you forgot is a finding that died.

Spaced Review

From Chapter 26 — the production book. What does this chapter add?

From Chapter 30 — the systems change. What does §39.8 operationalise?

From Chapter 36 — the tool stack. Why buy a platform fourth?

📐 Project Checkpoint

Run the systems audit.

Every systems change this book has accumulated across thirty-eight chapters — the unit next to the number, the venue file, the second column, the access questions on the RSVP template, the attribution column, the alone-list, the scope note, the annual fee review, and fifteen more.

Produce:

1. The full list, sourced to its chapter
2. The ranking, using §39.11's criteria
3. The three or four for this season, and the artefact each changes
4. The deferred list, with dates
5. The stack decision, by function
6. The document architecture
7. The data and retention position

case-study-02.md does all seven — and there are twenty-two, and no planner can implement twenty-two things.

Looking Ahead

Part VIII ends here. Part IX is the capstone and the career.

Chapter 40 is the complete wedding, start to finish, stress-tested — everything this book has built, run once, on paper, against a scenario designed to break it.

And Chapter 41 asks the question none of the arithmetic in Part VIII has touched: what this work costs the person doing it, and how long anybody can do it.