All case studiesProof of concept
Order handling for an IT hardware provider: proof of concept.
An IT hardware provider's order desk checked stock, device compatibility and supplier availability by hand for every order. A proof of concept automated those checks and drafted supplier orders, was validated against live order cases, and documented where a person must still decide.
- Client
- An IT hardware provider
- Sector
- IT distribution, revenue operations
- Engagement
- Proof of concept
IT distribution, revenue operations
Growth goal
Let the order desk handle more orders without more people checking stock, compatibility and suppliers by hand.
Operating constraint
Every order meant checking stock, verifying device compatibility and chasing suppliers for missing parts.
Validated result
Validated against live order cases, with the points where a person still decides documented.
Summary
- Challenge
- Checks ran across several systems and inboxes, and nothing recorded which had been done or which supplier replies were outstanding.
- What SIEL built
- A language model reads customer requests and links them to quote and product records. Rules check stock and compatibility in the existing systems, and the workflow drafts supplier orders for missing parts.
- Controls
- Drafts only. A person reviews and releases every supplier order, and each step records whether the system or a person made the call.
- Impact
- The documented review points are the design basis for a production build.
The full account
01The same checks, repeated for every order
The order desk sits between sales, customers and suppliers. For every confirmed quote, someone checked stock, verified that devices and parts were compatible, and chased suppliers for anything missing, across several systems and inboxes. As volume grew, the work grew with it, and so did the risk of promising a delivery the desk could not meet.
02What the language model does and what rules do
The proof of concept splits the work in two. A language model interprets each customer request, which arrives in free text and varied formats, and links it to the right quote and product records. Everything after that is rules. Stock levels are read from the existing systems, compatibility is checked against the provider's compatibility rules, and missing parts are listed. The workflow then assembles a draft supplier order with the lines and context a buyer needs.
03Drafts only, with every step recorded
The workflow cannot commit the provider to anything. It produces drafts, and a person reviews and releases every supplier order. Each step records whether the system or a person made the call and on what data, so the desk can see the path from customer question to supplier draft and check any step in it.
04Validation and the documented review points
The proof of concept ran against live order cases, not constructed examples. During validation we recorded each point where human judgement was still needed, such as unclear compatibility rules and supplier behaviour outside the usual pattern. That record is the main result. It defines which steps a production build can automate and which stay as explicit approvals. The workflow is not yet in production.
Discuss Your Operation With Our Engineers.
Describe one workflow and the systems it relies on. A senior engineer responds within two business days with an initial assessment: what we would build, what we would not, and why.