Request to Invoice
An automation study tracing every step between a customer's first request and a paid invoice, to see where manual handoffs add delay or errors.
Self-initiated example — not a client engagement.
Case 02 / 04
The artifact
A request stays trackable once every handoff has an owner, a status, and one place it can be found.
- CompleteRequestRequesterAccount ownerProject / scopeNamed in the request
- CompleteValidateAmountFrom the rate card
- CurrentApproveApproverCommercial owner
- PendingInvoiceDue dateSet by payment terms
- PendingStatusInvoice statusDraft · Issued · Paid
The path starts the moment a request names its own requester and its scope — not when someone finally opens a spreadsheet to work on it.
Validating a request reads the amount from one rate card, not from whoever remembers the last quote.
A named approver signs off before work proceeds — never a shared inbox or an implied yes.
The invoice's due date follows directly from the payment terms, not a guess made at send time.
Status moves in the open, so anyone in the chain can see where a request actually stands — draft, issued, or paid.
What changes operationally
BeforeEach handoff lives in a different tool, or in none at all.
AfterEach handoff is one stage on a single rail, owned and visible end to end.
BeforeA price or detail gets retyped by hand at least once.
AfterThe amount is read from the rate card once, not retyped at the next handoff.
BeforeNobody can say where a request actually stands.
AfterStatus is visible at every stage, from request to paid.
Context and question
In a small business, “request to invoice” is rarely one system. It is an email, then a quote in a spreadsheet, then a job in a scheduling tool, then an invoice typed up separately once the work is done — each step a small handoff where someone re-enters information the business already had. No one piece of that chain looks like a problem on its own. The question this piece asks is what the chain looks like end to end, and which of its handoffs are actually costing time or causing the errors that show up later as a wrong invoice or a late payment.
Approach
The approach is to trace one real path at a time rather than audit every tool at once: pick a single, common request type and follow it literally from the first message to the paid invoice, timing each handoff rather than just naming it — what turns a general sense that “invoicing is slow” into a specific, arguable claim about where the time actually goes.
