Home / Case studies / AI Procurement Automation Across Seven Supplier Websites
Case study · Construction · AI agents & machine learning
AI Procurement Automation Across Seven Supplier Websites
Before AI procurement automation, a UK construction & building materials company checked supplier prices by hand & found price changes only on invoices. Brainy Neurals built a platform that uses live web scraping & machine learning to rank supplier prices & forecast demand. The platform’s 12 modules read the company’s existing database, so buyers search seven supplier sites & the catalog with no migration. One search now returns ranked prices, & a buyer assistant answers spend questions from live data.
7
Supplier sites in one search
No migration
Existing database kept in place
Scheduled
Supplier price changes flagged
Published October 2026
At a glance
AI procurement automation gave a UK construction materials company one ranked view of supplier prices, stock & demand.
What problem did this solve?
Buyers at a UK construction materials company checked supplier prices by hand & found changes on the invoice. Stock ran short or sat unused with no early warning.
What did Brainy Neurals build?
Brainy Neurals built a 12-module procurement platform for a UK construction materials company. One Python service searches, compares, forecasts & answers questions over live data.
What changed after it went live?
One search now returns ranked prices across seven supplier sites & the catalog. Price drift, duplicates, dead stock & low stock all surface on their own.
Who else could use this?
Any team buying from many suppliers against its own records fits this pattern. Manufacturers, hospitals, warehouse operators & retail chains all face the same problem.
Industry
Construction
Sub-industry
Building materials procurement
Client
UK construction materials company
Engagement
AI procurement platform
Timeline
Not disclosed
Capabilities
Generative AI, ML & vision
Delivery
Project-based delivery
Why was procurement still done by hand?
Procurement stayed manual at this UK construction & building materials company because the right tooling had never been built. The company buys for several projects & sites at once, & buyers, storekeepers, project managers & administrators touch procurement every day. AI procurement automation needed pieces from AI agent development to live price scraping, & none of them existed yet.
- A buyer opened each supplier website in turn & keyed the prices into a sheet for every order.
- A price change showed up when the invoice arrived, weeks after the decision it should have shaped.
- The same product sat in the catalog twice under slightly different names, & both versions got ordered.
- Unused stock sat in stores for months, tying up cash nobody had put a number on.
- A shortage surfaced when a crew reached for the item, too late to reorder in time.
None of these problems were unusual for construction buyers. A 1987 ASCE study found integrated materials management pays back in labor productivity & surplus stock[1]. The same study also linked it to better cash flow.
What do buying teams try first?
Buying teams have four common routes to supplier price comparison, & each one is reasonable.
Each common route stops at a wall that the custom AI route clears.
Browsing & spreadsheets
What it gets right
Zero new tooling & full control
Where it stops
Hours per check & stale by afternoon
Who it still suits
Occasional buys & small catalogs
One supplier portal at a time
What it gets right
Accurate live prices on that one site
Where it stops
No view across suppliers
Who it still suits
Single-supplier relationships
Off-the-shelf procurement suites
What it gets right
Broad workflow coverage from day one
Where it stops
No live market prices & a long migration
Who it still suits
Greenfield stacks & standard workflows
Custom AI layer, our route
What it gets right
Live prices & forecasts on the existing database
Where it stops
Weeks of scraper & matching work
Who it still suits
Teams keeping their system of record
Price gaps between online sellers are real & measurable. A landmark online retail study found prices for identical books differed across sellers by 33% on average[2].
How we designed the AI procurement automation
Brainy Neurals designed the platform as one Python service, with one module for each business function. The 12 modules share the company’s existing database. They also share a local cache & a semantic index, & nothing was migrated because the trusted database stayed exactly where it was.
One search asks every source at once, & the buyer sees one ranked answer.
Every search draws on the internal database, the semantic index, the cache & seven live supplier sites.
One search asks every source at once, & the buyer sees one ranked answer.
The first decision was where market prices would come from. We rejected waiting on supplier data feeds, because these trade suppliers publish prices only on their websites. So the platform scrapes seven supplier sites live, rendering each page in a headless browser, a browser that runs with no screen.
The second decision was how far generative AI development would reach. A vision model names a product from a site photo, & a language model answers buyer questions.
Dense embeddings, number patterns that capture what words mean, let search match products when spelling differs.
Demand forecasting stayed classical machine learning, trained only on the company’s own order history. The models were the easy part, & the matching, isolation, caching & scraping around them made the build work.
The technology stack we used
The technology stack for this build had to earn its place beside a live operational database. We chose each layer for what it adds without a migration, from the vector index to the scrapers. The same RAG development layers carry our other retrieval builds, with different data underneath.
Data & scraping
Operational database
The company’s existing database
Why
Procurement truth lived there
What we ruled out
A parallel store
Supplier scraping
Headless browser scraping
Why
Pages render in JavaScript
What we ruled out
Raw page fetches
Models & matching
Buyer assistant
A language model with tools
Why
Questions become read-only queries
What we ruled out
Canned report menus
Photo recognition
A multimodal vision model
Why
Names products from site photos
What we ruled out
Barcode lookup only
Semantic search
Dense embeddings & a vector index
Why
Meaning survives bad spelling
What we ruled out
Keyword matching alone
Demand forecasting
Gradient boosting on order history
Why
Learns demand for each product
What we ruled out
Fixed reorder points
Name matching
Token-based fuzzy scoring
Why
Catches near-duplicate names
What we ruled out
Exact matches only
Application & delivery
Application
One Python service
Why
12 modules that ship alone
What we ruled out
One app per function
Background work
An async in-service queue
Why
Scraping never blocks buyers
What we ruled out
Blocking scrape calls
How does one search get answered?
One buyer search runs through six steps, start to finish, in the same order every time.
- A buyer types a product name, or sends a photo that the vision model turns into one.
- The service checks the internal catalog first, by exact product name & code.
- Dense embeddings search the semantic index for products that match by meaning when spelling does not.
- Scrapers fan out to seven supplier websites in parallel, each in its own process on a shared clock.
- Results merge into one list, with duplicates removed by product code & prices sorted from low to high.
- The cheapest in-stock option is flagged as the recommendation, with the saving already worked out.
The catalog paths answer first while the live scrape runs in parallel, & the merge waits for both.
Photo searches join at step one, & every later step treats them the same as typed searches, with no spreadsheet anywhere in the flow.
What nearly stopped the build?
Three problems nearly stopped the build, & they arrived in the order below.
Two event loops in one process
The scraping framework runs its own event loop, the cycle that schedules its work, & so does the async service around it. Put both in one process & the second one dies. The first combined run proved that within minutes.
Search that came back empty
Exact matching returned nothing for products plainly sitting on the shelf. The catalog held the same item twice under different names, & supplier listings spelled it a third way. Search that trusted the data kept coming back empty.
An assistant that lost the thread
The buyer assistant answered its first question well & its tenth badly. Every tool call added text to the running conversation, & the model began losing the thread. Published research agrees that models read long inputs unevenly, with accuracy dropping for detail buried in the middle[3].
Weeks like these are why clients hire AI developers with this experience rather than paying for each lesson twice.
How we fixed each of them
Each of the three fixes now reads as a single line, though none was found in an afternoon.
Isolation
Every scraper now runs in its own child process & pipes results back to the service. A shared timeout closes slow ones, so a stuck site costs seconds. The event-loop conflict never came back after that change.
Matching
Search became a ladder that tries exact matches, looser text matches, fuzzy scoring & finally meaning. A duplicate scan now scores the whole catalog, & new products are checked before they’re saved.
Fuzzy scoring itself is an old idea, & spell checkers have ranked near misses this way for decades.
Context
The assistant now loads only the table schemas, the layout of each table, that its classified intent needs. Older tool messages are trimmed as the conversation grows, & the loop is capped. The tenth answer now reads like the first.
An AI proof of concept exists to surface exactly this kind of work before any promise is made.
What changed after go-live?
After go-live, AI procurement automation replaced five manual habits with checks that run on their own.
Price checking
Before
One supplier website at a time, by hand
After
Seven sites & the catalog in one search
Price changes
Before
Discovered on the invoice
After
Flagged by scheduled monitoring
Duplicate entries
Before
Found by accident
After
Scanned, scored & blocked at entry
Reordering
Before
Started when someone noticed a gap
After
Drafted from live stock & forecasts
Spend questions
Before
A manual report request
After
Asked in plain language & answered from live data
We haven’t published an hours-saved or spend-reduction figure, though the client reports faster buying decisions. A number we haven’t measured is a number we won’t print.
Day to day, a buyer decides from one ranked view instead of seven open tabs. Managers see dead stock by age, in 3, 6 & 12 month bands. A shortage now arrives as a drafted order, grouped by supplier.
Still comparing supplier prices by hand?
Tell us how your buyers check prices today & where stock goes wrong. We’ll reply with how an AI procurement build could fit your suppliers & your database.
What is running today
Today the procurement platform runs as one Python service over the company’s live operational data. The 12 modules sit behind a single API, & the company’s own frontend calls them through the working day.
Buyers across the company’s projects search, compare prices, check stock & question the data freely. One connection is staged for the next phase, the price write-back into the catalog.
Everything else runs now in Python, from the scrapers to the assistant, as a working example of AI in construction.
What would we do differently?
We’d change four things if we built this procurement platform again.
Assume the catalog is dirty first
We built exact search on data we trusted, & the data wasn’t clean. Search built on a clean catalog meets a dirty one in production. Fuzzy & semantic layers should have been in the first cut.
Give every scraper its own process
We found the event-loop conflict by running into it. Isolation was always going to be the answer, so it should have been the starting point.
Trim the assistant’s memory early
Context grows one tool call at a time, & answer quality falls the same way. We now prune & cap it from the very first prompt.
Sort database access before you build
One module still waits on production credentials to write prices back into the catalog. Chasing that access in week one would have cost nothing.
Search built on a clean catalog meets a dirty one in production.
Where else does this pattern fit?
AI procurement automation fits wherever buyers still check supplier prices one website at a time. It prices & forecasts what a company buys by linking its own records to live supplier data.
Manufacturing
Plants buying spares & consumables across sites
What changes in the build
New supplier scrapers & criticality-weighted forecasts
Logistics
Warehouse teams stocking packaging & parts
What changes in the build
Reorder points tied to throughput seasons
Healthcare
Hospitals stocking wards from framework suppliers
What changes in the build
Expiry dates join the dead-stock logic
Retail
Chains buying store supplies from many wholesalers
What changes in the build
Store-level forecasts & promotion-aware demand
Hospitality
Groups supplying sites from rotating supplier lists
What changes in the build
Menu cycles drive the forecast features
Porting the pattern takes new supplier scrapers, a retrained forecast, fresh reorder cutoffs & a duplicate scan.
Questions buyers usually ask
Buyers usually ask these questions before they commit to a procurement build.
How it works
Can AI compare prices across supplier websites automatically?
Yes, when the sites publish their prices publicly. Scrapers driving a headless browser read each product page, & the results merge into one ranked list. You see the cheapest in-stock option flagged, with the saving already calculated.
How does AI demand forecasting work in procurement?
A model learns from the company’s own purchase history, including seasons, order frequency, gaps between orders & recent demand. It then predicts demand day by day across the forecast horizon. Sparse or irregular history lowers the confidence score it shows beside each forecast.
Can an AI assistant answer questions from our own database?
Yes, & the guardrails matter more than the model. The assistant turns a plain-language question into read-only database queries, runs them & writes the answer in plain words. It never gets write access, so it can inform a decision but never make one.
Time, cost & rollout
How long does it take to build AI procurement automation?
A working first module on your own data usually takes a few weeks. Scrapers, matching, forecasting & the assistant then land one module at a time. A platform of this size is a phased build measured in months, & each phase ships something buyers use.
How much does an AI procurement system cost?
The cost depends on supplier count, module list, data quality & what already exists. Brainy Neurals scopes it from a short call & a look at the database, then quotes a fixed price. An AI readiness assessment tells you first whether your data can carry it.
Does this work with an existing ERP or database?
Yes, & that question shaped the design. The platform reads your system of record in place & adds AI around it, with no migration. Write-backs come last, once trust is earned on read-only ground.
What does your buying team need next?
Tell us which suppliers you buy from, how prices get checked & where stock goes wrong. We'll reply with what a procurement build would need for your team.
Services behind this case study
Six Brainy Neurals services went into this build, & each one has its own page.
AI agent development
A buyer assistant that queries live company data with tools & answers in plain language.
Generative AI applications
Vision, language & embedding models applied to one workflow, from photo search to answers.
RAG development
Semantic product search over a vector database, tuned for messy real-world catalogs.
Computer vision development
Photo recognition that names an unknown product from a site photo & starts a search.
Hire AI developers
Engineers who extend your team for the weeks when scrapers & matching fight back.
AI in construction
Procurement, planning & site systems for builders whose data lives in one database.
An AI proof of concept is the fastest way to test the approach on your own data. AI consulting helps sequence the modules & phases. An AI readiness assessment shows whether your records can carry a forecast, & the industries hub maps where these systems run.
Similar case studies
Three more Brainy Neurals builds shipped into live environments rather than demos.
Case study
Overhead Line Geometry Measurement
Stereo vision measuring live wire geometry from a moving train, processed on board.
Case study
AI Diet Assistant for Gastroenterology
Clinical dietary guidance generated under review gates, running in a live healthcare setting.
Case study
Personalised AI Meal Planning for Chronic Care
Meal plans built from messy personal health records, with every suggestion grounded & reviewable.
Cite this case study
Use the reference below to cite this case study in reports or research.
Patel, Mitesh. AI Procurement Automation Across Seven Supplier Websites. Brainy Neurals, September 2026. https://brainyneurals.com/case-studies/ai-procurement-automation/
Sources cited on this page
[1] Bell LC, Stukhart G. Costs and Benefits of Materials Management Systems. Journal of Construction Engineering and Management. 1987,113(2):222-234. DOI 10.1061/(ASCE)0733-9364(1987)113:2(222).
[2] Brynjolfsson E, Smith MD. Frictionless Commerce? A Comparison of Internet and Conventional Retailers. Management Science. 2000,46(4):563-585. DOI 10.1287/mnsc.46.4.563.12061.
[3] Liu NF, Lin K, Hewitt J, Paranjape A, Bevilacqua M, Petroni F, Liang P. Lost in the Middle: How Language Models Use Long Contexts. Transactions of the Association for Computational Linguistics. 2024,12:157-173. DOI 10.1162/tacl_a_00638.