The PTM™ operating model,
for one real process.
A real example of what you get once a build moves into implementation — not a diagram of our process, a document about your business. Built for the same Meridian Supply Co example used on the methodology page.
Function Library entry
Process → Task → Mapping
Process: Incoming Payment Reconciliation. Mapping isn't just "who automates this" — for every task it names the Actor (who/what does it), the technology's role, and the human's role, with M/A/SA/F kept as a simple summary tag, not the whole story.
| Task | Complexity | Mapping | Human time | Frequency | Monthly hrs | Role | Systems | Priority |
|---|---|---|---|---|---|---|---|---|
| Pull the incoming payment record from the bank feed | Low | Software Tech: ExecuteHuman: — F | — | 310 / mo | 0 | — | Accounting system | 3/5 |
| Match payment against open invoices | Medium | Software + AI Tech: ExecuteHuman: — A | — | 310 / mo | 0 | — | Accounting system | 5/5 |
| Diagnose the variance on an unmatched payment | Medium–High | Human + AI Tech: RecommendHuman: Review SA | 8 min | 49 / mo | 6.5 | AR Lead | Accounting system, Email | 5/5 |
| Approve the match override or write-off | High (judgement) | Human Tech: AssistHuman: Decide M | 2 min | 49 / mo | 1.6 | AR Lead | Accounting system | 4/5 |
| Post the resolution and close the ledger entry | Low | Software Tech: ExecuteHuman: — F | — | 359 / mo | 0 | — | Accounting system | 2/5 |
Training — what the AR Lead needs to know
Automation removes the two clean-match tasks from a human's plate entirely — it doesn't remove the need to train someone on what's left. The AR Lead's role shifts from "match every payment by hand" to "judge the ones the mechanism couldn't."
Current → Augmented → Future
Current
An AR clerk opens the bank feed, cross-checks every payment against a spreadsheet of open invoices by hand, and flags anything odd in a running notes doc. ≈40 hrs/month, every payment touched by a human regardless of whether it's a clean match.
Augmented
The mechanism auto-matches clean payments and closes the ledger entry itself. The AR Lead only ever sees the ≈49/month genuine exceptions, and the mechanism drafts the variance summary before they look at it — they approve or correct, not investigate from scratch.
Future
Same allocation as Augmented, but the exception rate itself trends down as upstream data quality (PO references, bank remittance detail) improves — reviewed quarterly as part of DevShop Care + Optimisation, not a new build.
Economics — underneath Mapping, not the headline
Task time × frequency = monthly workload, computed in three states: what it costs today, what it should cost after the Mapping above, and the gap between them.
≈40hrs/mo
Current — fully manual baseline
≈8hrs/mo
Future — human hours after Mapping (exceptions only)
≈32hrs/mo
Capacity released — ≈0.18 FTE, redeployable without adding headcount
Planning & tech stack
Planning
PTM Priority sequences the build — the two Priority 5 tasks (matching, diagnosis) get built and validated first, since they carry the most workload; Priority 2–3 tasks (extraction, posting) are lower-risk to automate and follow once the core match logic is proven.
Tech stack
Reads and writes to the existing accounting system's bank feed and invoice ledger directly — no new system of record. Exception notifications route to the AR Lead's existing inbox, not a new dashboard they have to remember to check.