--- lang: en template: deployment-detail --- # **Dispatch standard run** in regular operations > Impact 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 % {#lower-inventory-value} Inventory value ### -18.30 % {#lower-transport-cost} Transport cost per pallet ### 99.78 % {#first-time-right-order-proposals} First-time-right orders ## Manual dispatch {#challenge} > Challenge 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. ## Outcome-led dispatch run {#solution} > Solution 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. ## From trigger to documented order {#technical-depth} > Technical depth 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. #### `cron/ops` Function: Daily run orchestration Activity: 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` Function: Business manufacturer run Activity: 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` Function: Data phase Activity: 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` Function: Dispatch planning Activity: 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` Function: Four-eye check / approval Activity: 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` Function: Research for first orders Activity: 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 ```mermaid 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. #### ERP / ordering system Use: Order creation and PO check Description: 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` Use: Closing evidence Description: Not used as an operational guidance system, but as technical reference and run documentation for generated artefacts, status messages and closing evidence. #### `Excel` Use: Order artefact Description: Corresponds to the enterprise's existing closing format and is deliberately integrated into the existing operating mode as a generated order artefact. #### `Browserless` Use: Public research Description: 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. ```mermaid flowchart TB subgraph human["Human service
Clarification"] h1[Clarify master data
or vendor] h2[Return open] h1 --> h2 end subgraph crawl_ops["crawl/ops
conditional troubleshooting"] co1[Check proxy consent
challenge timing] co2[Return fix issue
or HiTL] co1 --> co2 end subgraph crawl_lane["crawl/scrape
task for first order"] cr1[Start crawl_recherche] cr2[Crawl public sources] cr3[Deliver artefact
and review] cr1 --> cr2 --> cr3 end subgraph cron_ops["cron/ops
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
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 ``` ## This deployment can become a blueprint for your enterprise {#dispo-deployen} > Implementation 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. [Get Started](action:demo-booking)