Home · Solutions · Customer service
Solution · Customer serviceDelays announced by your systems, status questions answered without a queue
Order status answered before the customer asks
Customers hear about a delay or a backorder from your systems, and whoever still asks gets a verified answer in seconds; agents keep only the cases that need a decision.
Executive summary
Every third customer contact asks where an order is; the answer already sits in SAP and the carrier portal.
Two layers solve two different problems, and we keep them apart.
Customers learn about a delay from you, not from an empty loading bay, while there is still time to act.
customer email and SMS; the customer portal; the UiPath Data Fabric notification log
Business problem
Proactive service
A status question is not a decision. It is a lookup, and the answer already exists in the order, the delivery document and the carrier's event feed. It costs money because no single screen holds all three, so a person assembles it and writes the reply. Across a service team's month, a real share of the payroll goes on reading systems aloud.
The second cost is timing. Delays and backorders are known inside the company long before the customer notices, and nothing pushes that knowledge outwards. The customer finds out when the lorry does not arrive, so the first contact is a complaint rather than a question, and the account manager is pulled in to repair the relationship.
Volume peaks at the worst moment. Promotions, seasons and supplier disruption raise both the number of late orders and the number of people asking about them, so the queue grows fastest when capacity is thinnest. Answers drift too: one agent quotes the confirmed date, another what the warehouse said that morning, and the customer gets two Thursdays.
Underneath sits a measurement problem. Handled inside a general mailbox, these contacts are never counted, so nobody knows which customers ask most or which routes cause them. The largest single category of customer contact is the one the service report cannot see.
How it works today
A customer asks when the order arrives; the answer is assembled by hand from SAP, a carrier portal and a Teams message, in most distributors before automation, whatever the ERP.
- SystemA customer emails the service mailbox, writes in the portal or calls to ask when an order arrives
- WaitingThe message queues behind the rest of the day, hours in a normal week and far longer in a peak
- PersonAn agent opens the order in SAP, checks the delivery and confirmed date, then the carrier portal
- PersonFor anything not yet shipped the agent asks the warehouse or planner on Teams and waits
- PersonThe agent writes a free-text reply, occasionally committing to a date no system holds
- Risk of errorDelays known internally are never announced and status contacts are never counted, so the volume and its causes stay invisible
Why the current process costs more than it appears
The most expensive part of this process has no cost line.
- Each lookup is short and each is a context switch across three systems, which is why recorded handling time and consumed time rarely match.
- Silence before a delay is what costs real money: an unannounced late delivery becomes a chased order, a credit note, a re-planned shipment and sometimes a lost contract, none of it booked to customer service.
- Improvised answers create their own follow-up. A date promised from memory has to be corrected, and every correction is another contact and another dent in trust.
Cost of inaction
The arithmetic above is only the visible half. The rest is the orders that quietly move to a competitor after the second unannounced delay, the credit notes issued to keep an account, and the express shipments booked to repair a date nobody warned about. None of that lands in the customer-service budget.
The second risk is structural. A team sized around the status queue grows with the order book, and a team that spends its month on lookups never reaches the work that keeps customers.
A plausible organisation with realistic proportions. The figures are there to be recalculated on your data; they are not a client result.
A European e‑commerce and wholesale distributor of technical consumables, roughly 600 employees, two distribution centres, SAP with a warehouse and transport management system, four carriers, a B2B portal and a consumer webshop; Microsoft 365 E3 with some Microsoft 365 Copilot licences.
12,000 status contacts a month across the service mailbox, portal chat and the telephone, roughly 60% email, 25% portal and 15% phone; about one contact in three is a status question, and peak months run some 40% above average.
Twelve agents answer from SAP and the carrier portals, escalate to planning on Teams and reply in free text. Delays are communicated only when the customer asks, and a weekly list of late orders is kept by hand.
About five minutes of handling per status contact, and a service function fully occupied answering questions instead of resolving the situations behind them.
SAP and transport events trigger rule-driven notifications before the customer notices, a Microsoft Copilot Studio agent answers verified customers in the portal, and a UiPath conversational agent in Microsoft Teams gives staff the same live figures.
In the modelled case the proactive layer removes a large share of contacts before they are made, the agents answer most of the rest, and the team keeps the cases that need a decision. The figures are a model, not a measurement.
Proposed solution
Two layers solve two different problems, and we keep them apart. The first is deterministic and contains no AI. A confirmed date that moves, a short delivery, a shipment handed over, a scan event that misses its window: UiPath Orchestrator picks these up through Integration Service triggers and queues them with a reason code. A rule set owned by service and supply chain decides what is worth telling a customer, in which language and on which channel. Email leaves through the Microsoft Outlook 365 connector, consumer SMS through Azure Communication Services, the account owner gets an Adaptive Card in Microsoft Teams, and UiPath Data Fabric holds the state so a customer hears about an event once.
The second layer answers what remains. On the portal a Microsoft Copilot Studio agent takes the question in the customer's language and calls a UiPath API workflow that reads the order, the delivery and the carrier feed live. A UiPath conversational agent published as a Microsoft Teams app answers it internally for sales and service, with the detail customers never see. Both call one status service, so every channel quotes the same figure.
Identity governs what the customer-facing agent may say. A signed-in portal user carries their identity from the session, and the status service filters on the customer numbers that identity may see. An unauthenticated visitor gives an order number plus one field only the recipient of the confirmation holds, typically the delivery postcode; the check runs server side, three failed attempts end the session, and the agent confirms one order rather than listing anything. Internal users are authenticated by Microsoft Entra ID and scoped by group. Dates and tracking numbers come from returned fields, never paraphrased by a model, and the field list is approved, so prices, margins and other customers' orders are not there to be leaked. UiPath agent guardrails cover prompt injection, PII and harmful content. Asked for a date no system holds, either agent says so and escalates into an Action Center task for a named person, visible in Teams with a due time.
Licensing deserves a plain statement. The internal Teams agent runs on UiPath licensing and its AI and agentic usage pool. The Copilot Studio agent is billed in Copilot Credits per answer, per agent action and per event payload; the zero rating for Microsoft 365 Copilot licence holders covers agents in Copilot Chat, Teams and SharePoint, not an external customer on your portal. We size that capacity from your contact volume first.
UiPath Orchestrator queues with event, time and API triggers; UiPath Integration Service connectors for SAP, Microsoft Outlook 365 and Microsoft Teams; UiPath API workflows; a UiPath conversational agent in Microsoft Teams; agent guardrails and Action Center escalations; UiPath AI Trust Layer; Microsoft Copilot Studio with tools and Entra Agent ID; Microsoft Purview audit; Azure Communication Services SMS
The event model over SAP and the transport system, the notification rules and the screen where their owners change them, message templates per event and language, the status service and its approved field list, identity verification, agent instructions and evaluation sets, escalation routing and reporting by cause
Carrier tracking interfaces with no packaged connector, built with UiPath Integration Service Connector Builder or as API workflows; the portal hand-off passing the signed-in identity into the agent; the bridge from Copilot Studio to the status service, either the UiPath connector for Power Platform (premium tier, Preview on Microsoft Learn) or an Orchestrator-managed MCP Server
How the automated process works
- AutomationA moved confirmed date, a short delivery or a carrier scan event is queued in Orchestrator with the order, the customer and a reason code
- SystemThe rules decide whether the event is worth a message, to whom, in which language and channel, and suppress repeats
- AutomationThe customer gets an email or SMS with the new date, the reason in plain words and a link to the order; the account owner gets a card in Teams
- AutomationA customer who still has a question opens the portal chat; the Copilot Studio agent verifies identity, calls the status service and answers from the returned fields
- SystemSales and service staff ask the UiPath agent in Teams and get the same figures plus internal detail
- PersonAnything outside the agents' scope becomes an Action Center task for a named person, conversation and order attached
- AutomationEvery notification, question and escalation is written against the order, so the service report shows volume by cause and route
Human-in-the-loop model
Automation handles
- Detection of the events worth telling a customer about, and the rules deciding who hears what
- Sending, translating and logging notifications across email, SMS and Teams without duplicates
- Verified status answers on the portal and in Teams, read live from the order and the carrier feed
- Counting status contacts by cause, customer and route for the service report
People decide
- Any new promised date; the agents state what the systems hold and never commit for the company
- What to do about a delay that damages a customer: partial shipment, substitution or a goodwill gesture
- Which events deserve a proactive message and how it is worded; the rules stay owned by the business
- Every case the agents escalate, which arrives as a named task rather than a queue nobody owns
Before and after
Systems and integrations
Where a rule suffices we do not use a model. Where judgement is needed, a person decides.
Inputs
- SAP sales orders, deliveries and confirmed dates
- availability and backorder changes
- carrier tracking events from the transport management system
- the service mailbox in Outlook
- portal and web chat
Automation layer
- UiPath Orchestrator
- UiPath Robots
- UiPath Integration Service
- UiPath API workflows
- UiPath Agents
- Microsoft Copilot Studio
Target systems
- customer email and SMS
- the customer portal
- the UiPath Data Fabric notification log
- the service contact report
Human touchpoints: the UiPath conversational agent in Microsoft Teams; Action Center escalation tasks in Teams; the hand-off from the portal agent to a named service person
Technologies used
queue ERP and carrier events, run the notification rules, retry and audit
Aread orders and deliveries, send emails, post internal cards
Aone status service for both agents and the portal, returning approved fields only
Ainternal status agent for sales and service, with guardrails and escalations
Acustomer-facing agent on the portal, calling the same status service as a tool
Aescalations become named tasks with due times
Amodel allow list, PII masking, prompt and response audit
AIllustrative economic model
Start by questioning the assumptions.
Five minutes is a blended average across an easy email lookup and a phone call that needs the carrier portal, and it counts handling only. It is illustrative, taken from ranges we see in distribution service teams rather than measured at a client. The rate is a fully loaded hourly cost in Central Europe. We model capacity released, not posts removed.
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
- Customers learn about a delay from you, not from an empty loading bay, while there is still time to act
- The questions that remain are answered in seconds, at any hour, in the customer's language, with no queue behind them
- Service capacity moves from lookups to the cases that need judgement: disputes, damaged goods, accounts at risk
- Account managers stop working as a status relay and see the live picture in Teams themselves
- Peaks are absorbed by the notification layer and the agents instead of by overtime and temporary staff
The management view
- The invisible volume becomes a measured category: how many status contacts, from which customers, caused by what
- Delay communication becomes a policy the business owns and can change in an afternoon, not a habit that varies by shift
- Order growth stops implying service headcount growth, because the contact-generating part of the volume is handled by rules
- Every promise and notification is logged against the order, which settles disputes on evidence
Board-level KPIs
Security and governance
Security is designed with the process, not after it.
- Robots and agents hold their own service accounts with read rights on orders and deliveries and nothing more; every call is logged
- The customer-facing agent never takes a customer number from the conversation: identity comes from the portal session or the verification check
- The approved field list is the security boundary; prices, credit status and other customers' orders sit outside it, whatever a prompt asks
- Prompts, responses and tool calls are kept for audit, in the UiPath AI Trust Layer for the Teams agent and Microsoft Purview for the Copilot Studio one, with PII masking on both
- The EU region of UiPath Automation Cloud and your Microsoft 365 tenant are the only places any of this executes, and conversation logs never leave that boundary
Why now
Supplier lead times and carrier performance are no longer predictable, so late orders are routine and a team sized for the average is permanently behind; the modelled queue alone is a thousand hours a month
Under the EU Consumer Rights Directive a consumer whose goods are late may set an additional reasonable period and then terminate the contract, with thirty days as the default deadline where nothing else was agreed
The plumbing is no longer a project of its own: UiPath conversational agents have been generally available as a Microsoft Teams app since April 2026, Copilot Studio consumes MCP tools as a generally available feature, and Orchestrator publishes an API workflow as a tool
Relevant executive roles
The largest contact category stops arriving, and the month moves to the cases that decide whether a customer stays
Delay communication becomes a controlled process with owners, rules and evidence, not a habit that differs by shift
Account managers get live delivery facts in Teams and stop relaying dates from the warehouse
One status service serves every channel, with identity verification, an approved field list and a full audit trail
Common questions and objections
Most never reach it, because the proactive layer answers before the question forms. The agent that remains does one narrow job and hands over the moment a decision is needed.
Identity is never taken from the conversation. It comes from the portal session or a check against the order itself, and the status service filters server side and returns approved fields only.
The rules, templates and status service sit outside the ERP; only the read layer changes. A migration is usually when confirmed dates are least reliable, exactly when proactive communication is worth most.
When this is not the right solution
- Order volume is low enough that one agent knows every open order by name, where a shared status view costs less
- Confirmed dates in the ERP are not maintained, so there is no reliable fact to announce; order-confirmation discipline comes first
- The carriers expose no tracking events and block automation of their portals, which limits the proactive layer to what the ERP knows
A question for the next management meeting
Our service team answers the same question all day: how many of last month's contacts asked for a delivery date our own systems already held, and what did answering them cost?
Implementation approach
We start with one slice of the process and extend only once it is proven.
We deliver
- A read of three months of service contacts against order and delivery data: what was asked and what an event could have prevented
- The event model over SAP and the transport system, with reason codes the business recognises
- The notification rules, message templates per event and language, deduplication, quiet hours and the owner screen
- The status service: one API workflow with an approved field list, serving both agents and the portal
- Both agents, with identity verification, guardrails, escalation routing, evaluation sets and a tested fallback to a person
We need from you
- Three months of service mailbox and portal contacts, and the matching orders and deliveries
- A service owner and a supply-chain owner who sign off which events are announced and how
- Technical accounts for SAP, the transport system and the carrier interfaces, plus the portal identity hand-off
- Your escalation matrix and the languages your customers actually write in
Stages
Contact analysis
Classify real contacts and identify which a notification would have prevented
Event and rule design
Event model, reason codes, message rules, channels, quiet hours and ownership
Build
Notification layer, status service, both agents, escalation routing and reporting
Pilot
One customer segment live under supervision, both layers measured
Rollout
Wider release, hypercare, tuning of rules and instructions on real conversations
Departmental. Effort is driven by the carriers without a packaged interface, the number of languages, and the quality of confirmed dates in SAP.
Your planner knows the delivery moved. Your customers do not.
Send us one month of service contacts with the matching orders and deliveries. You get back the share an event notification would have prevented, the events worth announcing first, and a credit-capacity estimate for a customer-facing agent.
Count one month of status contactsThe neighbouring process usually has the same problem
Your best agents spend their morning sorting mail instead of answering it.
View solution Supply chainCustomer orders from PDFs and emails straight into the ERPCustomer POs still get retyped from PDFs into SAP and confirmed hours later. Stop paying your order desk to type.
View solution Customer serviceReturns and refunds without a ping-pong of emailsThree weeks, two phone calls and eleven emails to give a customer their money back.
View solution Supply chainOrder confirmations and delivery dates chased automaticallyBuyers spend their mornings chasing suppliers for dates, and planners plan on dates that are already wrong.
View solution Case studyComplaints in hours, not daysThe agent reads every complaint from email and forms, gathers evidence from the ERP and TMS, and settles simple cases by your rules.
View case study Case studyOrder-to-Cash control towerEvery blocked order, disputed invoice and breached credit limit flows into one process: an agent diagnoses, a robot executes, a human approves with one decision on Teams.
View case studyIndustries we deliver this in most oftenManufacturing & industryRetail & e‑commerce