Executive Summary

A fast-scaling European specialty distributor running purchasing across thousands of SKUs, thousands of suppliers, and six regional warehouses was buying almost entirely on spreadsheets and intuition. Purchase orders were triggered manually, communicated over email and fax, and generated only after stock had already run low.

Net Solutions was engaged to design and build a new procurement platform from the ground up: not a UI refresh on top of the existing ERP, but a new product, a forecasting and automation layer engineered to sit alongside it. At the center of the build was a proprietary forecasting algorithm that we designed, tested, and hardened in production to calculate exactly what to buy, when, and how much and to generate the purchase order automatically. This is the story of how that algorithm was engineered, and what it took to get a 100+ person buying organization to trust software with a decision they’d always made themselves.

Client Snapshot

  • Industry: Specialty retail & distribution
  • Scale at engagement: ~2,800 suppliers, ~64,000 active SKUs, 100+ buyer teams
  • Footprint: Six regional distribution hubs across the UK and Europe
  • Systems context: Legacy ERP as system of record; no native forecasting or automated ordering capability

The Problem We Were Actually Solving

This wasn’t a “build us a dashboard” engagement. The client’s growth had outpaced what a legacy ERP and human judgment could reliably coordinate:

No forecasting layer existed.

Reordering was reactive, triggered when stock hit a minimum, not before. That meant missed order windows, rush freight, and strained supplier relationships.

Purchasing decisions lived in people’s heads and spreadsheets.

With 100+ buyers each covering different product groups across six hubs, there was no single, structured way to know what should be ordered, from whom, and by when.

The scale exceeded manual capacity.

Millions of historical sales, stock, and supplier records needed to be evaluated continuously. Something no buyer, however good, could do by hand across tens of thousands of SKUs.

Supplier communication was unstructured.

Cost changes, lead times, and delivery dates moved over email and fax, with no audit trail and no visibility for either side.

The brief, in effect, was a new-product-development problem: design a system that could think about procurement the way a good buyer does, at a scale no buyer could sustain, and do it in a way buyers would actually trust enough to act on.

Our Approach: Build the Product, Not Just the Feature

We ran this as a full product engineering engagement, not a scripted integration job:

  • Agile delivery with the buying teams embedded as product stakeholders, not end-of-cycle testers. Every iteration of the algorithm was reviewed against real purchasing scenarios before it went further.
  • Architecture-first thinking. Before writing forecasting logic, we designed a data architecture capable of ingesting and continuously evaluating over a decade of sales history, daily stock telemetry across six hubs, and hundreds of thousands of SKU-to-supplier mappings without degrading as the business scaled.
  • Transparency as a design constraint, not an afterthought. From day one, we asked “can a buyer see why the system recommended this order?” as a hard requirement, on par with correctness and performance. That single constraint shaped the entire algorithm architecture.

Deep Dive: Engineering the Forecasting & Purchase Order Automation Algorithm

This was the technical core of the build, and where most of the engineering effort went.

The problem with “just automate it.” A naive automated reorder rule: reorder when stock crosses a threshold was exactly the reactive logic the client was trying to escape. To actually reduce manual work without reducing accuracy, the algorithm had to replicate (and improve on) the judgment a skilled buyer applies: accounting for seasonality, supplier lead times, commercial constraints, and the business’s own past stock-out mistakes.

We engineered the algorithm as a transparent, step-by-step calculation pipeline rather than a black-box model, so every recommendation could be traced back to its inputs:

  • Demand estimation: Daily sales velocity per SKU, adjusted for seasonal patterns.
  • Stock-out bias correction: A purpose-built correction layer that detects when a SKU’s historical sales were artificially suppressed by past stock-outs, and adjusts demand upward accordingly. Without this, the naive approach would keep under-ordering the fastest-moving products, the ones that sell out reinforcing the exact problem we were hired to fix.
  • Coverage projection: Translating adjusted demand into required stock coverage, factoring in each supplier’s actual lead time.
  • Commercial rule filtering: Applying minimum order quantities, case/carton pack sizes, and supplier-specific constraints so recommendations were something a supplier could actually fulfill, not just mathematically correct.
  • Net requirement calculation: Netting the projected need against current on-hand stock and any purchase orders already in flight.
  • Automated PO generation: The final, procurement-ready quantity is used to trigger a purchase order automatically, replacing what had been a fully manual, spreadsheet-driven step for every one of tens of thousands of SKUs.

As a result, the purchase orders that previously required a buyer to notice a shortfall, calculate a quantity by hand, and manually raise an order, are now generated automatically while every number in the calculation remains visible and explainable to the buyer who owns that SKU.

Why the transparency mattered as much as the math. Buyers had spent years developing intuition for their categories, and a system that just outputs “order 480 units” with no explanation was never going to be adopted, regardless of accuracy. We built a calculation walkthrough into the buyer dashboard so every recommendation could be expanded into its component steps: demand, corrections, lead time, constraints, turning the algorithm from a black box into something buyers could audit, challenge, and ultimately trust. That trust is what allowed the organization to shift the default purchasing motion from manual to automated, rather than running the algorithm as a suggestion nobody acted on.

Supporting the Algorithm: Portal, Governance, and Scale

An algorithm is only as good as the data feeding it and the workflow around it, so we engineered the supporting product surface with the same rigor:

  • A centralized supplier portal (2FA, role-based access) so ~2,800 suppliers could update costs, quantities, and delivery dates directly against pre-defined business rules replacing email/fax with structured, auditable data that feeds straight back into the forecasting engine.
  • Buyer and team governance, enforcing a clean one-to-many mapping of buyers to SKUs across product groups, eliminating duplicate ordering across a 100+ person buying organization.
  • A re-order administration layer replacing static legacy reports with real-time, line-level data entry and validation, paired with the algorithm’s calculation walkthroughs.
  • A decoupled, high-throughput data architecture engineered to process tens of millions of stock, sales, and supplier data points annually without degrading and built to scale with the business, not just handle current volume.

Impact

  • Manual purchase order generation was replaced with automated, algorithm-driven triggering, freeing buyers from line-by-line manual calculation across tens of thousands of SKUs.
  • Reduced stock-outs and excess inventory simultaneously. The stock-out bias correction alone recovered “lost demand” the business had been systematically under-ordering for years.
  • High adoption from day one, driven by algorithmic transparency rather than mandated usage. Buyers moved from skepticism to trust because they could see, and verify, the math.
  • A platform built to scale, engineered to absorb continued growth in suppliers, SKUs, and buying teams without re-architecture.

Why us/ Key Differentiators

This project sits at the intersection of two things we specialize in: product engineering, building a new system from a blank page, architected for a specific business’s scale and constraints and software engineering discipline applied to a genuinely hard algorithmic problem, where correctness, explainability, and performance all had to hold simultaneously.

We don’t treat automation and trust as a trade-off. The engineering choice to make every step of the forecasting algorithm inspectable rather than optimizing purely for model accuracy is what turned a technically sound system into one buyers actually adopted. That’s the kind of problem we like building for: where the algorithm has to be right, explainable, and fast enough to run across tens of thousands of SKUs, every day, without anyone needing to trust a black box.

PLATFORM DEVELOPMENT

Ready to Move Beyond Manual Processes plaguing your business?
Let's build an engine that thinks ahead.

We design and build predictive, data-driven platforms replacing manual, reactive processes with intelligent systems that forecast demand, automate buying decisions, and scale with you across new suppliers, more SKUs, and growing order volumes.

Talk to our team about your growth challenges.

Latest Insights

Stay ahead of the curve with our expert analysis, industry trends, and actionable advice. Our blog offers fresh perspectives on the challenges and opportunities in the tech landscape, helping you make informed decisions and drive innovation within your organization.

Net Solutions

Ask Sol

Powered by Net Solutions

Skip the search. Start the conversation.

Ask Sol anything about digital products, AI, engineering, or growth, and get answers drawn from years of Net Solutions thinking and experience.

Our assistant helps you find content on our website. By asking a question, you acknowledge that we will process your data in accordance with our Privacy Policy, and consent to anonymous tracking of your conversation to help us improve the experience. Please avoid sharing personal or sensitive information, and close this page if you do not agree to these terms. While we strive for accuracy, AI responses may be inaccurate.By chatting you accept our Privacy Policy and anonymous analytics. Do not share sensitive information. AI answers may be inaccurate.