Client Work Requests
A client briefs work in the portal, a contractor scopes it, and the client holds both gates: approve the estimate before anything starts, accept the work before anything bills. The moment they accept, the invoice is created in QuickBooks and lands in their inbox.
One loop, two client decisions
This is the client side of the loop. The contractor side runs on Contractor Payments, and the invoice lands in the ledger kept true by QuickBooks Invoice Sync.
Adding scope, mid-flight
Work already underway and the client wants more? They add scope right on the same request. They never touch the hours: the added scope goes back to the contractor to re-estimate, and the client approves again before the extra work counts. Same request, same gate, still one invoice at the end.
How each step works
The portal offers five doors: a general request that lands in the CRM inquiries pipeline, a project brief aimed at a specific contractor, a full-time hire in Vietnam, pre-paid human token packs (40 tokens for $2,000, one token per hour of skilled work), and an AI program plan. This workflow follows the project brief.
The brief goes straight to the contractor by email, with a secure link to their own work page. They come back with an estimate: hours and a plan, and the client is emailed the moment it is ready. No account manager translating in the middle.
Decision one. The client approves, requests changes, or declines, right in the portal, and the contractor is emailed the decision. Nothing gets built and nothing gets billed until they say go.
The contractor delivers and submits actual hours and a link to the result through the same request, and the client is emailed that it is ready, so they see exactly what they are being asked to sign off on.
Decision two. The client reviews the work and accepts it, or sends it back for revision with a note (the note is required). Acceptance is the only thing that triggers billing.
The moment the work is accepted, an invoice is created in QuickBooks for the hours delivered at the contractor's billable rate, QuickBooks emails it to the client, and it is mirrored into the invoice ledger so the account view is current immediately. If anything is off (no hours, no client company, no billable rate, or QuickBooks says no), the request is flagged for manual invoicing, the accountant is emailed and ops pinged in Lark, instead of the system guessing. A billing problem never blocks acceptance.
The seven elements
Every workflow we document has the same anatomy: seven elements, each assigned to a human, a machine, or both. This is the Centaur Map from our workflow design method.
A client needs work done and opens a request in the portal. No email chains, no relay through an account manager.
The client's brief plus the contractor's estimate: hours, timeline, and a definition of done.
Both gates belong to the client: approve the estimate before work starts, accept the work before billing.
Every transition notifies the right person automatically by email: the contractor gets the brief and each decision, the client gets the estimate and the finished work, the accountant gets every billing outcome. The ops Lark channel sees every step.
Accepted work and a QuickBooks invoice, created the moment the client says yes.
QuickBooks emails the invoice and the CRM mirrors it instantly, so the account page is current before the weekly sync runs.
An event log stamps who decided what and when, and every request carries a billing status, so nothing invoiced slips and nothing failed hides.
The standing rules
- The client decides twice; nothing starts and nothing bills without them
- Scope can grow mid-flight: every addition re-estimates and re-approves before it counts
- Our team sees every request but is never a required gate
- Billing failures flag a human; they never block acceptance
- Contractor pay runs on its own monthly cycle, untouched by this flow
Why it works
- Requests skip the inbox and land where the work is tracked
- An estimate before approval means no surprise invoices
- Billing at the moment of acceptance means revenue never trails delivery
- The event log ends “who agreed to what” conversations before they start