A Copilot Studio Agent Handling Store Service Requests Across 240 Retail Sites
The internal service desk was taking 9,400 tickets a month from store staff, most of them the same twelve questions. We built a Copilot Studio agent that resolves them end to end and hands the rest to a human with the context attached.
About the Client
The Challenge
The internal service desk supported 240 stores with a team that had not grown in three years while the estate had. Volume ran at roughly 9,400 contacts a month. When we categorised 12,000 closed tickets, a few request types accounted for the clear majority: password resets, rota and payroll questions, stock discrepancy reporting, printer faults, and how-do-I questions about the point-of-sale software.
Every one had a documented answer somewhere, spread across an old intranet, a Teams channel and PDFs on a shared drive. A supervisor on a shop floor at seven in the morning is not going to search three systems. Phoning the desk was faster for them and expensive for everyone else.
A previous attempt had failed. A keyword chatbot bolted onto the intranet matched on exact phrases, answered with a link, and was abandoned within a quarter. It had been measured on deflection rate, which it scored well on, because a user who gives up and phones counts as deflected. That term has no counterpart in Copilot Studio analytics, and for good reason. The product reports engagement, resolution, escalation and abandonment separately, and resolution splits into Resolved Confirmed, where the End of Conversation topic fires and the user confirms the problem is solved, and Resolved Implied, where the session completes without that confirmation.
The brief we were given was to reduce ticket volume. The brief we agreed was different: resolve routine requests properly, and make every escalation arrive better than a cold phone call. Those are not the same target and do not produce the same design.
Our Approach
We built from the ticket history outwards. Every topic traces back to a request type we could count, and every answer was tested against real closed tickets before release.
Ticket Taxonomy and Candidate Selection (Weeks 1-2)
Exported 12,000 closed tickets and clustered them by intent rather than by the category the agent picked at logging time, which is almost always wrong. Scored each cluster on volume, whether the resolution was deterministic, and whether it needed data the agent could reach. Transactional requests became authored topics, explanatory questions became generative answers, and anything needing judgement was designed as a structured escalation from day one.
Topic Design and Action Wiring (Weeks 2-6)
Built authored topics for the deterministic paths, because a password reset or a stock discrepancy report must follow the same steps every time. Each collects its variables with validation, then calls a Power Automate flow or connector to do the work — raise the ITSM record, trigger the reset, write the discrepancy to Dataverse. Explanatory questions went to generative answers, as a node inside a topic or via the Conversational boosting system topic, with generative orchestration routing between them.
Knowledge Grounding and Content Cleanup (Weeks 3-7)
Pointed generative answers at a governed source set rather than everything available — one curated SharePoint library and the ITSM knowledge base. Generative orchestration allows 25 SharePoint URLs, more than a well-scoped agent needs and far fewer than a tenant holds, so the limit forced curation early. The old intranet and shared drive were excluded because they held superseded procedures. Turned off ungrounded responses, so the agent cannot answer without citing a knowledge source or running a tool. Content work ran through our SharePoint consulting team.
Authentication and Personalised Answers (Weeks 5-8)
Switched the agent to Microsoft Entra ID authentication so it knows who is asking. That is what turns generic guidance into an answer: the agent reads the user's store, role and open tickets, so "what is happening with my printer request" returns a status rather than an article on raising one. Authentication also gates actions — only a duty manager can trigger certain flows — and removes the identity-verification step that made the phone route slow.
Regression Testing and Staged Release (Weeks 7-11)
Built a regression set of 600 real user utterances taken verbatim from ticket text, including the misspelt and half-finished ones, and ran the agent against it after every change. Released to pilot stores in Teams first and reviewed analytics weekly. The diagnostic that mattered was the System Unintended escalation sub-type, which isolates handoffs caused by the agent hitting a threshold rather than by a business rule; System Intended and User Requested escalations work as designed. Abandonment — an engaged session timing out after 30 minutes without resolving or escalating — was reviewed case by case. Widened only once both stopped moving, then rolled out by region.
Solution Architecture
Agent: Copilot Studio with authored topics for transactional requests and generative answers for explanatory ones, generative orchestration routing between them
Knowledge: A narrow source set — one curated SharePoint library and the ITSM knowledge base, well inside the 25-URL SharePoint limit. Superseded content was excluded rather than deprioritised, because grounding does not know which version is current
Identity and actions: Entra ID authentication for personalised answers and role-gated actions, with Power Automate flows and Dataverse writes behind each topic
Escalation: The Escalate topic and a Transfer to agent node hand over carrying the transcript, the authenticated user context and every variable collected, so nothing is asked twice
Channels and measurement: Published to Teams, where responses cap at 20 citations, and the store portal. Reported on engagement, resolution split into Resolved Confirmed and Resolved Implied, escalation by sub-type, abandonment and the 1-5 CSAT score, with ticket reporting in Power BI
Results
Client identity withheld under confidentiality. Figures are representative of engagements of this scope.
Technologies Used
Key Takeaways
If your organization is facing a similar challenge, here's what we learned:
Deflection rate is the wrong first metric, and not one the product reports. Copilot Studio measures engagement, resolution, escalation and abandonment. Report all four, and read resolution carefully: Resolved Implied only means the session ended without a problem signal, while Resolved Confirmed means the user said so. Hold yourself to abandonment and System Unintended escalations, because those two are the agent failing people.
Authored topics and generative answers do different jobs. Anything that changes state — a reset, a record, an approval — belongs in an authored topic with validation and a deterministic path. Generative answers explain. Blurring the two produces an agent that improvises a transaction, which is the failure nobody recovers from.
Grounding quality is a content decision, not a model decision. Pointing an agent at every document you own guarantees it will confidently quote a procedure withdrawn two years ago. A narrow, current, owned source set beats a wide one every time.
Authentication is what makes the answers worth having. An anonymous agent returns documentation. An authenticated one returns your ticket, your store's rota and your device. That gap is the gap between a novelty and a tool people reuse.
Test against real ticket text, not prompts you wrote. Designers write clean utterances. Store staff write "till 4 wont take card again". A regression set built from verbatim ticket history catches failures a demo never will. We place Copilot Studio developers who build this way.
Related Case Studies
Thinking About an Agent for Your Service Desk?
We start with your ticket history, not a demo. If the volume is not there, we will say so. If it is, we build an agent that resolves requests rather than one that closes conversations.