When a Merge Is More Than a Merge

CX Operations · Case Study

How a routine inbox action became a customer experience framework


Most support teams treat merging conversations as an inbox management task. Find the duplicate, consolidate the threads, move on. It feels like a neutral action, administrative, invisible, low stakes.

It is not.

At Teachable, I noticed something worth paying attention to. Agents were merging conversations correctly from an operational standpoint, but customers were still walking away feeling like their issue had been redirected rather than resolved. The merge was happening, the experience was not improving, and I wanted to understand why.


What I Set Out to Answer

The question that I looked to understand was specific: does how we merge a conversation affect the customer's experience, and if so, what separates a merge that supports CX from one that quietly damages it?

To find out, I pulled customer satisfaction data from Intercom and split it into two groups: conversations where customers left feeling helped, and conversations where they left with friction. I built structured analysis across three views: individual conversation patterns, outcome comparisons, and a breakdown of what drove each type of experience.

I was not looking for a dramatic finding but rather a consistent pattern.


What the Data Showed

The pattern was clear. A strong answer alone did not guarantee a positive outcome.

Conversations where customers left satisfied shared a common set of conditions: clear ownership, visible progress, low effort, and a concrete next step. Conversations where customers left frustrated showed the opposite: repeat contact, acknowledgment without substance, pending states with no visible movement, and a sense of being redirected rather than helped.

The most telling detail came from the merge-related examples in the sample. In nearly every friction case, the merge had happened correctly. The inbox was organized. But the customer received nothing useful in the process. The issue was acknowledged, the thread was consolidated, and the experience ended there.

The clearest lesson from the analysis: a merge must create progress, not just continuity.

Customers do not judge a merge by whether the inbox is clean. They judge it by whether their problem feels understood, owned, and easy to continue. When a merge feels like "we moved your message somewhere else, please wait," it creates friction. When it feels like "I found your original conversation, I understand the issue, and here is what happens next," it builds confidence.


What I Built From It

I turned the findings into a practical framework for the support team. Not just a list of rules, but a shift in how agents think about the moment of the merge.

The framework covered when to merge and when not to, how to write a merge reply that reduces effort rather than adds to it, and what a strong merge interaction looks like versus a weak one. I also built a standard eight-step process agents could follow every time, and a coaching guide for leaders so they could review merge behavior with precision rather than intuition.

The core standard I held everything to was simple:

The merge reply should contain the best available answer, a clear status update, and a concrete next step.

Not a routing note. Not an acknowledgment. Something the customer could actually use.


What This Work Demonstrates

This project was not about a metric that moved. It was about identifying a blind spot, a moment that agents treated as invisible that customers experienced as a signal of whether they were being taken care of.

The ability to see that gap, analyze it rigorously, and translate it into something a team can actually use is the work I find most valuable. Operational improvement is not always about big numbers. Sometimes it is about making a team more intentional about the moments that quietly shape how customers feel about the experience.

This article is based on internal operational work completed at Teachable. The Confluence article, analysis datasets, and process documentation are available upon request.