Home · Solutions · Customer service

Solution · Customer service

Every email and ticket themed and counted, so the fixes go where the money leaks

Voice of the customer: the reasons behind the score

Every customer email and case is themed, scored for sentiment and trended, so management sees the reasons customers leave and can fix them in billing, provisioning and product.

DepartmentalMicrosoft TeamsHuman in the loopAI where it earns its place
20,000emails and tickets a month reach this illustrative operator's B2B service desks. Management reads the five that were escalated.

Executive summary

Challenge

Your CSAT score gives you a number. Your customers' emails give you the reason, and nobody reads them.

What changes

We start with history rather than a live feed.

Business value

The largest causes of customer contact are named, counted and ranked every month, so improvement work starts from a list rather than the loudest voice.

Systems involved

Power BI semantic model and dashboards; account risk flags in Dynamics 365 Customer Service; fix register in Microsoft Lists

Business problem

Service intelligence

Every service organisation collects two kinds of feedback: the survey, which returns a score and occasionally a sentence, and the traffic, which is nothing but sentences. Twenty thousand messages a month go unread in aggregate, so the survey wins by default and a large operation is steered on one number.

Category codes are meant to fill that gap and cannot. A code is chosen under time pressure, from a list built for the desk. "Billing query" covers a customer who cannot read a proration line, a customer still charged for a site disconnected in March, and a customer whose service credit never appeared: three owners, three fixes, one code.

The consequences land on people who cannot act on them. The service director defends a score that will not decompose, product hears whichever anecdote is freshest, and billing receives a complaint count with no diagnosis. Account managers find out at renewal, when a customer with eleven months of quiet frustration asks for a discount or does not sign.

At scale the failure compounds. A cause that is never named is never fixed, so it produces the same email next month, and the desk pays for it twice while being measured as busy rather than ineffective.

How it works today

This is how customer feedback usually reaches a management meeting.

  1. PersonAn agent closes a case in Dynamics 365 Customer Service against a category list that has grown to sixty entries
  2. SystemThe reporting pack counts cases per category and queue and adds whatever CSAT responses came back
  3. WaitingMail to the service, billing and provisioning mailboxes is answered and archived; nothing reads it again
  4. PersonOnce a quarter someone reads a sample of thirty complaints by hand and writes a summary slide
  5. Risk of errorA new fault pattern is noticed only when it grows big enough for an account manager to escalate
  6. PersonThe review discusses the score, the escalations and the backlog; product and billing leave with impressions
  7. Risk of errorRepeat contacts on an unresolved cause count as fresh volume, so a number that should trigger a fix justifies more agents
PersonSystemWaitingRisk of error

Why the current process costs more than it appears

Nobody planned this work; it accumulated.

  • A category chosen to close a case is not a diagnosis. Sixty codes describe how the desk is organised, not what went wrong for the customer.
  • Repeat contacts vanish into volume. The same unresolved cause is paid for twice, in handling time and in the customer's patience, and neither shows up as a line anywhere.
  • Reading thirty complaints by hand finds the loud problems and misses the frequent ones. A theme carried by four hundred polite messages never appears in a sample of thirty.
  • Churn arrives without warning although the warning was written months earlier, in plain language, in a message that was answered correctly and then closed.
  • Improvement money is allocated on argument. Without a named cause, a contact count and a revenue figure beside it, the roadmap goes to whoever presents best.

Cost of inaction

Twelve months of themes nobody counted≈ €477,000
Three renewal cycles argued from anecdote≈ €1,431,000
If the B2B base grows to 8,000 accounts (per year)≈ €636,000

Waiting looks free from the inside. The desks keep closing cases inside their service level, the score moves a tenth of a point either way, and the causes keep producing the same contacts. The bill is paid in three places that are never added together: capacity spent on repeats, improvement money spent on the wrong causes, and renewals that arrive with a discount request attached.

The second cost is delay. A pattern that a weekly comparison would surface within days waits instead for an escalation, by which time the same message has been answered several hundred times. Meanwhile the correspondence that would explain it is aged out by retention policy.

Illustrative scenario

A plausible organisation with realistic proportions. The figures are there to be recalculated on your data; they are not a client result.

Organisation

The B2B unit of a European telecom operator serving about 6,000 business customers. Service runs on Dynamics 365 Customer Service with three shared mailboxes in Microsoft 365, and management reporting is already in Power BI.

Volume

20,000 inbound emails and cases a month, roughly 240,000 a year, across service, billing and provisioning, in Polish, English and German, about a fifth of them replies inside existing threads.

Current process

Agents close cases against sixty category codes. Reporting counts categories, queue times and CSAT. Complaints that reach the director are read individually; everything else is archived and never revisited.

Bottleneck

Nobody can say which causes generate the most contacts, which leave customers angry, or which accounts have raised the same issue all year. Every renewal surprise was visible in the mailbox months earlier.

Solution

UiPath Communications Mining learns a taxonomy of causes from twelve months of this operator's own messages, then labels every new email and case with themes, sentiment and the fields to slice by: account, product family, region, channel, language. Power BI turns the labels into trends; a Teams channel carries the monthly review and the alerts.

Potential outcome

In the modelled case the ten largest causes are named and counted inside the first reporting cycle, accounts with a repeated unresolved theme become a standing list for account management, and several causes prove fixable in an invoice text or a provisioning step rather than by adding agents. Illustrative, not a client result.

Proposed solution

We start with history rather than a live feed. Twelve months of correspondence from the service, billing and provisioning mailboxes, plus case bodies and notes from Dynamics 365, are loaded into UiPath Communications Mining. Then comes the part that decides whether any of it is worth having: the taxonomy. With your service, billing and product people we define the causes worth naming, and your own reviewers train the model on your own messages. Supervised machine learning with measured coverage, not a prompt and a summary.

Once the taxonomy is published, every message carries themes, a sentiment reading and the fields we slice by: account, product family, region, channel, language. A mailbox becomes a dataset. Power BI holds the semantic model behind four views: contacts by cause and month, sentiment by cause, causes by product and region, and the accounts whose messages keep carrying the same negative theme. None of this needs a generative model; the value is in labelling twenty thousand messages the same way every month.

The output has to land somewhere with a name and a date on it. The review runs monthly in Microsoft Teams against that dashboard, each top cause takes an owner and a due date in a Microsoft List, and an alert posts to the same channel when a theme's weekly volume leaves its normal band. That is how a firmware release or a new subcontractor announces itself.

Native capabilities used

UiPath Communications Mining in UiPath IXP (label taxonomy trained by annotation, sentiment, extraction fields, multilingual datasets, reports and monitoring); UiPath Integration Service connectors for Microsoft Outlook 365 and Microsoft Dynamics 365 CRM; UiPath Orchestrator scheduling and audit; Power BI semantic models and data alerts

What we build

The taxonomy and the annotation programme with your reviewers; the historical load and the live ingestion; the field set for account, product, region, channel and language; the Power BI model and its four views; the normal-band alert; the fix register in Microsoft Lists and the review format

Custom integration

Mapping the shared mailboxes and Dynamics 365 case bodies and notes into Communications Mining streams, with thread handling and language routing; writing the account risk flag back to Dynamics 365 Customer Service

How the automated process works

  1. AutomationNew mail in the three shared mailboxes and new or updated cases in Dynamics 365 are collected through Integration Service and passed to Communications Mining
  2. AutomationEach message is labelled with themes and sentiment, and the account, product, region, channel and language fields are extracted, replies inside threads included
  3. SystemA nightly Orchestrator job writes the labelled results into the reporting model behind the Power BI dashboards
  4. AutomationWeekly volume per theme is compared with its normal band; a theme that leaves it posts an alert to the service channel in Teams with example messages
  5. PersonService, billing and product owners meet monthly in Teams on that dashboard and give the largest causes an owner and a due date in a Microsoft List
  6. SystemAccounts carrying the same negative theme repeatedly are flagged in Dynamics 365 Customer Service, so account management sees them long before the renewal date
AutomationSystemPerson

Human-in-the-loop model

Automation handles

  • Collecting every email and case from the mailboxes and Dynamics 365, replies inside threads included
  • Labelling each message with themes and sentiment and extracting account, product, region, channel and language
  • Trending, comparison against the normal band, and the alert when a theme moves
  • The account risk flag, the monthly review pack and the record of what was assigned to whom

People decide

  • What the taxonomy contains: which causes are worth naming and how they group
  • Whether a spike is a real problem or a known event, settled in the alert thread in Teams
  • Which of the largest causes gets a fix, who owns it and by when
  • Label corrections in a short monthly session, which is how the model stays accurate

Before and after

BeforeAfter
What management sees each montha score and five escalated complaintsevery message themed, with volumes, sentiment and trends
Time to notice a new fault patternweeks, until someone escalatesdays, from the weekly band alert
Basis for an improvement decisionthe loudest complaint and the backlogranked causes with counts and the revenue behind them
Accounts at riskdiscovered in the renewal conversationa standing list, flagged in Dynamics 365 Customer Service

Systems and integrations

The stack is deliberately short: one engine, one execution layer, one place where a person decides.

Inputs

  • service, billing and provisioning shared mailboxes in Microsoft 365
  • Dynamics 365 Customer Service case bodies and notes
  • twelve months of history for the initial model

Automation layer

  • UiPath Communications Mining (IXP)
  • UiPath Integration Service
  • UiPath Orchestrator
  • UiPath Robots

Target systems

  • Power BI semantic model and dashboards
  • account risk flags in Dynamics 365 Customer Service
  • fix register in Microsoft Lists

Human touchpoints: monthly review in a Microsoft Teams channel; emerging-theme alerts in the same channel; the monthly label-confirmation session

serviceUiPath Communications MiningUiPath Integration ServicePower BI semantic modelmonthly review in a Microsoft Teams channel

Technologies used

UiPath Communications Mining (IXP)

learns a taxonomy of causes from your own emails and cases, then labels every message with themes, sentiment and extracted fields

A
UiPath Integration Service (Microsoft Outlook 365 and Microsoft Dynamics 365 CRM connectors)

collects mailbox traffic and case data without a bespoke extract

A
UiPath Orchestrator + Robots

schedule ingestion, write the nightly export, run the alert job, keep the audit trail

A
Power BI

semantic model and the cause, sentiment, product and region views, embedded as a tab in Teams

A
Microsoft Teams

the monthly review, the alert thread and the assignment of owners

A
Microsoft Lists

the fix register: cause, owner, action, due date, status

A
Dynamics 365 Customer Service

source of case bodies and notes; carries the account risk flag

A
Averified product capability (vendor documentation)

Illustrative economic model

Numbers you can check against your own data.

Illustrative model
240 accounts with a repeated negative theme × €9,000 average annual revenue= €2.16m of revenue at risk
€2.16m × 20% retained once the cause is fixed≈ €432,000 / year
240,000 contacts a year × 18% repeats × 25% removed= 10,800 contacts avoided
10,800 contacts × 9 minutes = 1,620 h × €28 fully loaded hourly cost≈ €45,000 / year
Annual illustrative value pool (retention + repeat contacts)≈ €477,000

Not one of these figures comes from a client; they are assumptions for this scenario: 6,000 B2B accounts at an average €9,000 of annual recurring revenue, 240 of them carrying a repeated unresolved negative theme over a year, and a fifth of that revenue retained once the cause is fixed and the account is worked before renewal. For repeat contacts: 240,000 emails and cases a year, 18% of them repeats, a quarter removed as causes are fixed, at 9 minutes of handling and €28 fully loaded hourly cost. A value pool, not a saving.

Business benefits

  • The largest causes of customer contact are named, counted and ranked every month, so improvement work starts from a list rather than the loudest voice
  • Fixes land where the cause is: an invoice line rewritten, a provisioning step removed, a spare part stocked in one region, instead of more agents answering the same question
  • Repeat contacts fall as causes are removed, releasing desk capacity without touching service levels or hiring
  • Accounts raising the same unresolved theme for months are visible to account management well before the renewal conversation
  • Polish, English and German feedback is counted in one taxonomy, so a cause is never hidden by the language it arrived in

The management view

  • Service quality stops being a single score and becomes a list of causes with volumes, trends and an owner on each
  • Improvement budgets can be argued with counts: contacts a cause generates, revenue in the accounts that raise it
  • The desk is measured on what it removes as well as on what it handles, which turns the headcount conversation from defensive to evidential
  • The same taxonomy shows which themes are standard enough to triage automatically, so the automation pipeline is fed by evidence rather than workshops

Board-level KPIs

contacts per cause per monthrepeat-contact rateshare of contacts with negative sentimenttop causes with a named owner and a due daterevenue in flagged accounts

Security and governance

The automation holds exactly the rights it needs, and not one more.

  • No third-party analytics service receives a copy of anything: customer correspondence is read where it already sits, in your Microsoft 365 tenant, and UiPath Automation Cloud does the reading from its EU region
  • Ingestion runs under a dedicated application identity, with mail permissions scoped to the named mailboxes and case access limited to the tables it reads
  • The reporting layer publishes aggregates and selected examples rather than raw correspondence, and dashboard access follows the same Microsoft Entra ID groups as your other reporting
  • Personal data in message bodies is covered by a retention rule agreed with your data protection officer before the historical load
  • Communications Mining classifies and counts your own text; it drafts nothing, and every figure traces back to the messages and the labels applied to them

Why now

01

Retention policies remove the oldest correspondence every month, so the twelve months that would train a good model today are not the twelve months you will have next year, while the modelled pool of roughly €477,000 a year stays unclaimed

02

B2B contracts renew on a cycle, and that conversation is shaped by what the customer remembers of the past year; knowing which accounts have raised the same unresolved theme changes who opens it

03

Communications Mining is a supervised model over your own messages, not a general-purpose language model, so labels stay consistent and auditable message by message

Relevant executive roles

Customer Service Director

The score becomes named causes with owners, so the improvement plan can be defended and its effect measured

COO

Contacts that should never have happened are removed at source in billing, provisioning and logistics instead of being absorbed by the desk

CFO

Retention and desk capacity are tied to a counted cause list, which makes service investment arguable like any budget line

CIO

One supervised model over data you already hold, with EU residency and an audit trail, rather than a text-analytics tool per department

Common questions and objections

Our agents already categorise every case.

They categorise in order to close it, under time pressure, from a list built for the desk. Communications Mining reads what the customer wrote, applies one taxonomy to every message including replies inside threads, and can be set beside your existing codes to show where the two disagree.

Isn't this a language model summarising our mailbox?

No. It is a classification model trained by your own reviewers on your own messages, so the same cause is counted the same way every month. That consistency is the point: a summary cannot be trended, a count can.

Our customers write in three languages, and often badly.

Real service correspondence is what the model is trained on: forwarded threads, half sentences, mixed languages, missing context. One taxonomy is applied across languages, so a cause is not split by the language it arrived in.

When this is not the right solution

  • A few hundred messages a month, where reading a full month of correspondence by hand is cheaper than training and maintaining a model
  • No willingness to change anything outside the service desk: if billing, provisioning and product will not accept causes, a better diagnosis produces a better-documented backlog and nothing more
  • Message data without usable account identifiers, in which case the revenue view is unavailable and the first project is fixing the identifiers instead

A question for the next management meeting

If we ranked the ten reasons our customers wrote to us last year and put the revenue of the accounts behind each one next to it, would anyone in this room be surprised by the order?

Implementation approach

A scope without ambiguity, before anything is signed.

We deliver

  • A read of your history: twelve months of mailbox and case data, volumes by channel, the language mix and what today's codes really record
  • The taxonomy of causes, designed with service, billing and product, then trained on your own messages
  • The annotation programme: reviewers, workload and the coverage targets that decide when the model can be published
  • The ingestion: mailbox and Dynamics 365 streams, thread handling, language routing, nightly export
  • The Power BI model and its management views: causes and volumes, sentiment, product and region, the account watch list
  • The normal-band alert, the fix register in Microsoft Lists, the monthly review format and the handover

We need from you

  • Twelve months of email and case data from service, billing and provisioning, with account identifiers intact
  • A taxonomy owner in customer service and named counterparts in billing and product who will accept causes
  • Access to Dynamics 365 Customer Service and the shared mailboxes for a dedicated service identity
  • Two to four reviewers: a few hours a week during training, a short session each month afterwards

Stages

Discovery

History, channels, languages, volumes and what today's codes record

Taxonomy design

The causes worth naming, agreed across service, billing and product

Training

Annotation by your reviewers, measured for coverage and consistency

Build

Live ingestion, the Power BI model, the band alert, the fix register and the account flag

Go-live

The first monthly review run together, then hypercare

Optimisation

Taxonomy maintenance as products change, threshold tuning, further channels

Departmental. Effort is driven by the number of channels and languages, how reliably account identifiers appear in the data, and how much argument there is about what the causes should be called.

What were the ten reasons your customers wrote to you last month?

Send us one month of message statistics: volumes by channel and language, your current category list, and how a case is closed. We return a draft taxonomy of causes and a written assessment of what your history can support.

Rank the causes in your service mail

The neighbouring process usually has the same problem

Industries we deliver this in most oftenRetail & e‑commerceServices & ITFinance & insuranceEnergy & utilities

Browse all 115 solutions