Artience cut procurement approval from 7 days to 2

Requisitions, purchase orders, receiving reports and payment requests now run on a single approval engine that emails the next approver the moment it becomes their turn. Routing rules change without a developer. Printed forms change without a deployment.

Snapshot

The Challenge

Procurement ran on spreadsheets and email. Three things follow from that, and Artience had all three.

• Approvals waited on whoever was free. A requisition needed several people in sequence, and their schedules shifted. Nothing told an approver it was their turn, so a document moved when someone happened to open the right email. End to end, that averaged 7 days.
• A stalled request looked identical to a live one. One sitting unread was indistinguishable from one under review, so finding it meant chasing three departments.
• The approved document was not always the filed one. Forms were assembled by hand in Word, and a retyped figure stays invisible until someone reconciles the invoice.

If your approval chain lives in email, this is your situation whether or not it has cost you yet. It costs you at audit.

The Approach

One engine, four document types. The four forms are one lifecycle: raise a document, route it through a defined sequence of approvers, feed the next document. I built one engine that works on any document type instead of four that each know their own form. For Artience that means a policy change is made once and applies everywhere, rather than four edits with four chances to leave two departments on different rules.

The system chases people, not the requester. When a step becomes active, its approver is emailed immediately, and the outcome is emailed back when they act. This is the change that moved the number: the 7 days was mostly documents sitting still while nobody knew they were waiting.

Routing is configuration. A step names a person, a role, or the head of the requesting department, and requires all approvers or any one. So a policy change is an administrator's afternoon rather than a development ticket, and because department heads resolve at the moment of approval, a promotion does not silently route documents to someone with no authority over them.

Forms stay the client's. Artience's Word templates already existed and were already approved internally. The system fills one with the record data, stamps the signature, and merges the attachments into a single PDF. Rebuilding each form in HTML would have made every future change a developer's job forever.

The Build

The engine was built wrong first. Approval routing went into the purchase requisition, because in March that was the only document type. Orders, receiving reports and payment requests then each got their own variant, and by June the same logic existed four times and had diverged in each.

Rebuilding it as one document-agnostic engine cost a week that produced no new features, and every existing document type had to be rewired. Doing it in June rather than at the fifth document type was the recovery, not the plan.

Two defects only production found:

• Line items were paired by row position on update. PostgreSQL does not guarantee row order, so an edit could write one item's values onto another's. This produces a wrong purchase order that looks completely normal.
• A partial short-close left orders in a state where submitting appeared to work and did nothing.

Results

Before7 days

After2 days

26 documents went through in the first month, across 20 users, and both numbers are still climbing as departments move over. This is an early rollout rather than a finished migration, and the cycle time is what it produced first.

Cycle times and volumes are Artience's own figures. What is verifiable in the system itself: four document types on one engine, every decision carrying an actor and a timestamp, and routes and templates held as administrator-editable records rather than code.

Next

If your approvals live in email and your forms live in Word, the fix is a defined path with a record on it. Get in touch.