Contractor Hours + Payment
Every piece of contractor work moves through one loop: request, estimate, approval, delivery, and a monthly payment run. Notifications land in Lark and email, 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.
A Lark message and an email go out automatically, each with a link to respond.
The link opens a form asking for their hour estimate and their plan to complete the work.
The admin makes a call. Every response triggers a notification back to the contractor.
Once approved, the contractor does the work and submits actual hours, an explanation, and a supporting link.
On the 1st of the month, the system summarizes all completed work and creates a request to pay.
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 created, the contractor gets a Lark message and an email, each carrying a link to their response form. Two channels means it never gets missed.
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 reviews the estimate and picks one of three outcomes:
- Approve: the contractor is cleared to start
- Reject: the request is closed or reworked
- More information: the contractor gets a specific follow-up question
Every response triggers a notification back to the contractor, so the loop never stalls waiting on a status update.
Once approved, the contractor does the work. When it is done they submit their actual hours, an explanation of what was delivered, and a supporting link as proof of the work.
On the 1st, the system summarizes every completed piece of work from the prior month per contractor and creates a payment request. Estimates, actuals, and proof links are all attached.
Admins get one page listing every payment request. Each one is marked paid, rejected, or more information required, and the contractor is notified of the outcome.
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, actual hours, explanation, and proof link from the contractor.
Two human gates: approve the estimate before work starts, approve the payment after it ships.
Every response triggers a Lark message and an email, looping the request until it is approved or closed.
A monthly payment request per contractor, with estimates, actuals, and proof attached.
One admin page listing every payment request, plus notifications back to the contractor on each outcome.
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 triggers a notification, in both Lark and email
- Actuals need an explanation and a supporting link, 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
- Proof links make every payment auditable months later
- One monthly run replaces ad hoc payment requests all month long