Case study

Once For All helps organisations in the built environment assess and manage supplier compliance. Through an online portal, suppliers provide evidence for requirements such as public liability insurance, health and safety accreditations, certifications, policy documents and self-declaration questionnaires.

The process was slow and repetitive. Suppliers often already held the required information in their documents, yet still had to find and re-enter it, requirement by requirement. I led the design of an AI-assisted experience that reads those documents, proposes answers and lets suppliers review and confirm every value before submitting.

Completing a single requirement could mean opening a PDF, locating the right details and copying each one into a form — provider, policy number, cover amount and dates — then repeating the process across many requirements. This made completion tedious and error-prone, contributing to drop-off before suppliers finished.

Verifiers then checked each submission manually, adding delay and leaving more room for inconsistent decisions.

I partnered with a senior UX researcher, who led supplier interviews and analysis, and translated the findings into design implications. We also reviewed 14 of the highest-volume requirements to identify the information suppliers had to provide, where they hesitated and which fields generated the most corrections.

The strongest finding was not simply a need for speed; it was a need for trust. Suppliers needed to see the source of each answer and retain control of the final submission.

Trust depended on visibility and control: suppliers needed to see every proposed answer, understand its source and edit it before submitting.

We set a clear boundary: the system would do the repetitive work of reading documents and proposing answers; the supplier would review them and decide what to submit. Four principles followed from that boundary.

• Show provenance. Every extracted answer identifies the source document it came from.
• Keep it editable. All proposed answers remain editable before submission.
• Make state obvious. Every stage — from upload and extraction to review and exceptions — is clearly signposted.
• Fail honestly. If the system cannot extract a value, it leaves the field unresolved instead of guessing.

The supplier experience comes down to three steps. The screens below use an anonymised example company, “First Access Ltd”.

1

Upload

The supplier adds the documents they already hold to a requirement. The form shows which information still needs to be provided.

1 2

2

Extract

The system reads the uploaded documents and extracts values such as the provider, insured company, policy number, cover amount, start date and expiry date. It then populates the relevant fields.

1 2

3

Review

Each proposed answer is linked to its source document. The supplier checks the answers, corrects anything that needs attention and submits the requirement.

1 2 3

Verifying a requirement spans three operational surfaces: internal configuration, the supplier's upload–extract–review flow and the verifier's review and exception handling. Buyers do not need a new screen; they see the verified result in their existing supplier views. We therefore planned delivery as a sequence of capabilities rather than one large release.

The first release, shipped in March 2026, focused on the supplier flow for public liability insurance: upload, extract, review and submit. This gave us a complete, real-world supplier slice to learn from before expanding to more requirement types and the verifier workflow.

Interactive

Follow one requirement through the service — choose a step to see who is involved, what each stage enables and what shipped first.

1 ConfigureSet the rules 2 SupplierUpload & review 3 VerifyReview & approve 4 BuyerView the outcome

Foundation

The internal configuration team defines what each requirement asks for and how it will be assessed.

• Defines requirement types and the fields to capture.
• Sets the rules that extraction and verification follow.

Open interactive screen

Step 1 of 4 Next: Supplier

The first release shipped in March 2026, so it is too early to claim outcomes. We are tracking supplier metrics now; verifier metrics will follow when that workflow ships. These are evaluation signals, not confirmed results.

The hardest design problem was not extraction itself; it was making the automation trustworthy. Accuracy matters, but people also need to understand where an answer came from and retain control of the final submission. In the next iteration, I would keep strengthening that balance: make the evidence easier to inspect, make uncertainty explicit and always leave the final decision with the person.