Impact

Dispatch standard run in regular operations

The Dispatch deployment guides the operational standard run for replenishment planning in the enterprise: checking inventory, combining data, identifying due manufacturers, preparing orders and triggering approved orders. The daily run checks each manufacturer separately and documents every closing status with evidence. The dispatch process in the approved standard path is therefore moved from manual processing into guided operational case management.

-14.50 %

Inventory value

-18.30 %

Transport cost per pallet

99.78 %

First-time-right orders

Challenge

Manual dispatch

An e-commerce company in DACH with roughly 200 active manufacturers had to monitor inventory, manufacturer due dates and irregular order needs every day to reliably meet the internal service target. The process included daily replenishment and a multi-step ordering and approval process.

In manual dispatch, orders were frequently corrected, enlarged or triggered as small individual orders. This secured availability in the short term, but increased tied-up capital, delivery costs and warehouse effort.

The central question was not only whether orders could be automated. The real challenge was to create a daily dispatch standard run that secures delivery capability, manages inventory economically, identifies due manufacturers in time and executes ordering decisions in a controlled way, without the process depending permanently on manual monitoring and individual follow-up control.

Solution

Outcome-led dispatch run

In Q1 2026, the company built an outcome-led in-house solution for the daily dispatch standard run with Jadey's agent swarm. The solution was operated inside the enterprise and connected due manufacturers, data review, order decision, approval and order placement in one controlled process.

Across an eight-week measurement period, the comparison with the previous manual dispatch process showed a clear economic improvement. The evaluation is based on 897 completed order runs across roughly 200 active manufacturers. The internal service target remained stable.

First-Time-Right in this deployment means: an order run was completed after approval and PO creation without subsequent manual correction. 895 of 897 order runs fulfilled this definition.

Note: Company name, absolute order values and ERP details are anonymized for confidentiality reasons. Process structure, measurement logic and artefact chain correspond to the deployed setup.

KPI	Before Jadey	After Jadey	Impact	Meaning
Average inventory value	Index 100.00	Index 85.50	-14.50 %	Less capital tied up in inventory
Transport cost per pallet	Index 100.00	Index 81.70	-18.30 %	More efficient transport through better bundling
Unplanned individual orders	92	18	-80.50 %	Significantly less reactive follow-up control
Bundled order volume	65.00 %	80.54 %	+23.90 %	More volume runs through plannable consolidated orders

The strongest operational change is in unplanned individual orders. They fall from 92 to 18. This shows that after Jadey was introduced, the process operated much less reactively. Needs were recognized earlier, manufacturer runs were guided more consistently and orders were less often corrected outside the standard.

At the same time, bundled order volume rose from 65.00 % to 80.54 %. This explains the lower transport cost per pallet: more volume is consolidated in a plannable way instead of being moved in small lots at short notice.

The lower average inventory value also shows that better planning was not bought with more safety stock. The process becomes more economical without simply holding more goods.

In the defined standard run, the previous manual dispatch process was no longer needed as a continuous processing unit. Jadey took over daily case guidance across manufacturers, data review, approval and order placement. Human interventions remained limited to clearly bounded exception and maintenance tasks, such as creating new manufacturers or adding missing information.

Technical depth

From trigger to documented order

The technical architecture of the deployment is based on a deliberate separation of orchestration, business case guidance, data review, planning, review, ordering and evidence. Jadey therefore does not run the dispatch standard run as uncontrolled end-to-end automation, but as a bounded, auditable and documented operating process. The following overview shows the participating agents, systems and flows in the actual depth used in the deployed enterprise.

Agents and roles in the deployment

Three agent areas participate in the daily manufacturer run. cron starts the daily run, identifies due manufacturers and hands every manufacturer to dispo as its own case. In the ops role, dispo takes over case guidance: the agent keeps the manufacturer case together, controls data phase, dispatch planning, review, approval and order placement, and commissions further specialized dispo roles such as demand, planner and review.

When needed, crawl is additionally involved. crawl researches public manufacturer or product information, prepares it structurally and returns it as a data artefact into the manufacturer case. The daily run therefore remains clearly guided: cron orchestrates the start, dispo/ops carries outcome responsibility per manufacturer case and crawl adds external data when the internal data situation is not sufficient.

Agent/role	Function in the deployment	Activity
`cron/ops`	Daily run orchestration	Starts the daily run and sequences manufacturer runs.
	`cron/ops` is responsible for the technical daily run. The agent starts the dispatch run on workdays at 09:00, checks due manufacturers and sequences the individual manufacturer runs. For each manufacturer, `cron/ops` starts a waiting subtask to `dispo/ops` and waits for result, error, timeout, blocker or finding. Only then is the next manufacturer run started. The daily run, started subtasks, results and skipped manufacturers are documented. Boundary: `cron/ops` makes no business ordering decisions and must not trigger an order. The agent controls the daily run, but not dispatch planning itself.
`dispo/ops`	Business manufacturer run	Guides the manufacturer case from data review to completion.
	`dispo/ops` is the leading business agent for each manufacturer. It keeps the manufacturer case together across data phase, dispatch planning, review, approval, order placement and completion. To do this, `dispo/ops` calls specialized roles such as `dispo/demand`, `dispo/planner` and `dispo/review`, combines their results and guides the case through to closing status. After approval, `dispo/ops` can trigger the order through the ERP or ordering system and create the closing artefacts. Boundary: `dispo/ops` does not replace the individual specialist roles. The agent guides the manufacturer case, but remains dependent on data situation, planning, review and approval.
`dispo/demand`	Data phase	Supplies the verified data basis for the manufacturer run.
	`dispo/demand` supplies the verified data basis for the manufacturer run. The agent collects relevant data sources, creates source artefacts, builds `datenquellen.json` and provides the required data links. The verified data situation is returned to `dispo/ops` and forms the basis for further dispatch planning. For first orders, `dispo/demand` can involve additional public research through `crawl/scrape`. Boundary: `dispo/demand` delivers data and evidence, but makes no ordering decision and must not trigger an order.
`dispo/planner`	Dispatch planning	Creates dispatch evaluation and order logic.
	On the basis of `datenquellen.json`, `dispo/planner` creates the business dispatch evaluation. The agent evaluates quantities, order need and relevant comment positions and creates `disposition.json` from this. The result can prepare a concrete ordering decision, such as `bestellen_heute`. `dispo/planner` therefore supplies the business basis for review and approval. Boundary: `dispo/planner` can prepare an ordering decision, but cannot operationally place an order. Execution remains bound to review, approval and system action.
`dispo/review`	Four-eye check / approval	Reviews the dispatch decision before execution.
	`dispo/review` checks the dispatch decision before operational execution. The agent reviews data links, dispatch artefact and business plausibility. When the result is positive, `dispo/review` creates `review.json` and `freigabe.json`. When problems occur, the agent returns finding, question or rejection. Boundary: Without explicit approval from `dispo/review`, no order may be triggered. The review agent checks and approves, but does not order itself.
`crawl/scrape`	Research for first orders	Researches public manufacturer and product data.
	`crawl/scrape` is involved only when needed, especially when additional public manufacturer or product information is required for first orders. The agent researches public sources, extracts structured manufacturer, product and source information, deduplicates results and provides a JSON or CSV artefact. The return status includes source coverage, row count and artefact path. Boundary: `crawl/scrape` is not a generic research agent for arbitrary data procurement. The agent is used only within the data phase and works on public sources that may be used under the applicable rules.

Service hierarchy

flowchart TB
  cron_ops[cron/ops]
  dispo_ops[dispo/ops]
  demand[dispo/demand]
  planner[dispo/planner]
  review[dispo/review]
  crawl_scrape[crawl/scrape]
  erp[(ERP / ordering system)]
  github[(GitHub)]
  excel[(Excel)]
  browserless[(Browserless)]

  cron_ops --> dispo_ops
  dispo_ops --> demand
  dispo_ops --> planner
  dispo_ops --> review
  dispo_ops --> erp
  dispo_ops --> github
  dispo_ops --> excel
  demand --> crawl_scrape
  crawl_scrape --> browserless

Systems in the deployment

In the deployment, Jadey connects to the company's existing system landscape. Internal sources provide manufacturer data, the ERP or ordering system executes approved orders, Excel provides operational closing evidence, GitHub documents technical results and Browserless supports public research when needed.

System	Use in the deployment	Description
ERP / ordering system	Order creation and PO check	Connected enterprise system for operational orders. The order is created there and the PO status checked only after verified data situation, dispatch evaluation and approval.
`GitHub`	Closing evidence	Not used as an operational guidance system, but as technical reference and run documentation for generated artefacts, status messages and closing evidence.
`Excel`	Order artefact	Corresponds to the enterprise's existing closing format and is deliberately integrated into the existing operating mode as a generated order artefact.
`Browserless`	Public research	Supports public crawl and scrape runs when additional manufacturer or product information is needed for first orders.

Artefacts in the deployment

The artefacts in the deployment form the evidence chain of the manufacturer run. Every relevant step creates auditable evidence: data basis, dispatch evaluation, review, approval, order and completion. The agent run therefore does not become a black box, but an auditable operating process.

For enterprise environments, this artefact chain is central. It makes visible which data was used, which role was responsible for which step, when a decision was approved and how the result was documented in the system landscape. Jadey therefore not only takes over operational work, but also creates the evidence needed for control, governance and continuous improvement.

`Run note`

Owner: cron/ops

Meaning: Documents daily run, due manufacturers, started subtasks, results and skipped manufacturers.

`lauf.json`

Owner: dispo/ops

Meaning: Keeps manufacturer case, run context and closing status together.

`datenquellen.json`

Owner: dispo/demand

Meaning: Describes verified data sources, data links and source artefacts for the manufacturer run.

`disposition.json`

Owner: dispo/planner

Meaning: Contains dispatch evaluation, quantity logic and prepared ordering decision.

`review.json`

Owner: dispo/review

Meaning: Evidences review, finding and approval before an operational order.

`bestellung.json`

Owner: dispo/ops

Meaning: Documents the triggered order and the returned order status.

`Excel file`

Owner: dispo/ops

Meaning: Serves as generated order artefact in the company's existing closing format and is referenced in closing evidence.

`crawl_recherche`

Owner: crawl/scrape

Meaning: Supplies public manufacturer or product information for first orders.

From daily start to order evidence

The daily dispatch run connects daily start, manufacturer check, data phase, dispatch evaluation, review, approval, order placement and closing evidence into a guided operating process. cron starts the run and hands due manufacturers over as individual cases. dispo/ops keeps every manufacturer case together and guides it through specialized roles, systems and artefacts to the outcome.

The standard path ends with a documented order or a traceable completion status. Side paths apply only under defined conditions: when public manufacturer information must be researched, technical crawl issues occur or master data and vendor assignments are not clarified sufficiently. The run therefore remains controllable even when individual cases block or need additional clarification.

flowchart TB
  subgraph human["Human service<br/>Clarification"]
    h1[Clarify master data<br/>or vendor]
    h2[Return open]
    h1 --> h2
  end

  subgraph crawl_ops["crawl/ops<br/>conditional troubleshooting"]
    co1[Check proxy consent<br/>challenge timing]
    co2[Return fix issue<br/>or HiTL]
    co1 --> co2
  end

  subgraph crawl_lane["crawl/scrape<br/>task for first order"]
    cr1[Start crawl_recherche]
    cr2[Crawl public sources]
    cr3[Deliver artefact<br/>and review]
    cr1 --> cr2 --> cr3
  end

  subgraph cron_ops["cron/ops<br/>daily run task"]
    c1[cron/ops trigger]
    c2[Check order day]
    c3[Sequence manufacturer list]
    c4[Start dispo/ops subtask]
    c5[Wait for result]
    c6[Document run]
    c1 --> c2 --> c3 --> c4 --> c5 --> c6
  end

  subgraph dispo_ops["dispo/ops<br/>manufacturer run task"]
    d1[Start manufacturer run]
    d2[demand subtask]
    d3[Wait for data]
    d4[planner subtask]
    d6[review subtask]
    d7[Wait for approval]
    d8[Close PO Excel GitHub]
    d1 --> d2 --> d3 --> d4 --> d6 --> d7 --> d8
  end

  c4 --> d1
  d8 --> c5
  d2 -. first order .-> cr1
  cr3 -. crawl_recherche .-> d3
  cr2 -. issue .-> co1
  co2 -. return .-> cr2
  %% Layout help: keeps crawl/ops above the crawl lane so clusters do not collide.
  co2 ~~~ cr1
  d7 -. clarification needed .-> h1
  h2 -. return .-> d7

Implementation

This deployment can become a blueprint for your enterprise

The Dispatch deployment shows how Jadey guides a business-critical process in operational use: from data review through demand evaluation to approval, order placement and traceability of the outcome.

What was implemented here for dispatch can be transferred to comparable processes in your enterprise - with your existing system landscape, your approval paths and the rules that govern your operations.

In a first conversation, we assess whether this deployment is suitable as a starting point for your enterprise and where Jadey can create near-term operational impact.