A change-order one-pager can look approval-ready while its story is already wrong: a phantom change line is added for a tidy log; the same ask from Slack + email + PDF is counted three times; base-scope work bleeds into the delta; a “verbal yes” is dressed as signed acceptance; a superseded CO_FINAL_v2 still greens the page next to v3; a guessed “about two days somehow” is locked as the fee; or open asks are scattered as footnotes nobody will find at handoff.
Before-you-share is different from a mid-change cleanup. This is the pass I run when the one-pager is about to leave my hands and someone else may treat every row as what was actually asked and accepted.
I am Brittany Bonds, a freelancer admin helper. I turn messy change-request dumps into clean change-order one-pagers. I am not a CPA, bookkeeper, lawyer, tax advisor, or contract attorney, and this is not legal, financial, tax, or contractual advice. It is an administrative proof-checking routine, not a recommendation about what anyone should approve, price, sign, or enforce.
This complements How I turn messy change-order notes into a clean change-order one-pager and The mid-change checklist I use so a change-order one-pager stays honest. Those live posts cover the first-pass workflow and the mid-change honesty cleanup. This third pass is the pre-share evidence check — not a rewrite of either.
What “honest enough to share” looks like
- Every change row and impact total maps to a Slack/email/PDF/ticket crumb, call note, or a labeled ask — nothing invented for a tidy approval preview.
- Soft guesses (“about two days somehow,” “usual add”) stay soft; hard dollars or hours only appear when a source supports them.
- Same-ask duplicates across Slack + email + PDF stay merged or labeled duplicate — they are not three change lines.
- Scope bleed into base work stays tagged clarification / already-included — not silently billed as a new change.
- “Verbal yes” without written acceptance stays ask / pending — not locked as approved.
- Superseded or zombie CR versions are labeled superseded / stale or removed from the share view.
- Open asks are listed once — not scattered as footnotes nobody will find at handoff.
- An emoji reaction or vague “lgtm” is not treated as signed acceptance unless the one-pager states what was confirmed.
If the only share instruction is “send the clean change-order page,” pre-share honesty has already slipped.
The before-you-send checklist
Use this against the near-final one-pager and live evidence: the original change-request dump (Slack threads, email forwards, call scribbles, PDF “final” versions, ticket comments), prior one-pager if any, and the mid-change scratch trail. The goal is not to make every cell complete. The goal is to make uncertainty visible before the page becomes someone else’s approval source of truth.
1. Freeze change rows to what was asked
- [ ] Every change row maps to a source crumb, screenshot, export, or a labeled ask — no orphan row gets a confident “this is the log” look.
- [ ] Phantom change lines, template filler, and “bonus” adds that never appeared in the dump stay out or labeled proposed / ask — polish is not permission.
- [ ] Duplicate asks under two (or three) phrasings — Slack + email + PDF of the same add — are merged or marked duplicate — one ask is not three change slots because it looked tidy three times.
- [ ] Request naming stays close to the source; a polished synonym may not be the same add or the same owner.
- [ ] Scope bleed into base work is tagged clarification / already-included — not silently rewritten as a new change line.
- [ ] Skim test: a reader can point from each row back to a source, or see that it still needs confirmation.
An invented change row is not automatically useless. It is a proposal. The misleading part is leaving it dressed as what was already asked for this project window.
2. Keep dollar and hours impact strength-honest
- [ ] Soft notes (“about two days somehow,” “usual add,” “roughly a small fee”) stay soft — they are not upgraded to hard dollars or hours for neatness.
- [ ] Hard amounts keep a quote line, email reply, estimate note, date, or confirmer when available — silence is not consent.
- [ ] Missing impact stays ask — a blank cell that looks priced is worse than a visible unknown.
- [ ] Currency and unit (fixed fee vs hours vs T&M) stay labeled; converting vibes into a tidy total without a note is a rewrite, not a cleanup.
- [ ] Totals never invent missing dollars or dates — blanks stay ask.
- [ ] Skim test: a reader can tell which impact lines are locked, which are soft, and which still need confirmation.
This is a consistency check, not pricing or contractual advice. I am recording what the dump disclosed, not deciding what anyone must charge or approve.
3. Separate acceptance from verbal yes — and list open asks once
- [ ] Status vocabulary is named (proposed / approved / rejected / parked / ask) — not blank cells that look signed.
- [ ] Evidence for approved (email reply, signed CO, ticket acceptance) sits in notes or source — “they said yes on the call” alone is not approval.
- [ ] “Verbal yes” without written acceptance stays ask / pending — do not dress it as signed for a prettier green column.
- [ ] Approver (who can say yes on their side) is named or unowned — folklore that “they’re fine with it” is not ownership.
- [ ] Open asks (missing impact, conflicting versions, guessed dates, unclear owner) are listed once in a visible place — not scattered as footnotes nobody will find at handoff.
- [ ] Skim test: a reader can say what is locked, what is still verbal-only, and what still needs a written yes without reopening Slack.
A verbal yes can be useful context. The misleading part is leaving it dressed as written acceptance on the share-ready page.
4. Retire zombie and stale versions before they travel
- [ ] Superseded CR versions (CO_FINAL_v2 still looking live next to v3) are labeled superseded or removed from the share view — they do not still green the page.
- [ ] Walked-back, canceled, deferred, or out-of-window asks are labeled stale or stay-off — they do not still inflate the change log.
- [ ] When Slack, email, and PDF disagree, keep the conflict visible as recheck — do not pick the easier line because it fits the template.
- [ ] Capture or last-checked date exists for material totals — “I cleaned this last week” is not a freshness rule.
- [ ] Raw scratch, rejected options, and unresolved conflicts stay in the evidence trail but out of the clean share view.
- [ ] Skim test: a reader can tell whether each line describes the current dump, an older CR version, or something still needing confirmation.
A zombie version is historical context. The misleading part is leaving it dressed as this window’s share-ready change order.
5. Challenge the Slack guess
- [ ] Replace “they said looks fine” / “while you’re in there…” folklore with the exact requests, impacts, or status that were confirmed, parked, or never named on the one-pager.
- [ ] An emoji reaction, “lgtm,” or vague thumbs-up is labeled by what it covered — it does not silently rewrite change rows, dollars, or acceptance status.
- [ ] If Slack approved a different version than the page you are about to send, stop and reconcile — do not ship the prettier draft under the older reaction.
- [ ] Make the share ask specific — confirm this change, this impact, this acceptance evidence, this superseded flag — instead of asking for another vague thumbs-up.
- [ ] Leave a visible needs confirmation marker where sharing would otherwise create a false record of agreement.
- [ ] Final skim: I can answer “what source supports this line, what still needs confirmation, and what did Slack actually cover?” for every share-ready row.
If a row fails one of these checks, I would rather send a visible needs confirmation label than make the change-order one-pager look complete by guessing.
Soft CTA
If you have a messy change-request dump and want it organized into a clean change-order one-pager, changeorders on Gumroad is $12. Code ADMIN12 takes $2 off. Browse the full shop or the catalog mirror on GitHub Pages.
Not a CPA. Not legal, financial, tax, or contractual advice — just an admin checklist for keeping a shared change-order one-pager tied to what was actually asked.
Top comments (0)