Run a standard in the tools you already use
No new platform to log into. The list, the drafts and the exceptions land where you already work, a person says yes or no, and you buy only the step that is hard to run yourself.
Used by
- Sales Agent
- Operations Manager
- Business Development Coordinator
How to get this live in your business
A standard says what a correct build does. It does not say where the build lives on a Tuesday morning. The answer is wherever you already work: your CRM, your inbox, a shared sheet, a small board your coding agent writes, or a bot that holds the routine. Nobody owns the board, including us.
In short
- Three runners
- Write the list into the tools you already use. Or have your coding agent build a thin personal dashboard. Or give the routine to a long-lived bot. Any of the three starts from the same standard.
- One contract
- The runner shows the standard's output without re-deciding it, puts exceptions first, sends nothing without a person's yes, and logs every decision so tomorrow's list reads it.
- What you buy, if anything
- Live data, a compliant voice step, or a record that survives a dispute. Each is optional and additive: you change the provider line and the runner stays where it is.
- The test
- Put a do-not-contact flag on the top-ranked row. The runner must show it skipped with the reason, and offer nothing to send.
Take the spec to Claude, ChatGPT or Copilot. The sentence to paste is one click away.
Want the whole thing by email?
This paper, plus the rest of the library. One click to stop them.
1. Three ways to run it
Pick the one that fits your week. They are not tiers: the first is often the right answer for good.
1. The tools you already use
You want nothing new to log into. Works today, lowest friction.
The coding agent writes the morning's ranked list, the drafted messages and the exception flags into what the office already runs: a task list in the CRM (Rex, Agentbox, VaultRE and the like, through whatever import or API that system offers), email drafts in your own inbox, a shared Google Sheet, or a Slack channel. A person reads, edits and sends from there.
Your CRM, your inbox, your sheet. The build is a script on a schedule.
2. A personal dashboard your coding agent builds
You want one screen with the list, accept and reject, and the log.
Ask the coding agent for a thin board: a small Next.js page, a Streamlit app, a Notion database, or a single local HTML file reading a CSV or JSON. It shows today's ranked rows, the draft for each, an accept and a reject, and a log of what was decided. It reads the standard's output and writes decisions back to the same place.
The agent's code, the agent's data. We never host it.
3. A long-lived bot
You want the routine to run while you are out.
Give the routine to a bot that keeps memory across days and can call tools (Claude, Grok or similar): every morning pull the list, draft the openers, surface the exceptions, then wait for a yes or no. The bot is only the runner. The standard and the data stay where they were, so swapping the bot loses nothing.
The routine is a prompt and a schedule. The data stays in your system.
2. The runner contract
Five rules every runner keeps, whichever of the three it is. They are what stop a convenient screen from quietly undoing the standard underneath it.
- 1
Reads the standard's output, never re-decides it
The ranking, the play and the exception flags come from the build. A runner that re-sorts or re-scores is a second standard nobody tested.
- 2
Exceptions sit on top
A do-not-contact conflict, a missing field, a reply waiting or a figure that does not match the record is shown before the first ranked row, with its reason.
- 3
Nothing leaves without a person's yes
Every draft waits for accept. Reject and edit are recorded. A runner with a send-all button has removed the gate the standard is built around.
- 4
Every decision is logged, with who and when
Accepted, edited, rejected, skipped and why. Tomorrow's list reads the log, so yesterday's no is not asked again.
- 5
The provider line is the only thing that changes
Stub today, production when you want live data or a voice step. The board, the bot and the sheet stay as they are.
For the developer, the shape a runner reads and writes. Every standard’s output maps onto it; the fields beyond these are the standard’s own.
For your developer. Show the runner shape
# today.json, written by the build, read by the runner
standard: database-reactivation-build-standard
generated_at: 2026-10-24T06:30:00+10:00
provider: stub # or production
exceptions: # always shown first
- row_id: c-118
kind: do_not_contact
reason: "Flagged 2026-09-02; ranked first, not offered"
rows: # in the build's order, never re-sorted
- row_id: c-204
play: tenure
reason: "Bought 2017; two sales on the street this month"
draft: "Hi Sam, it's Jess from ..."
channel: call # call | sms | email | letter
# decisions.jsonl, appended by the runner, read by tomorrow's build
{"row_id":"c-204","decision":"accepted","edited":false,"by":"jess","at":"2026-10-24T09:12:00+10:00"}
{"row_id":"c-311","decision":"rejected","reason":"spoke yesterday","by":"jess","at":"2026-10-24T09:14:00+10:00"}3. A week for an agent
A sales agent builds three standards with a coding agent over a weekend: Database Reactivation for the daily call list, the Just-Sold Pack for the neighbours of each sale, and Open-Home Feedback for Saturday’s register. Each runs against its stub until the checks go green.
Monday to Friday, a script writes the day’s call list into the CRM as tasks before 7am, with the reason and the opener on each. When a sale settles, the just-sold drafts land in the agent’s email drafts folder, waiting. On Sunday night, the open-home follow-ups and the vendor report draft sit in a shared sheet the agent reviews on their phone. Nothing new to log into, nothing sent without them.
Months later, the agent wants real sales in the just-sold letters instead of the mock feed, and the database tail called after hours so their own calls stay personal. They change the provider line on two standards. The CRM tasks, the drafts folder and the sheet do not move. Before a vendor meeting, the Price One-Pager is the fourth standard they add, the same way.
4. The paid steps, and only when you want them
Every standard runs end to end on its stub for free, and many builds never need more. These are the three steps that are hard to run yourself. Each is additive: the workflow does not move to use one.
| The step | What it replaces | Where it runs today |
|---|---|---|
| Live property data | Recent sales, suburb figures and estimate ranges in place of the mock feed, for the Just-Sold Pack, Price One-Pager and Database Reactivation standards. | Not offered by any product for your own build: the data licences do not cover passing it on. Build against the stub and use a source your business already licenses in production. |
| A compliant voice step | The optional call, outbound or inbound, with disclosure first, the Do Not Call Register, calling hours, a daily cap and a log of every call. | Office Voice, for every standard with a call: one governed call to a person you hold a record for, on a stated basis, never a cold or prospecting call. Off unless you turn it on for a workflow. Never the default. |
| A record that survives a dispute | The durable log of what was said, shown or sent, with consent and opt-outs held centrally, so a vendor or a regulator can be answered from evidence rather than memory. | Comes with the voice step on Office Voice: every call it places is logged with its basis. Not sold on its own; the standards say what your own log has to hold if you keep it yourself. |
The voice step and the payment links are Office Voice. Any Office Voice account can queue a single governed call through its MCP tool create_call, for a reason such as a callback someone asked for or a tenant’s own tenancy, and it refuses prospecting calls by design. Get Paid adds overdue invoices chased on the call against Xero, with the payment link sent mid-call, $199 per month. It slots in beside the systems you already run rather than replacing them.
The steps are written as MCP tools where a product offers one, so the same call works from Claude, Grok, Cursor, a script or a bot. Pricing stays flat per month, never per minute.
5. The one-minute test
Before trusting any runner, stage this. It takes a minute and needs nothing live.
- Mark the contact at the top of today’s list do-not-contact.
- Run the build again and open the runner.
- Pass: that contact shows above the list as skipped, with the reason, and there is nothing to accept or send for them.
- Reject the next row with a reason, and run again tomorrow.
- Pass: the rejected contact is not offered again, and the log shows who rejected them, when, and why.
A runner that fails either step has re-decided the standard, and the green checks on the build no longer describe what reaches a customer.
6. Hand it to a coding agent
Give the agent this page and one standard. Name the runner you want: “write today’s list into my Google Sheet”, “build me a one-page dashboard that reads today.json”, or “set this up as a morning routine that waits for my yes”. Then run the one-minute test above.
Would rather not build it?
For the call or the payment link, switch on Office Voice and keep the rest of the build as it is. For everything else, the 8-minute diagnosis maps how your week runs to what is already built and what is worth building.