A customer explains a delivery problem for six minutes. The first representative promises to contact the warehouse and transfers the conversation. The next person receives a polished summary about the delay, but the promise is missing. The customer has to start again.
That is the test that matters. A conversation summary is useful only when the next person can continue the work without inventing a commitment, repeating a question or losing ownership. Before enabling Copilot summaries across a service team, test them as operational handoff records rather than treating fluent prose as proof of accuracy.
The old summary is not the new one
Microsoft says it stopped supporting the previous auto-summarization of ongoing conversations on April 16, 2025 and recommends Copilot-generated conversation summaries instead. That change is recorded in the current Customer Service deprecation notice.
The replacement is not the same feature with a new name. Copilot can summarize an ongoing chat or transcribed voice conversation. An administrator chooses when summaries appear. Microsoft documents triggers for a representative or collaborator joining, a transfer, the end of a conversation and an on-demand request. AI agent conversations are not automatically included.
Configuration therefore changes the evidence available at handoff. A summary generated when someone joins serves a different need from one generated after the conversation ends.
Choose the trigger before tuning the output
Start with one handoff moment. A transfer is usually easier to judge than a broad rollout because there is a clear sender, recipient and next action. Map the same moment in your human handoff design: who decides to transfer, what the receiving person must know and who keeps responsibility until acceptance.
- Define the momentChoose whether the summary supports a join, transfer, ending or current decision.
- Write expected factsRecord the customer need, action, promise, next step and owner outside the generated text.
- Run representative casesInclude corrections, long conversations, transfers, calls and AI-started contacts.
- Classify each failureSeparate omissions, distortions and invented details so the cause stays visible.
- Name the human ownerAssign acceptance and recovery responsibility before widening access.
Microsoft's current summary settings allow summaries when a representative joins, when a conversation ends and on demand. A transfer also generates a summary under the join setting. The finished summary can remain with the closed conversation, and administrators can permit a representative to create a case from it.
Do not turn on every trigger just because it exists. Too many summaries can make it unclear which version is current. Choose one purpose, one owner and one acceptance check.
| Summary moment | What it should preserve | Human acceptance check | Main failure to watch |
|---|---|---|---|
| A representative joins | Customer need and work already completed | New representative states the next action before replying | The customer must repeat a fact |
| A conversation transfers | Promise, deadline and accepted owner | Receiving person confirms ownership | The promise disappears during transfer |
| A conversation ends | Outcome and unresolved follow-up | Closing representative checks the record | A partial fix is described as complete |
| On demand | Current facts needed for a decision | Requesting person compares it with the transcript | An early assumption becomes a fact |
Test the moments where context breaks
Build a small test set from ordinary work. Include a straightforward chat, a long conversation, a correction by the customer, a promise with a date, a transfer, a consultation, a transcribed call and a conversation that started with an AI agent. Use synthetic or properly authorized data and keep the expected facts outside the generated summary.
For each case, write five things the next person must receive: the customer's actual need, verified evidence, action already taken, unresolved next step and accepted owner. This is close to a useful customer support case note, but the two records are not interchangeable. A summary helps someone catch up. The case record remains the place for durable facts and commitments.
Run the same case through each intended trigger. Then compare the output with the transcript and expected facts. Mark three kinds of failure separately:
- Omission means an important fact or promise is missing.
- Distortion means the summary changes who did what or what was agreed.
- Invention means it adds a fact, outcome or commitment that the conversation did not contain.
Also check whether the summary preserves uncertainty. “The customer thinks the charger failed” is not the same as “the charger failed.” That small difference can send the next representative down the wrong path.
Make a human own the summary
The summary should reduce rereading, not remove judgment. Before a transfer completes, the sending representative should check any promise and the receiving representative should accept the next action. At closure, the person ending the conversation should verify the outcome. When the summary creates a case description, someone should confirm that a proposed action has not been recorded as completed.
Define a recovery path. If the summary is missing or wrong, the representative should know whether to read the transcript, ask the previous owner, reopen the record or create a corrected note. A broken summary must not leave work without an owner.
This is also a good place to prevent duplicate action. A summary may make two people feel informed without telling them who owns the reply. Use the same visible ownership and send-time checks that help stop two representatives replying to the same customer.
Roll out from evidence
Pilot one queue or workstream with a named service lead. Review a representative sample of transfers, endings and on-demand summaries. Do not measure success only by whether a summary appeared. Track whether the recipient could continue, whether a customer repeated information, whether a promise survived and whether the recorded owner acted.
Expand only when the failure pattern is understood and the team has a recovery rule. Recheck after changing the trigger, source data or summary format because each change can alter what people see.
In DripTell, we approach the same problem through visible history and ownership in the shared inbox, with AI assistance inside a human operating model. The next person needs verified context, not merely a convincing paragraph.
A broader support operation should treat summaries as one control in the handoff, alongside routing, access, records and accountability. If the customer still has to repeat the story, the summary has not passed.
Frequently Asked Questions
When should Copilot generate a conversation summary
Choose the moment that matches a real operating need. A join or transfer summary supports continuity, an end summary supports closure and an on-demand summary supports a current decision. Enable only the triggers you can review and own.
Can a summary replace the conversation transcript
No. Keep the transcript or approved source record available for verification. The summary is a shorter working view and can omit, distort or overstate details.
What should a handoff summary always contain
It should preserve the customer's need, verified evidence, action already taken, any promise, the unresolved next step and the person who accepted ownership.
How do you know the rollout is ready
It is ready when representative test cases pass, reviewers can identify and correct failures, recipients continue without asking customers to repeat known facts and every next action has a visible owner.
Want help applying this guide?Ask the DripTell team
From reading to action
Want help applying this to your business?
Share your details. We will read the article you are on and start with a useful answer for your team.
DripTell Editorial
Practical guidance reviewed by the DripTell product and customer workflow team.
See how DripTell checks product claims, uses primary sources and handles corrections.
Editorial and source policy
