Home · Solutions · Supply chain
Solution · Supply chainThe offer sequence runs itself; the dispatcher only decides what nobody accepted
Every load offered to the right carrier at the right price
Every load is offered to carriers in the order your rate card sets, inside a response window; acceptances are booked and documented, and only unplaced loads reach a person.
Executive summary
Loads go to the carrier who answers first, priced from a rate sheet nobody has updated since March.
What Mientha builds is a dispatch sequence, not another transport system.
Loads go to the carrier the contract names, at the price it names, without anyone remembering which lane was renegotiated.
SAP S/4HANA and the transport system booking record; SharePoint document and offer archive; Power BI
Business problem
Transport execution
Transport is bought twice. Once a year at the negotiating table, where lanes, equipment and rates are agreed with forty carriers, and then again every afternoon at the dispatch desk, where somebody decides which of them gets the load. The second purchase determines what the company pays, and it is made by telephone against a spreadsheet.
The rate card is the weak point: a workbook with a tab per carrier, updated whenever someone remembers that a lane was renegotiated. Dispatchers learn who answers quickly and go there first, which is rational under cut-off pressure and expensive all the same, because the contracted carrier may be third in the queue. Spot loads have no card at all: one or two carriers are called, the first workable price is taken, and the only trace of the decision sits in the dispatcher's sent items.
Everything downstream inherits the delay. The warehouse plans bays for carriers it will learn about in the morning, customer service says the truck is booked without naming it, and the freight audit compares an invoice with a rate card rather than with what was agreed.
How it works today
One dispatcher's afternoon, in the order it happens.
- SystemTomorrow's confirmed loads are exported from the ERP and the transport system into a spreadsheet
- PersonThe dispatcher sorts them by region and opens the rate workbook to see who should take each lane
- PersonCarriers are called or emailed one at a time, starting with whoever answered fastest yesterday
- WaitingThe desk waits for a callback while the remaining loads queue and the cut-off approaches
- PersonCarrier, vehicle and price are typed into the transport system, the order written from a template
- Risk of errorSpot loads are awarded at the first acceptable price, with no record of who else was asked
- PersonThe loading list is emailed to the warehouse and the customer called with an arrival time
- Risk of errorThe rate comes from a workbook version nobody can date, so invoice and agreement diverge quietly
Why the current process costs more than it appears
Nobody planned this work; it accumulated.
- Speed decides price. A dispatcher working against a cut-off takes the first yes, and calling the fastest responder first reprices a whole lane without any decision being taken.
- Nothing records what was not chosen: who else was asked, what they quoted, why they were passed over. Procurement negotiates the next card blind.
- Rate-card drift stays invisible until the invoice arrives. Between a renegotiation and the day the workbook is updated, every load on that lane moves at the wrong number.
- Waiting is unpaid work. Much of the time per load is a dispatcher holding a line or watching a mailbox, which does not improve with effort.
- Carrier knowledge sits with two people: who takes refrigerated work at short notice, who never answers on Fridays, who refuses a difficult ramp.
Cost of inaction
Rate cards age faster than anyone updates them, and that is the part the table above does not price. A lane renegotiated in March is still dispatched on February's number in June, spot loads keep going to whoever picks up, and the freight audit later finds differences nobody can settle. It shows up as freight cost growing a little faster than volume.
The second risk is concentration. Four dispatchers hold the working knowledge of forty carriers, and the bargaining position in the next rate round is whatever those four remember. A process that lives in habits cannot be audited, handed to a new depot, or scaled without hiring the same knowledge again.
A plausible organisation with realistic proportions. The figures are there to be recalculated on your data; they are not a client result.
A European building-materials manufacturer, three plants and two distribution centres in Poland and Germany; SAP S/4HANA with a transport module, a separate warehouse system and Microsoft 365 E3; four dispatchers place the loads.
2,600 outbound loads a month across roughly 40 contracted carriers; about 70% full loads on contracted lanes, 20% groupage, 10% spot; loading windows are fixed the previous afternoon.
Loads are exported to a spreadsheet, offered by telephone and free-text email in the order the dispatcher chooses, typed back after acceptance and documented from a Word template.
About eight minutes of dispatcher time per load, most of it choosing, calling and waiting. Late placements leave the warehouse building sequences for unnamed carriers, and no evidence survives of the offers a load received.
Robots read the confirmed loads at cut-off, rank carriers per lane from the versioned rate card, offer in that order with a response window, book the acceptance, generate the transport order and loading list and tell the warehouse and the customer.
In the modelled case the desk keeps 347 hours a month for carrier management, contracted lanes are booked minutes after the plan is confirmed, and every award carries its offers; arithmetic on the assumptions of the illustrative model, not a client measurement.
Proposed solution
What Mientha builds is a dispatch sequence, not another transport system. The rate card becomes a versioned table on SharePoint, kept in Excel by transport procurement: lane, equipment, service level, validity dates, price, surcharges and a ranked carrier sequence. At the cut-off robots read the confirmed loads from SAP S/4HANA and the transport system with the attributes that decide the carrier.
Offers then go out in the order the card sets, each carrying a load reference, the windows, the equipment, the price valid that day and a response window. The accept and decline links are pre-addressed replies, so an answer returns with the reference and the decision already in the subject; carriers with a portal or an EDI link receive the offer there. The first valid acceptance inside the window takes the load and stops the sequence; a decline moves it on at once.
After the award the rest is bookkeeping. The booking is written back with carrier, vehicle, price and reference; the transport order and loading list are generated from your templates and filed on SharePoint beside the offer history; the warehouse gets the slot, the customer the window. The agreed price per load is stored as data, which is what a freight invoice audit needs later. A load unplaced at its escalation point becomes an Action Center task in Microsoft Teams with the ranked alternatives and the lane's price history.
UiPath Orchestrator queues, time triggers, retries and audit trail; UiPath Integration Service connectors for Microsoft Outlook 365, Microsoft Teams and Microsoft OneDrive & SharePoint; UiPath Action Center actionable notifications in Microsoft Teams; Microsoft Teams Approvals app; Power BI
The versioned rate-card and carrier-sequence model, the offer engine with response windows and escalation points, reply matching and award rules, booking write-back, document templates and the dispatch report
Load and booking exchange with SAP S/4HANA through UiPath SAP activities (BAPI/OData) and with the transport system through its API or a file interface; portal or EDI acceptance where offered
How the automated process works
- AutomationAt the cut-off the confirmed loads are read from SAP and the transport system and queued in Orchestrator
- SystemEach load is matched to its lane and a carrier sequence built from the card version valid that day; unpriced lanes go to spot
- AutomationOffers leave the dispatch mailbox in that order with reference, windows, equipment, price and a response window, or via the carrier's portal
- AutomationReplies are matched on the reference; the first valid acceptance inside the window takes the load and the sequence stops
- AutomationThe award is booked with carrier, vehicle, price and reference; order and loading list are generated and filed on SharePoint
- AutomationThe warehouse receives the slot and the carrier, the customer the confirmed window, and the price goes to the freight audit record
- PersonLoads unplaced at their escalation point arrive as Action Center tasks in Microsoft Teams with ranked alternatives; the dispatcher awards or releases to spot
- AutomationA daily summary reaches the transport channel: loads placed, first-offer acceptances, escalations, price against card
Human-in-the-loop model
Automation handles
- Reading the day's loads and building the carrier sequence from the card valid on the loading date
- Sending, timing and advancing offers, and stopping at the first valid acceptance
- Booking the award, producing the transport order and loading list, notifying warehouse and customer
- Recording every offer, reply, decline and agreed price for the freight audit and the next negotiation
People decide
- Loads at the escalation point: award above the card, re-offer at a new price, or release to spot
- Prices above the agreed tolerance, approved in Microsoft Teams by the transport manager
- The carrier sequence per lane, the response windows and the tolerances, owned by transport procurement
- Whether a carrier stays in the sequence after repeated declines or late refusals
Before and after
Systems and integrations
Where a rule suffices we do not use a model. Where judgement is needed, a person decides.
Inputs
- confirmed loads from SAP S/4HANA and the transport or warehouse system
- the versioned rate card on SharePoint
- carrier replies in the dispatch mailbox
- portal and EDI acceptances
Automation layer
- UiPath Orchestrator
- UiPath Robots
- UiPath Integration Service
- UiPath Action Center
Target systems
- SAP S/4HANA and the transport system booking record
- SharePoint document and offer archive
- Power BI
Human touchpoints: Action Center tasks in Microsoft Teams; Teams Approvals for prices above tolerance; the daily dispatch summary
Technologies used
queue every load, run the offer sequence with response and escalation timers, retry and audit
Asends offers from the dispatch mailbox, picks up replies
Aposts escalations, the warehouse slot list and the daily summary
Aaward decisions on unplaced loads, without leaving Teams
Aprices above tolerance approved by the transport manager
Aversioned rate cards, carrier sequences, transport orders, offer archive
Aacceptance by carrier and lane, price against card, spot share, time to booking
Aload data in, booking and price back
CIllustrative economic model
Start by questioning the assumptions.
The carrier's price is not in this model at all; what is priced is dispatcher time, at eight minutes per load. Those minutes cover choosing from the rate workbook, the call or the email, the wait, the write-back and the message to the warehouse. €26 an hour is a fully loaded dispatcher cost in Central Europe, and every figure is illustrative rather than measured at a client.
Run the numbers on your data
An illustrative estimate from your own inputs. It models released capacity; it is not a promise of savings.
Business benefits
- Loads go to the carrier the contract names, at the price it names, without anyone remembering which lane was renegotiated
- Contracted lanes are booked within minutes of the plan, so the warehouse builds its sequence for named carriers the same day
- Spot loads are awarded after a comparison rather than after a phone call, with offers and replies kept as evidence
- The customer learns the carrier and the window as soon as the load is booked, not when somebody has time to write
- The agreed price per load exists as data, so a freight invoice can be checked against what was agreed
- Peak weeks are absorbed by running offer sequences in parallel, at no extra cost in dispatcher hours
The management view
- Carrier behaviour becomes measurable at the moment of award: who accepts, who declines, who answers late
- Rate-card discipline stops depending on memory: the version valid on the loading date is applied, and every award records it
- Transport procurement enters the annual negotiation with its own award and decline history instead of the carrier's account
- The desk survives holidays and turnover, since carrier knowledge sits in the sequence rather than in two people's heads
Board-level KPIs
Security and governance
Security is designed with the process, not after it.
- Every robot signs in as its own service account: read-only on load data, booking rights only in the transport system, the mailbox reached through Microsoft Graph with permissions scoped to it alone
- Secrets never sit inside a workflow. They are held in the Orchestrator credential store, or in Azure Key Vault where your security team already runs one
- The rate card is contract data: versioned on SharePoint, changed by procurement with approval, and every award records the version it was offered against
- Duties stay apart: robots offer and book within the rules, the dispatcher decides escalations, the transport manager approves prices above tolerance in Teams
- Load data, offers and transport documents stay in your Microsoft 365 tenant and the UiPath Automation Cloud EU region; driver names and vehicle registrations only where the order needs them
Why now
Freight paperwork has a deadline. The eFTI Regulation applies in full from 9 July 2027, when authorities in EU Member States must accept transport information shared electronically through certified platforms; a transport order produced as structured data is a much shorter step towards that than a Word file per load
The dispatch desk is where a negotiated rate is applied or lost, and in the modelled case it consumes 347 hours a month, none of which makes the carrier choice better
The components are ordinary now: Orchestrator queues and timers, the Microsoft Outlook 365 and Microsoft Teams connectors, Action Center tasks in Teams, Power BI on the tenant you already pay for
Relevant executive roles
The plan reaches a booked carrier without depending on how many calls one dispatcher can make before cut-off
Freight cost per load becomes the number in the contract, and every award carries the evidence that it was
Rates are negotiated from your own award, decline and response history rather than the carrier's version of the year
Common questions and objections
They do not have to write anything. The accept and decline links are pre-addressed replies, so the answer returns with the reference and the decision already in the subject; larger carriers accept through their portal or EDI. A reply that does not match goes to a dispatcher, not into a rule.
Spot loads run the same sequence with a different rule: the offer goes to a defined carrier group at once, replies are collected until the window closes, and the dispatcher awards from a ranked comparison rather than the first call returned.
Carriers get a clearer offer, earlier in the day, and stop being called about loads placed twenty minutes ago. The conversations that matter, capacity for next week or a rate review, are the ones the dispatcher gets time for.
When this is not the right solution
- Fewer than a few hundred loads a month across two or three regular carriers, where a phone list is cheaper than an offer engine
- No usable rate card and no intention of building one; if every load is negotiated from scratch, carrier selection is a procurement exercise first
- Loads are not confirmed in a system before dispatch, so there is nothing to read at the cut-off; getting the plan out of spreadsheets comes first
A question for the next management meeting
For last month's loads, could we show which carrier was under contract for the lane, which one actually drove it, and what the difference between the two cost us?
Implementation approach
We start with one slice of the process and extend only once it is proven.
We deliver
- One month of your dispatch replayed: lanes, the carrier used against the carrier under contract, spot share, decline patterns
- The rate card digitised into one versioned model: lanes, equipment, service levels, validity dates, surcharges, a ranked sequence
- The offer engine: response windows, escalation points, reply matching, award rules and price tolerances
- Booking write-back to SAP and the transport system, order and loading-list templates, warehouse and customer notifications
- Teams touchpoints for escalations and price approvals, the daily summary and the Power BI dispatch report
- Go-live on one plant under supervision, then rollout with a runbook
We need from you
- Three months of loads with the carrier awarded and the price paid, plus the current rate-card workbooks
- A process owner in transport and a counterpart in procurement who owns the carrier sequence
- Read access to load data in SAP and the transport system, a service account for the mailbox, a test client
- Agreement with your carriers that offers and acceptances move to a structured channel: reply links, portal or EDI
Stages
Discovery
One month of awards replayed against the card: lanes, prices, declines, cut-off reality
Design
Rate-card model, carrier sequences, response windows, escalation points, thresholds, security model
Build
Offer engine, reply matching, SAP and transport-system write-back, templates, Teams touchpoints, Power BI
Validation
Parallel run on live loads, the dispatcher deciding and the sequence proposing
Go-live and tuning
Region by region, windows and sequences adjusted on the first acceptance data
Departmental. Effort follows the number of lanes and equipment types in the card, whether the transport system exposes bookings through an API, and how many carriers can accept outside free-text email.
The load goes to the carrier who answers, not to the carrier you contracted.
Send us one month of loads with the carrier awarded, the price paid and your current rate-card workbook. We replay the month against the sequence your card specifies and return the awards that would have gone elsewhere, with a written read-out.
Re-run one month of your dispatchThe neighbouring process usually has the same problem
Carrier invoices are checked on a sample and paid in full; the overbilled lines are the ones nobody opened.
View solution Supply chainTransport orders into the TMS without retypingNinety customers, ninety ways of sending an order, and a forwarder retyping every one into the TMS.
View solution Supply chainExport documents ready while the truck is loadedYour ERP holds every figure the customs pack needs. Somebody types them in again anyway.
View solution Supply chainInventory that agrees: WMS and ERP reconciled every nightStop discovering at the cycle count, or when an order cannot ship, that the WMS and the ERP disagree.
View solution Case studyDriver settlementNo more manual document collection and spreadsheets.
View case study Case studyDigital CMR and PODThe driver photographs the document at unloading.
View case studyIndustries we deliver this in most oftenManufacturing & industryTransport & logisticsRetail & e‑commerce