Buyers pick the supplier whose part fits best.
ADAPT, a 6-month proof of concept at digital.enterprises. 2 enterprise buyers signed on to build it with us, and it helped unlock a ~$220K QRDI grant.
Overview
ADAPT is an AI-powered marketplace for MRO procurement in Qatar's oil and gas sector, built at digital.enterprises to connect buyer and supplier ERPs in a single platform so that a request for a maintenance part can be matched to suppliers who actually have it, and the order completed end to end rather than across days of emails, spreadsheets and phone calls.
It has to work for 4 groups at once: engineers who need parts fast, procurement officers who need every order compliant and auditable, suppliers who want real demand instead of dead-end requests, and executives who measure it all in uptime and cost.
This effort to digitally orchestrate MRO operations in the sector brought 2 enterprise buyers and 1 supplier on board to help us build it. Over 6 months we ran a PoC (proof of concept) together, which later helped us unlock a QRDI Phase-I Small Business Innovation Grant (SBIG) of around $220,000.
2
Enterprise buyers
1
Supplier partner
6
Months, idea to funding
~$220K
QRDI Grant
The problem
An oil refinery runs on thousands of small parts. Valves, gaskets, seals, instruments. None of them look important until one fails — and when one fails, the plant stops. A stopped plant costs millions of dollars a day.
So you'd expect buying those parts to be a solved problem. It isn't.
The buying company has an ERP that knows what it needs. The supplier has an ERP that knows what it has. Both sides already hold the answer. But the two systems don't talk, so people fill the gap by hand.
One request turns into a dozen emails and a spreadsheet someone retypes. When a part fails during a shutdown, engineers start phoning around asking who has stock in the country. Certificates arrive days later as PDF attachments. Everyone is busy, and nobody can see the whole picture.
Sourcing platforms moved this online but kept the shape of it — send a request, wait, compare, choose. Analytics tools can tell you where the delays are, but they can't place the order.
It started with someone who had lived the problem.
Our CEO, Adil, had spent 25 years leading supply chain at Shell Qatar. He knew this gap better than anyone. What he didn't have yet was a product, or a single customer. I joined as the 2nd hire.
Adil’s brief
Before
Procurement ran on email
After
One click to a PO
What I created
A smarter procurement flow
1Trigger · low-stock alerts
2Discover · open requirements
3Search · type a spec
4Decide · speed, cost, risk score
5Order · Quick Order
We had to sell a product that didn't exist yet.
With no customers, we needed a reason for buyers to sit with us. So I designed the pitch deck and the prototype side by side with the PM, from the internal stakeholders’ brief. The first few pitches made it clear a sales deck alone wouldn’t win anyone over.
What changed
From sales slides to proof
Rebuilt the deck in Figma with branding, real imagery, problem/solution flows, journeys and the technical architecture.
Ending on the product
Every pitch closed on the app screens I designed. That's when the room changed.
Better after every pitch
Each meeting was a test; the deck was revised on what landed and what didn't.
2 buyers signed on to build it with us.
By now the screens were doing the talking in pitch meetings. 2 enterprise buyers signed MoUs to run a PoC with us, and one of their approved suppliers came on board too.
What tipped it
It looked like their Monday morning
Clickable, filled with real data from Qatar’s market, solving their exact pain step by step.
Seeing, not just hearing
What the slides promised, they saw happening in the prototype, live.
Proof we were the right team
Seeing it work showed, there and then, that we could solve this.
The first designs won the clients. Now we had to build it for real.
The direction was right, but early screens only showed the surface. Building it meant going deep into every feature, flow and edge case, shaped by how each buyer really worked. Each did it a little differently, so the challenge was one shared core that still felt made for each of them.
What we assumed
What they actually do
So we changed the design
A good fit only gets a supplier shortlisted. Price and local value decide who wins.
Approve appears only at a 99% match. Anything lower goes to an engineer first.
Every part can be bought from a supplier on the approved list.
Approved lists name the makers. The local sellers who stock the parts often aren't on them.
AI searches beyond the vendor list when no one on it sells the part.
The ERP has every detail needed to buy a part.
About 1 in 10 requests needs photos or catalogues the ERP can't hold, so they go by email.
AI fills in missing details and writes them back to the ERP.
An order goes out as soon as the buyer picks a supplier.
Orders above a set value wait for a manager to sign off. Smaller ones don't.
Orders under QAR 5,000 become POs on their own. Bigger ones wait for the Project Manager, with stock held for 24 hours.
What we assumed
Buyers pick the supplier whose part fits best.
Every part can be bought from a supplier on the approved list.
The ERP has every detail needed to buy a part.
An order goes out as soon as the buyer picks a supplier.
What they actually do
A good fit only gets a supplier shortlisted. Price and local value decide who wins.
Approved lists name the makers. The local sellers who stock the parts often aren't on them.
About 1 in 10 requests needs photos or catalogues the ERP can't hold, so they go by email.
Orders above a set value wait for a manager to sign off. Smaller ones don't.
So we changed the design
Approve appears only at a 99% match. Anything lower goes to an engineer first.
AI searches beyond the vendor list when no one on it sells the part.
AI fills in missing details and writes them back to the ERP.
Orders under QAR 5,000 become POs on their own. Bigger ones wait for the Project Manager, with stock held for 24 hours.
First, we had to understand how they actually work.
Every two weeks we met the buyers' procurement teams. Each session followed the same loop, so the next one always started from something they could correct. Claude turned each transcript into a workflow diagram fast, but not always right.
The process loop · every 2 weeks
1
Prepare questions with the PM
2
Session with the buyer's team
3
Transcript into Claude
4
Workflow diagram
5
Review with team
revise until approvedrevise until approvedApproved
4 things we got wrong
— caught in review
First draft
Mixed up which team raises which request.
Corrected
Each request matched to the team that really raises it.
First draft
Added software the buyer had never used.
Corrected
Cut back to the tools they actually use.
First draft
Kept SAP's quote comparison step.
Corrected
Removed — that's the step ADAPT replaces.
First draft
Listed the wrong buyer actions.
Corrected
Reset to the 4 actions we agreed.
Add image
Question doc — one page
Add image
Workflow diagram sneak peek [blur client details]
AI draft
Claude's first draft of the workflow
My version
Your corrected version — with 1–2 notes on what you changed
What we built: the buyer side of ADAPT.
A buyer goes from an ERP request to a sent PO in one place — five steps.
- 1
Request arrives
Activities
Requests sync from the ERP, grouped by maintenance project.
- 2
Compare
Ranked suppliers
Every supplier scored on spec match and local value, with certificates, safety and delivery record one click away.
1 / 6
- 3
Decide
4 actions
Approve, view, send to an engineer for review, or run an emergency auction when nothing fits.
1 / 4
- 4
Approve
Smart approvals
Small orders become POs on their own; big ones wait for the Project Manager, with stock held for 24 hours.
1 / 2
- 5
Track
Order tracking
Every PO from raised to delivered, with supplier chat.
1 / 3
Also in the product
Master MM
Keeps store stock topped up and fixes vague ERP data with AI.
ViewCatalogue
Equipment, its parts, and what's due for maintenance.
ViewDeep dive
Finding the right supplier took RFQ emails, Excel and 2 separate reviews. Matching had to do all of it on one screen.
They emailed 3–5 suppliers, compared the answers by hand and waited for engineers to check the specs. So we built an AI match: it reads the request, checks every supplier’s part against the spec and scores the fit. Everything else starts from the match: approvals, reviews and auctions. If buyers didn't trust the score, they'd go back to email.
1
Ranked by fit, then local value
best match first, every supplier listed
2
Match score on every offer
98%, 94% — visible before opening anything
3
Lead time and stock up front
short stock shows in red
4
Action follows the score
Approve, or Send for review
The score decides the next step
99% +
Approve straight away
60 – 98%
Send to an engineer — each gap is a point to check
Below 60%
Run an emergency auction
No supplier
Search outside the approved list
How the match is built
1
Read the request
Pulls part, spec and quantity from the ERP request, plus photos and attachments.
AI2
Find candidates
Searches supplier catalogues and stock, beyond the approved list if needed.
AI3
Check every spec
Compares each spec line by line and flags every gap.
AI4
Rank
Best fit first, then local value and lead time.
Rules5
Show the proof
Buyer sees why each score is what it is, then decides.
BuyerDesigning an AI score buyers would trust
Never just a number
Every score opens to its proof: which specs matched, which didn’t, and where the data came from.
The score sets the next step
99%+ can be approved. 60–98% goes to an engineer. Below 60% goes to auction.
Gaps are shown, not hidden
Each mismatch is listed as a point for the engineer to check, so a 96% match is easy to review.
Edge cases it handles
If
Not enough stockOrder what the best supplier has, point to the next for the rest
If
Engineer declines a matchThe next best supplier moves up
If
Request too vague to matchMissing specs are filled in and written back to the ERP
If
Close but not exactThe buyer asks the supplier to confirm specs before stocking
Testing it
We’d already asked buyers about the flows several times. Then came the first hands-on test: one session with TRAGS over Teams, where two people from their procurement team used the live prototype while I watched and asked what they expected versus what they saw. We tested the main activity/matching screen in that session.
1
Usability session with TRAGS, over Teams
2
People from their procurement team
Live
Clickable prototype with real Qatar data
What they expected
To compare suppliers on price first, the way SAP's quote comparison does.
What they saw
Suppliers ranked by spec match, with price as one column among many.
Local value moved into the ranking.
Buyers judge suppliers on more than fit, and both buyers score local content in tenders. The default order became "Recommended": spec match first, then ICV, with price one click away.
We heard
In the session, price-first came from habit. In tenders, both buyers score local content (ICV), so fit alone doesn’t win.
So we decided
Rank by spec match, then ICV. Keep price one click away, not first.
In the product
A “Recommended” sort became the default on every request.
6 months later:
funded.
The PoC became the basis of a QRDI Phase-I Small Business Innovation Grant of around ~$220,000.
2
MoUs signed
~$220K
QRDI grant
What comes next
More suppliers: onboard the 20 suppliers both buyers nominated.
Smarter ranking: add price, alongside fit and local value.
Past the PO: carry the flow into goods receipt and invoices.
The supplier side: one place for suppliers to answer buyer requests, confirm specs or add a matching product, mark ex-works orders ready for pickup, update delivery status and upload invoices.
What I'm taking with me
3 things this project taught me.
01
A prototype that sells and a prototype that's right are different things.
02
AI drafts fast. People make it right.
03
Map the work before drawing screens.
Next case study
✓