Our client documents: how they work, and where they're going
Nine documents take an accountancy firm from first phone call to finished build. This paper explains what each one does, how they feed each other, and the decisions we need to make together. None of these documents are set in stone: if we need more, fewer, or different ones, that's exactly what this discussion is for. Written for discussion, nothing here is final.
TL;DR
We have a document chain, not nine separate documents. Each one hands off to the next: call brief → audit proposal → audit agreement → access checklist → interviews → audit report → build proposal → build agreement.
The CRM does the boring parts, Claude does the bespoke parts. The CRM fills in facts automatically (names, dates, fees). Claude writes the custom sections from our notes and call material, and everything is saved in our database first, then shown as a document.
Because content lives in the database, we can show it anywhere. Today it renders as Google Docs. The plan is a client portal "wizard": a step-by-step web page (think Ignition) where the client reads the proposal or report, ticks the recommendations they want, and signs the agreements right there. Same data, better presentation.
The one rule that matters: the numbers and the client's selections must live in the CRM. How the document looks can be as custom as we like, as long as what it says is on record.
Decisions needed from the three of us: the shape of the funnel itself (Q0, the big one), the working rule above, real prices for the recommendations menu, and the legal adviser's sign-off on signing agreements inside the portal.
Part 1
The process now, and the process after
The honest picture of how we produce client documents today, next to what the system gives us once we work through it.
Now
Client information is scattered across chats, inboxes, notes, and personal drives.
Every document starts from a blank page and is written fresh each time.
Structure, wording, and pricing vary depending on who wrote it and when.
What was sent, quoted, and agreed lives in chat history and memory.
Nothing feeds the next step. The report doesn't build the proposal; the proposal doesn't build the agreement.
Pipeline numbers depend on asking each other what happened.
After
One database holds every firm's facts, fees, documents, and history.
Documents assemble themselves: the CRM fills the facts, Claude writes the bespoke sections from our notes and call material.
Every client gets the same structure and voice. Only their content and prices change.
Every document, price, and selection is on record against the client, automatically.
Each document feeds the next. The client's picks from the report literally become the build proposal.
The dashboard shows the true state of every deal, without asking anyone.
Same effort, going further: bespoke where the client sees it, systemised underneath. It's also the exact product we sell to accountants, so our own process should be the proof it works.
Part 2
The journey, start to finish
The path below is the funnel as currently designed and built: we sell a paid audit first, the audit produces a priced menu of recommendations, and the client's picks from that menu become the build. Whether this is the right funnel is an open question, and it's Q0 in Part 5. Each document exists to move the firm one step along.
1
Call Brief internal
Before the discovery call
A one-page prep sheet so whoever makes the call already knows the firm, the contact, and what to ask. Never seen by the client.
2
Audit Proposal client reads
After the discovery call
Sells the paid audit: what we'll look at, what it costs, and the hook that the fee is credited against the build if they go ahead. If they say yes, the agreement goes out.
3
Audit Agreement client signs
Audit agreed
The contract for the audit: scope, fee, payment, confidentiality. Signing this turns the prospect into a client and starts the engagement.
4
Access Checklist client fills in
Audit kick-off
Asks the client for system access (Xero, Google Workspace, and so on), sample documents, and the names of who runs what, so the audit can actually start.
5
Discovery Interview Questions internal
During the audit
Our script for interviewing the client's staff. The answers go into the CRM as notes and become the raw material for the report.
6
Recommendations Catalogue internal data
Feeds the report
Our reusable menu of things we know how to build (debtor chasing, email triage, document data-entry, and so on) with indicative prices. For each firm we pick what fits, reword it around their situation, and price it for them.
7
Audit Report client reads & picks
Audit delivered · the decision gate
The paid deliverable: findings plus the priced menu. Every item stands alone, framed as "here's what this problem costs you, here's the fix, here's the price". Whatever the client ticks becomes the build.
8
Build Proposal client reads
Client has picked their items
Confirms exactly what they chose, the total price, and the audit fee coming off it. Nothing bundled in that they didn't pick.
9
Build Agreement client signs
Build agreed
The contract for the build. Signing it starts design and development.
Part 3
Where each document lives, now and later
Today everything is a Google Doc generated by the CRM. The plan is simple: everything the client touches moves to the portal wizard. They read proposals and the report there, pick their recommendations there, and sign the agreements there too, Ignition-style. When an agreement is signed, the system still saves a copy as a document, so we always hold a permanent record of exactly what was agreed. Internal documents stay internal. Because the content is stored as data, the wizard is a second way of showing the same thing, not a second set of documents to maintain.
The nine documents at a glance
Document
Who sees it
When
What it does
Lives now
Heading to
Call Brief
Us only
Call booked
Prep sheet for the discovery call
Drive Doc
stays internal
Audit Proposal
Client
After the call
Sells the paid audit, fee credited against build
Drive Doc
client wizard
Audit Agreement
Client, signed
Audit agreed
Contracts the audit, converts prospect to client
Drive Doc + e‑sign
signed in wizard*
Access Checklist
Client
Kick-off
Gathers system access, samples, process owners
Drive Doc, shared
portal form, later
Discovery Questions
Us only
During audit
Staff interview script, answers become CRM notes
Drive Doc
stays internal
Recommendations Catalogue
Us only
Feeds the report
Reusable menu of solutions + indicative prices
repo file, not Drive
wizard's menu data
Audit Report
Client
Audit delivered
Findings + priced menu, client picks items
Drive Doc
wizard, interactive picks
Build Proposal
Client
Items picked
Confirms chosen scope and net price
Drive Doc
client wizard
Build Agreement
Client, signed
Build agreed
Contracts the build: scope, payments, IP
Drive Doc + e‑sign
signed in wizard*
* Signing in the wizard needs the legal adviser's sign-off on the mechanics (proving who signed, keeping an audit trail). Until then, agreements are e-signed as documents. Either way, a signed copy is stored as a document for the permanent record.
Folder rule (worth agreeing today)
Each client has a Drive folder the system can read. Anything that is evidence about the client (meeting notes, transcripts, files they send us) goes in the Discovery subfolder: that's what Claude reads when writing their report. Anything we sent them (like a custom HTML proposal) goes in the main folder, so it's on record but never mistaken for client evidence.
Part 4
How a document actually gets made
Three steps, and the order matters:
1. The CRM fills in the blanks. One click copies the template and drops in the facts: firm name, contact, date, fee. No thinking involved, no typos.
2. Claude writes the bespoke sections. Working from the CRM record, our notes, and the Discovery folder, Claude writes the parts that are unique to this firm: the tailored scope, the findings, the recommendations with prices.
3. Everything is saved as data first. The bespoke content and the priced recommendations are stored in our database, and the Google Doc is generated from that. That's the trick that makes the wizard cheap to build later: it just reads the same data and shows it a nicer way.
We check and approve before anything goes to a client. Claude drafts, founders send.
Part 5
What we need to decide
Q0 · THE BIG ONE
What shape should the funnel be?
Two models are on the table. They disagree about one thing: when does the client first pay, and when do they first feel the value? Everything else in this paper works under either model; the stages, prices, and documents would be adjusted to fit whichever we choose.
Model A: paid audit first
Call → Paid Audit (fee credited against build) → Report with priced menu → Build(s)
Works in its favour
The client has skin in the game, so they engage with the audit and act on the report.
Revenue from the first engagement. Every hour we spend is paid for.
The audit scopes the build before anything is built, so we build the right thing.
A short cycle with two decisions: buy the audit, buy the build.
Works against it
The client pays before they have felt any value. The first yes is the hardest one.
The value arrives as a report. Some buyers won't act on a document, however good.
Higher barrier to entry. Firms that would convert after a taste may never start.
Model B: taste first
Call → Small Audit → Free Small Build → Review of Value (after usage) → Paid Full Audit → Full Builds
Works in its favour
The epiphany is experienced, not promised: the client feels time saved on their own data before the big ask.
A much easier first yes. More firms enter the funnel.
The small build is a live demo in the client's own words: strong material for referrals and seminars.
Trust is built before the full audit, so the full engagement may be bigger when it comes.
Works against it
Free work costs real founder time with no revenue, at a stage when the company has none.
Free things risk not being valued or even switched on. If unused: no epiphany, and the funnel stalls at "review of value" with nothing owed and no lever to move it.
A longer cycle with more stages, more drop-off points, and support owed on free builds to firms that aren't yet clients.
Building before a full audit risks building the wrong small thing, and a bad first build hurts more than none.
One data point on record, for whichever way it cuts: the one accountant we've asked (our own target buyer) advised that free work doesn't get valued or acted on. That's a single opinion, not proof, but it's the only buyer input we currently have.
Possible middle grounds
Epiphany inside the paid audit. The audit already gets read access to the firm's real systems. Deliver the report with one quick win running live on their own data (their real debtor ledger driving a demo chasing sequence, a real morning digest). They feel the value at the decision gate, and the cost is bounded.
Paid-but-credited small build. A fixed-price micro-build (the daily digest is the cheapest item on the menu), credited in full against the full build. "Effectively free if you proceed" keeps skin in the game and cash flow, while still letting them live with a working system before the big commitment.
Test it. Run Model B on one firm and measure what happens: does the free build get used, does the value review land, does it convert? A real result beats a debate.
Can we agree the working rule: data in the CRM, presentation free?Custom-designed proposals are fine, encouraged even. The ask is only that the fee, the scope, and what the client picked are recorded in the CRM, so the pipeline numbers stay true and the next document can build on them.
Real prices for the menu.The recommendations catalogue has five items with placeholder prices. We need our actual numbers before the first real audit report goes out.
Signing in the portal.The plan is for clients to read and sign agreements inside the wizard, Ignition-style. Electronic signatures are legally valid in the UK; what we need is the legal adviser's sign-off on our mechanics: proving who signed, recording what they saw and when, and storing a signed copy as a document. Until that's confirmed, agreements are e-signed as documents.