- AI
- Compliance
- Design Systems
Vendor Accreditation, redesigned for an agentic workflow
I redesigned Brighte's entire vendor accreditation experience (the vendor-facing form and the internal review portal) around a new AI-driven workflow, so we could vet green-energy installers deeper and faster at the same time.
Context
For Brighte, an Australian green-energy finance company, to fund a solar install or a heat pump, the vendor doing the install has to be accredited first. Accreditation is our own internal check to make sure we only partner with high-quality vendors and providers of green-energy services and equipment. It's a commercial vetting decision. We don't issue a certification. We run a deep set of checks across credit, fraud, biometrics, licensing, and reputation. We also check against government-led accreditations like NETCC (the New Energy Tech Consumer Code) and Solar Accreditation Australia. Those inform the decision but don't define it.
I picked this up at the start of December 2025, about a week after I joined Brighte. Brighte's network depends on trustworthy vendors, but the old vetting was slow enough that thoroughness was bottlenecking growth. The bet was that we could go deeper and faster together by handing the volume work to an LLM and keeping human judgment for the edge cases.
The problem
The old process took up to a month, lived across four different systems, and consumed about 58 minutes of manual work per application from the accreditation team. By mid-2025 there was a backlog of about 80 applications. The Accreditation Manager was spending an extra 1 to 1.5 hours a day just reviewing escalations from offshore agents.
What worried me most was that about 56% of accredited vendors never wrote a single deal after we'd put them through the whole thing. We were spending hours onboarding vendors who never went on to trade with us.
It was opaque on every side. The accreditation team tracked director biometrics manually in a Monday-morning spreadsheet, and pass / refer / fail logic lived in people's heads and shared sheets. The sales team were, in their own words, flying blind. They had no idea when contracts had been sent or signed, so every status update was a Slack ping. The vendor experience was just as opaque. The form sat on legacy CakePHP and didn't capture half the data needed for downstream automation, and after submission the vendor heard nothing.
My role
My role was Product Designer, and I became the design-system custodian along the way. This ran with a strong cross-functional team: roughly 5 engineers, a 4-person product/design/BA pod that I was the designer in, and key contributors across the accreditation, sales, and risk and compliance teams. So here is what was mine and what wasn't.
What I owned end-to-end:
- The vendor-facing accreditation form (multi-step, mobile-first, 7 sections)
- The internal admin portal V1 (stakeholder-reviewed December 2025) and V2 (incorporating the agentic workflow results)
- The full vendor email suite (welcome, reminders, expiry warnings, approval, declined, multi-director confirmations)
- The role-based permission model across three internal roles (Admin Ops, BDM, Admin)
What I influenced but didn't own: the agentic workflow architecture itself was engineering's work. I was in the room shaping how its results would surface in the portal so admins could decision off them. Process changes like moving biometrics before assessment instead of after were a sales and accreditation team call that my design supported.
The decisions I personally drove were the five below: designing the form for AI consumption, building one adaptive portal instead of three products, warning instead of blocking on edge-case data, requiring a note on every status change, and showing contract-signing status per director.
If you ask me which of the outcome numbers are "mine", I won't carve them up. I worked extremely closely with engineering on this and I don't claim sole credit for the results. To me, product design is the collective product. The screens, flows and surfaces are one part of it. Those numbers belong to the pod that shipped it. What I'll stand behind is the decisions above and the part they played in making those results possible.
Approach
I started about a week into the job, so the approach leaned hard on questions and on the team. I drew from two structured discovery workshops held in November 2025 with the accreditation team and the sales team. I also had 2023 historical data: 1,093 applications, 65% never accredited, and 43% of those who did get accredited never submitted an application.
The decision that shifted direction was reframing the brief. The original ask was "redesign the form and the portal." Then I saw the agentic workflow engineering was scoping (30+ checks across 10+ data sources, run by an LLM, kicking off automatically once a vendor submits). After that I started treating the form as the data layer for an agentic system.
That changed how I designed it. Every field, label, validation, and conditional path had two readers: the vendor filling it in, and the LLM that had to do something with the answer downstream. If the form let a vendor type "approx 4 yrs" into a "Years of Trading" field, that is a data problem, and it breaks every check that depends on it. So the form captures clean, structured, machine-readable data without feeling like a tax return to the vendor. ABN lookups pre-fill where possible. Conditional logic shows only the questions that matter for that vendor's size and category. Edge cases get warning states instead of hard blocks.
Collaboration & method
With engineering and product: I worked closest with the Tech Lead, the PM, the BA, and the accreditation specialists, who gave me a lot of context early. My main work with engineering was where the form met the agentic backend, and where the backend results met the portal. That meant designing how check outcomes surface so a human can decision off them fast.
A design decision there that I'm proud of, and that most people wouldn't notice, was how the summary was weighted. Instead of laying the raw results out flat, I weighted the 41 data points the checks produced by how the accreditation team made their calls. The most decision-relevant signals surfaced first. The goal was to inform the decision, not to make it for the team. It's a useful injection of information that helps them decide quickly, and their judgment stays theirs. The longer plan is to keep refining that summarisation and the decision engine underneath and cut time-to-decision further. Eventually we want to automate the clear-cut cases and roll the same pattern out to other products, with a human staying in the loop for anything that isn't clear-cut.
Design systems showed up in two places. Inside the project, the admin portal had to stay coherent as one product across three permission levels, which is a systems problem more than a UI one. Outside it, our Figma design system was drifting from what was in build and costing engineering time every sprint. So I started aligning the two in parallel, regardless of whether I was the designer on a given project. A colleague recognised it directly: "Thank you for the amazing, hard work you've put in into updating the design system in Figma! It's going to make life so much easier for both designers and developers. Instead of leaving things semi-functional as they were you called the ball and made it happen."
AI showed up in the product and in my own workflow. The product itself runs on an agentic LLM workflow built in n8n by engineering, doing 30+ checks across 10+ sources in under 4 minutes. Separately, at the time of this project (just before Claude became more prominent for us) I'd built a custom tool in Lovable.ai running on an OpenAI API key to speed up my UX/UI decisions. Because I started this project within a week of joining, I built it to carry the context of our existing design patterns and design system. That way it could help with first-draft copy and first-pass designs while I got up to speed. I don't use that tool anymore. As the company shifted from a ChatGPT focus to Claude, and Claude's capability grew, I migrated many of my own GPTs and custom tools into skills and chat-interface webapps in the Claude suite.
Constraints & tradeoffs
The defining constraints were regulatory/audit, a part-built backend, and time.
- I designed the form for AI consumption as well as for humans. I minimised free text, used structured selects, and blocked ineligible entity types from progressing. The cost is that the form looks slightly more "regulated", with stricter validation and fewer free-text rescue valves. We took that on because dirty data downstream (a re-run check, or worse a wrong decision) costs far more than asking a vendor to be precise.
- One UI serves three roles instead of three separate products. A permission matrix governs what each role sees on the same underlying screen. It was harder to design and QA, but permissions can change without redesigning the UI, and a fourth role would be an extension of the same screen. V1 cleared stakeholder review with zero requests for separate role-specific products.
- Edge-case data gets a warning instead of a block. A sub-6-month ABN, a trust account without a deed, or a BSB not in the lookup raises a warning and flags the application for manual review. The team picks up slightly more flagged cases as a result. That was fine because manual review is what they're set up for, and application abandonment isn't.
- Every status change requires a note. Notes are mandatory, and system-generated notes are auto-added for non-human events like 45-day auto-expiry. It costs a few extra seconds per action and gives a fully timestamped, auditable history in return. This came directly from the Risk and Compliance review.
- Contract-signing status is shown per director on multi-director applications, instead of one binary state. That means more states to maintain. It was worth it because chasing "who hasn't signed yet" was the BDMs' most-cited pain point.
A backend constraint shaped the work too. I was designing for an agentic backend that wasn't fully built. So I had to design the optimistic state (result is back, surface it) and the fallback state (manual review required, queue it) at the same time.
What shipped
The platform launched in April 2026 with four interconnected pieces:
- A self-serve vendor form, mobile-first, with ABN lookup, save-and-continue, structured fields built for downstream automation, and a five-stage drop-off re-engagement email sequence.
- An agentic accreditation workflow running 30+ checks across credit, fraud, biometrics, licensing, and reputation in under 4 minutes. Thresholds adapt to business size and entity type, and it surfaces pass / flag / fail results and explanations instantly.
- An admin portal with decisioning assistance: a summary panel surfacing the most material check results, a full audit trail, and reinstatement flows for declined or expired applications.
- Real-time HubSpot pipeline sync, so BDMs see live deal stages, with vendor accounts auto-creating in FinPower and the internal Portal on approval.
Outcome
Headline improvements:
- Approval to accreditation: 17.5 days down to 0.5 days, 97% faster, driven by sending vendors their contract at the point of approval instead of after biometrics.
- Time to sign: 4 days down to 0.5 days, 88% faster, with 70% of vendors signing the same day they receive the contract.
- Decisioning: 58 minutes of manual work per application replaced by a workflow that runs in under 4 minutes.
Current funnel, dashboard period ending 3 June 2026:
- 352 vendors started the form and 315 submitted it, an 89% form completion rate.
- 206 completed biometrics, a 65% biometric completion rate within 7 days of submission.
- 208 applications reviewed, of which 84 were approved, with an information-request rate of about 50%.
- 83 contracts signed.
- 9 applications withdrawn after submission, and 9 approved but expired without signing inside the 45-day window.
Evidence beyond the numbers came from two places. From the team, a colleague recognised the work twice: "Thanks for your work on the discovery and design of the Vendor Onboarding project, this way of working makes work fun and leads to impact, amazing to see the new onboarding screens come to life so quickly, grounded in vendor and sales needs," and separately "thanks for bringing the product design momentum to accreditation."
From the vendors: about a month after release we spoke to 8 vendors (primarily for another project, but I used it as a chance to get feedback on this one too). Tradies don't use many words, so it wasn't effusive. The consensus was that the form was smooth and easy and they knew what to provide. The feedback led to a few small tweaks to the form and the follow-up comms, to make it clearer what a vendor needs to do after they submit.
Targets still in flight (these are targets, not results, because I don't have measured results yet): under a week end-to-end, a 50% reduction in team time per application, and over 70% activation on accredited vendors, up from the 56% who never wrote a deal.
Reflection
What I'd do differently: I'd involve the offshore accreditation specialists earlier. The most nuanced decisions came from the people doing the work day-to-day, not the team leads. For instance, learning that a biometrics resend costs $0.15 versus $6.77 for a new link shaped how I designed the resend flow, and I picked that up later than I should have. I'd also write a clearer assumptions document up front for the part-built backend.
A couple of things didn't work. We originally put weight on vendor reputation (social media, Google reviews, website quality). That was unstructured, unreliably scraped data, and it produced flagged issues that were either non-issues or outright hallucinated. Clean, structured data matters as much as ever with AI, maybe more, so we leaned harder into structured input fields on the form. We also planned an "intelligence" character called Lumen to guide the internal team, and dropped it. A characterful assistant risked being taken at face value in exactly the cases where the AI hallucinated. We simplified down to plain summary boxes that give an overview and leave the judgment with the human.
It's live and still iterating. We've made around 15 iterations since launch. We deliberately built in a two-week fast-follow window because we didn't want to wait until it was perfect to release. The point of that window was to ship the changes that had real impact and skip the "I think it would be nice if..." ones.
Want to go deeper?
Ask the site about this project. It answers from the real work - what shipped, what didn't, and how I'd do it again.