Contractor Hours + Payment
Every piece of contractor work moves through one loop: request, estimate, approval, delivery, and a monthly payment run. The contractor is emailed at every step, ops hears in Lark, and admins decide from one page.
Three lanes, seven steps
Work passes between the admin, the system, and the contractor. The system carries every handoff, so nobody has to remember to follow up.
The admin writes up the work: what it is, the context, and what done looks like.
An email goes out automatically with a link to respond. When a client raised the request, the ops Lark chat is told too.
The link opens a form asking for their hour estimate and their plan to complete the work.
The admin (or the client who raised it) makes a call. Every decision emails the contractor.
Once approved, the contractor does the work and submits actual hours, a summary, and a link. The admin accepts it or asks for a revision.
On the 1st of the month, a routine rolls the previous month’s accepted work into one payment request per contractor.
Admins see every payment request on one page and mark each one.
From request to paid
Everything starts with a written request from the admin: the work to be done, the context, and what done looks like. No verbal assignments, so there is always a record to estimate against.
The moment a request is sent, the contractor gets an email carrying a link to their response form. A request raised by a client from the portal also pings the ops Lark chat, so the admin sees it without being asked.
The link asks the contractor for two things: their estimate in hours and their plan to complete the work. Both go on the record before any work starts.
The admin, or the client who raised the request, reviews the estimate and picks one of three outcomes:
- Approve: the contractor is cleared to start
- Reject: the request is closed
- Request changes: the contractor gets a note and submits a new estimate
Every decision emails the contractor, and a reject or a change request must carry a note, so the loop never stalls waiting on a status update. Scope added mid-flight sends the request back for a fresh estimate the same way.
Once approved, the contractor does the work. When it is done they submit their actual hours (regular and overtime), a summary of what was delivered, and a link to the work. The admin, or the client, accepts it or asks for a revision; only accepted work reaches the payment run.
On the 1st, a scheduled routine rolls every piece of work accepted in the previous month into one payment request per contractor, pricing the hours at their current hourly and overtime rates and linking the work requests to it. Re-running is safe: a still-pending payment is recomputed, a paid or rejected one is never touched, and a contractor with no rate on file is skipped and named. The ops Lark chat gets the tally and a link to review, and an admin can run the same roll-up by hand.
Admins get one page listing every payment request, with the linked work and an amount they can adjust while it is undecided. Each one is marked paid, rejected, or more information required. Paid and more-information email the contractor; rejected is an internal note and sends nothing.
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.
An admin creates a written work request. No verbal assignments, so there is always a record.
The request scope from the admin; the estimate and plan, then the actual hours, summary, and work link from the contractor.
Three human gates: approve the estimate before work starts, accept the work when it ships, decide the payment on the 1st.
Every decision emails the contractor, looping the request until it is approved or closed; the ops Lark chat hears when a client raises or decides one.
A monthly payment request per contractor, with the accepted work linked and the hours priced at their current rates.
One admin page listing every payment request, plus an email back to the contractor when it is paid or needs more information.
Estimates versus actuals per contractor over time, the number that makes the next estimate honest.
The standing rules
- No work starts without a written request and an approved estimate
- Every decision emails the contractor; ops hears in Lark
- Actuals need a summary and a link to the work, not just hours
- Payments batch monthly on the 1st, reviewed on one page
Why it works
- Estimates before work means no surprise invoices
- The system owns the handoffs, so nothing waits on a human memory
- Work links make every payment auditable months later
- One monthly run replaces ad hoc payment requests all month long