A municipal purchasing office is a small team carrying a large liability. Every competition has to be fair, every award defensible, every contract insured and current, and every record findable when an auditor or an access to information request arrives. The team we worked with was doing all of that through email, phone calls, a shared network drive, and spreadsheets.
They told us where it hurt in three sentences. They spent their days chasing information and re-explaining the process. They could never be sure which draft of a document was the current one. And they tracked insurance, workers’ compensation clearance, and budgets by hand, in scattered spreadsheets.
The work sat inside a wider electronic records management rollout, which gave us the tools: SharePoint, Microsoft Lists, Power Automate, and Power BI, all already licensed. No new platform was purchased. This is what we built, and how it was decided.
Start from the gaps
A gap analysis already existed from two years earlier. It had been read, agreed with, and shelved, which is the usual fate of a gap analysis. We turned it into a working instrument: a traceability matrix where each of the 20 gaps carries its reference back to the original analysis, the stage of the journey it belongs to, the solution now in place, the outcome the team wants, and the data insight it should unlock.
Under the gaps sit 59 user stories, written for real roles: the department staff member who buys something twice a year, the buyer, the manager of purchasing, the contract administrator, finance, legal, records. Every story names its gap and carries a status. When leadership asks what is done, the answer is a filter, and nobody has to assemble a slide.
The first gap on the list was the one underneath all the others: procurement information was spread across systems with no shared model. So the first deliverable was a data dictionary of about 65 terms, each defined from the organization’s own procurement policy and protocol, with the page reference. Arguments about what “procurement value” means stop when the definition points at the policy.
One journey, six stages
We described the work the way the team already thought about it, as a journey a request takes. For each stage we wrote two columns in their language: what is frustrating today, and what changes for you.
Delivery is phased through a pilot. Self-serve information and version control went first because they removed the most daily friction for the least change; intake and triage followed and are now live. Competition was already handled by an existing e-bidding tool, so we left it there and connected it to the case file.
Most projects skip Stage 0. Before a request is ever made, staff have questions: is this supplier insured, which template do I use, what is the threshold for three quotes. Each of those questions was a phone call. A self-serve hub with live supplier status and a policy library that staff can click through took a measurable share of interruptions off the buyers before any workflow was automated.
The backbone: three lists that point at each other
The design decision that matters most is also the least visible. Supplier data from the finance system, enriched by the purchasing team, is the baseline. Every intake links to a case file. Every case file links to its contracts. That chain is what makes the whole story traceable and reportable.
Access is deliberate. A matrix sets what each of eight roles can do with each list, from "contribute only" for a department requester to on-demand access for legal, provisioned and revoked by purchasing.
The contract library was the biggest relief
Before, contracts lived in email and on the network drive. There were several copies held by several people, and finding one meant asking purchasing. Nobody could see who administered a contract, or who else in the organization was already using the same supplier.
Now there is one library and one copy. Purchasing is the custodian and buyers load the full record when a contract is created:
| Kept with every contract | Tagged on every contract |
|---|---|
| The contract and its amendments | Supplier |
| The competition file that led to it | Contract value |
| Annual spend report from the finance system | Start, end, and extension dates |
| Supplier business licence | Department, division, section |
| Workers’ compensation clearance | Contract administrator |
| Insurance certificate | Buyer |
| An issue log for anything that surfaces | Notification window for renewal |
Tagging is what turns a filing system into an information system. Because every contract carries its supplier, evaluations roll up across contracts, so the team can see how many contracts they hold with a supplier and how that supplier performs against the same criteria each time. Because every contract carries value and dates, spend breaks down by department, division, and section, and renewal notices go out automatically inside the notification window. The periodic report to Council, which used to be assembled by hand, is generated from the library.
Rollout is careful on purpose. Contract administrators go first, because their renewal protocol needs the full record and everything they need is already loaded. Evaluations are sensitive, so those documents stay with contract administrators and purchasing. Everyone else gets a metadata-only view: what each contract is, what it is for, and its value, which is enough to stop departments from procuring something the organization already has under contract.
Approvals that live in inboxes
We catalogued eight internal sign-offs that give authority to proceed without being legal instruments: budget pre-approval, legal review, standard and non-standard award approval, emergency purchase authorization, purchase order issuance, amendments within scope, and supplier suspension. Every one of them ran on email.
The symptoms were predictable. There was no authority matrix, so staff emailed around to find out who approves what at which value. Budget confirmation went to finance with no real-time check, so postings stalled. Approvals sat in threads with no queue and no visible status, and the audit trail was whatever could be reconstructed from mailboxes. The business case for routing them in one workflow was short: an authority matrix that picks the approver automatically, a timestamped trail fit for audit and access requests, and cycle times that no longer depend on whose inbox is fullest.
Dashboards built on exceptions
The reporting layer in Power BI has a view for each audience: a buyer’s own workload, all case files, all contracts with expiry and compliance at a glance, and a manager view of workload, pipeline, and aging across the team.
If I could keep only one view, it would be the exception report. It lists data discrepancies, highest severity first: a contract with no supplier tag, a missing end date, an insurance certificate that has expired or was never loaded. A dashboard that only shows healthy numbers trains people to stop looking. One that tells a buyer exactly which three records need fixing this morning becomes part of the job.
Processes kept as data
The contract administration process, the reporting cycle, and supplier evaluation were each written as a table of steps: one row per step, with its owner, shape, next step, duration, and system. The three processes call each other, so a step in contract administration opens supplier evaluation as a sub-process. When the team changes a step, they change a row, and every map and handout built from that table follows.
What the team got back
| Before | Now |
|---|---|
| Requests by phone, email, and assorted forms | One form, one queue, automatic confirmation |
| Nobody sure which draft is current | Co-authoring with full version history |
| Insurance and clearance tracked in spreadsheets | Status on the supplier record, exceptions flagged |
| Contracts in email and on the network drive | One library, one copy, fully tagged |
| No warning before a contract lapses | Renewal alerts inside the notification window |
| Council report assembled by hand | Generated from the library |
| Retention applied by memory | Retention applied by metadata |
The last row is the one the records team cares about, and it is the reason this work belonged inside a records management rollout in the first place. When every document lands in a library with the right metadata, retention and disposition apply themselves, and the audit trail is a by-product of people doing their jobs.
What we would tell another purchasing office
Use what you own. Every component here is part of a Microsoft 365 licence most public bodies already pay for. The investment was in analysis and design, and none of it went to software.
Let an old gap analysis earn its keep. Tracing every story and every deliverable back to a gap that leadership already accepted removed most of the debate about scope.
Sequence by relief. The team felt the benefit of self-serve information and version control within weeks, which bought the patience for the harder stages that follow.
And treat the process itself as data. Once steps, owners, and systems live in a list, the documentation, the maps, and the training material all come from the same rows, and they stay current because there is only one place to change them.