Deep Research

Today we're launching Deep Research, a new way to investigate customer behavior across your support tickets, chats, and calls.

Analytics tells you what happened. Insights help you spot patterns. Deep Research is for the moments when you need to answer a specific question with confidence - using the full context hidden inside conversations and the data around them.

‍

The problem: when analytics stops being enough

Most teams have dashboards. Most teams have weekly reports. Many teams even have an "insights" layer that surfaces trends like "billing questions are up" or "refund requests spike after deliveries."

And then something happens that doesn't fit neatly into a chart.

Conversions drop, but the funnel looks fine. Escalations jump, but categories barely change. Customers keep reaching a human agent instead of completing the digital flow, even though the form is right there on the site.

In those moments, the question is never "how many." It's "why, exactly."

The frustrating part is that the answer usually exists already. It's spread across hundreds or thousands of real conversations: what customers tried, what confused them, what they expected, which screen they were on, what they said they did before reaching out, what the agent saw, and what the system did or didn't do.

Deep Research is built for turning that mess of reality into something you can act on.

‍

Why we built Deep Research for CX

Support data is the richest behavioral dataset most businesses have, but it's also the least usable. Not because it's inaccessible, but because it's unstructured. It lives in free text, transcripts, attachments, call summaries, and back-and-forth threads.

Traditional tools force you to simplify it too early: tag it, bucket it, aggregate it. That works when you're looking for high-level signals, but it breaks down when you need precision.

We built Deep Research because teams kept asking questions that sounded like investigations, not reports:

• Why did customers bypass our digital form and reach a human agent last week?
• What changed after we launched the new flow, and how did customers describe the problem in their own words?
• Which friction points are causing repeat contacts for the same issue?
• Are these escalations actually policy-related, product-related, or expectation-related?

These are not questions you can answer confidently by sampling 30 tickets, skimming a few transcripts, and hoping your intuition is right.

Deep Research makes it possible to ask the question directly, search across the right data, and get an outcome that stands up in a product meeting.

‍

Analytics vs insights vs Deep Research

It helps to separate three very different types of "knowing."

Analytics is measurement. It's counts, rates, timelines, and funnels. It's the heartbeat monitor. Essential, objective, and fast. But it can't tell you what customers were thinking when they made a decision.

Insights are interpretation. They connect signals into patterns. They can tell you that a certain issue is trending, or that a segment behaves differently, or that specific intents correlate with higher escalations. Insights are often where you realize there is a story.

Deep Research is investigation. It's what you do when you already have a hypothesis, or when something feels off, and you need to prove the cause. It doesn't stop at "this is happening" or even "this seems related." It goes into the conversations themselves, pulls out the underlying reasons, and ties them back to the context around those conversations so you can trust the conclusion.

If analytics is your map and insights are your compass, Deep Research is your flashlight in the dark corridor.

‍

How Deep Research works

Deep Research starts with a question. Not a dashboard prompt, not a filter tree. A real question, phrased the way you would ask a colleague.

From there, it gathers the most relevant evidence across your support universe: tickets, chats, call transcripts, and any other conversation records you have. It does not treat each conversation as a single blob of text. It understands them as sequences: what the customer said, what the agent asked, what was attempted, what succeeded, what failed, what was repeated, what was escalated.

Then it does what experienced analysts do, but at scale. It clusters recurring reasons, identifies edge cases, separates symptoms from causes, and keeps track of what it relied on to reach the conclusion. The goal is not to sound smart. The goal is to be useful and defensible.

Instead of leaving you with a vague summary, it produces structured outcomes you can take into the business: themes, supporting evidence, breakdowns by segment or channel, and clear recommendations tied to what customers actually said and did.

‍

No-code, data scientist-level power

Deep Research is designed to feel like having a data scientist on demand, without the overhead that usually comes with that.

No SQL. No notebooks. No exporting logs into a separate system. No figuring out how to label, sample, and normalize messy text before you can start.

You write in free text. You iterate in free text. You can ask follow-ups in the same way you would in a conversation: "Break that down by new vs returning customers." "Only include cases where the customer mentioned the form." "Show me the top three failure points and example quotes for each."

And when you're ready to share the outcome, you can choose the format that matches the next step in your workflow. Sometimes you want a narrative you can paste into Slack. Sometimes you want a CSV to hand to an analyst. Sometimes you want a graph to drop into a deck.

Deep Research is built to meet you where you are, not force you into a specific way of working.

‍

The role of metadata and combined data

Conversation text is powerful, but it's rarely enough on its own. The real story often lives in the relationship between what was said and the context around it.

Deep Research uses metadata as first-class research material, not as an afterthought. That includes things like channel, time, language, customer segment, product line, ticket reason, escalation tags, agent team, resolution path, and more. It can also incorporate what you know about the customer and the account: plan tier, lifecycle stage, region, prior contact history, and any relevant attributes you already track.

This matters because "why" changes depending on who the customer is and what situation they are in.

A customer bypassing a digital form might be doing it because the form is unclear. Or because it doesn't support their language. Or because it fails on mobile. Or because the customer is high-value and knows humans respond faster. Or because they tried the form last time and it didn't work.

Those are different causes, and they deserve different fixes.

Deep Research is built to combine the conversational evidence with these surrounding signals so you get conclusions that are not just interesting, but accurate.

‍

What you get out: narratives, reports, CSVs, and graphs

A good investigation ends in an outcome you can use or share.

Deep Research can produce a clear written report that explains the findings in plain language, with the "why" and the implications. It can also produce structured outputs: tables you can export as CSV, breakdowns you can plug into your own analysis, and visual summaries that make it easier to communicate what changed and where the biggest impact sits.

Most importantly, it doesn't just give you conclusions. It gives you the shape of the evidence. That means you can move from "I think" to "we know," and align teams faster because the story is grounded in real customer interactions.

‍

Real examples of the questions Deep Research is built for

Deep Research shines when the question is specific and the stakes are real.

Here’s a short example of the kind of case insurance teams run into:

Last week, an insurance team saw a sudden jump in "claim status" calls, even though the self-serve claims portal was working. They ran Deep Research across all claim-related calls and chats from the previous seven days with one question: why are policyholders calling instead of checking status in the portal?

The answer came back in three clear clusters. First, many callers weren’t truly asking for an update - they were responding to a status that stayed on “In review” for days with no explanation of what happens next. In the conversations, customers repeatedly described it as “stuck,” “frozen,” or “no one is looking at it.” Second, Deep Research surfaced a smaller but high-impact issue: people who tried uploading documents from mobile, hit a silent failure, and then called when the portal continued to show “missing documents.” Third, it highlighted a behavior pattern tied to claim type: in certain claim categories, customers received fewer proactive status notifications, which increased uncertainty and drove calls even when the claim itself was progressing normally.

Once that was visible, the next steps stopped being a debate. The team updated the status language, added a simple "what happens next" step in the portal, and aligned CX macros to match the new flow. The following week, claim status calls dropped - without changing staffing or pushing harder on deflection.

The same approach works for questions like why FNOL gets abandoned, why denials trigger repeat contacts, or what pushes claims into supervisor escalation. It’s not about guessing what changed. It’s about proving it from the conversations and the context around them.

‍

Trust, privacy, and guardrails

When you investigate customer conversations, trust matters. Deep Research is designed to work within the boundaries you set: which data it can access, what it can output, and what actions it is allowed to suggest or automate.

It is built to support serious operational use, not just exploratory curiosity. That means being deliberate about how data is handled, and ensuring the system remains aligned with business and compliance requirements.

For teams that care about governance, this is not a side detail. It's part of making Deep Research safe to use broadly.

‍

What's next

Deep Research is the start of a new workflow: one where answering "why" doesn't require a separate project, a separate team, or a week of back-and-forth.

Next, we're focused on making investigations faster to run, easier to share, and easier to operationalize. That includes richer ways to slice findings, stronger collaboration around research outputs, and more direct paths from discovery to action.

Because the real promise here isn't just better reporting. It's moving from scattered conversations to confident decisions, with evidence you can actually trust - proactively.