#37 Integrating UX and Customer Support?

Last week, I had an online coffee with Anders Notzhén. We first bumped into each other at a meetup about a year ago, and when he reached out to talk about CX, UX, and customer support, it got me curious.

After the usual introductions, Anders said:

“Wouldn’t it make sense to bring UX and customer support closer together? And maybe CX as well? Perhaps even to organize them so that they are part of the same team?”

We explored the idea for a while. It is easy to see the appeal: gathering both the reactive feedback you get from customer service and the proactive insights you gain through user research, prototyping, and early testing. But as we talked, I found myself thinking that for this to really work, the organization would need to be at a very particular point in its journey.

Over the weekend, I kept returning to the question. When does this make sense? And when does it not?

Like most things in growing companies, the answer depends on context. In some stages, bringing UX and support closer together can be a real strength. In others, it risks obscuring other issues that need different kinds of attention.

Proximity Over Process

In the early days of a company, titles and responsibilities are often fluid. The person designing the product might also be answering support emails. There is usually no real separation between user research, customer service, and product design; everything is driven by whatever needs doing in the moment. Customer experience, if it is thought about at all, is simply a shared understanding that it is important to care about the people buying and using what you are building. UX, if it exists formally, tends to live somewhere within product, often handled by a single designer juggling everything from wireframes to marketing material. Support is reactive and practical. Solve the problem. Try to keep the customer. Move on to the next issue.

In this kind of environment, the idea of putting UX and support into the same team would not feel strange. It would probably happen naturally, simply because there are so few people doing so many things. And honestly, it might not be a bad setup. What matters most at this stage is that the people building the product stay close to the people using it. When everyone shares the same Slack channel, insights flow naturally. There is no need for formal process because proximity does most of the work.

Growing and the Pains of Specialization

Growth brings complexity. Teams form. Roles specialize. Support becomes a structured function with tools, KPIs, and service-level agreements. UX, if it has been allowed to take root, matures into a discipline of its own: conducting research, designing at both conceptual and detailed levels, running usability tests, and building design systems. CX may appear too, thinking more broadly about the entire customer journey.

It is here that combining UX and support becomes more complicated. The immediate, practical value of support is easy to measure. Customers have problems. Support solves them. UX, on the other hand, often plays a longer game. Good design prevents problems before they happen, but prevention is harder to measure than resolution. In organizations still finding their footing, this difference can create real tension. Functions that show obvious, immediate value tend to be protected. The ones that require trust and patience sometimes are not.

In these environments, putting UX and support together can seem appealing. Support has a clear mandate. UX can ride along. The team looks busy, productive, measurable. But there is a risk. UX, if it is not given its own strategic space, can become reactive by nature. Instead of shaping better experiences upstream, it can end up fixing symptoms downstream. Instead of solving root causes, it can get caught in resolving individual complaints.

That does not mean there is no value in closer collaboration. Quite the opposite. Especially in young or growing organizations, finding simple ways to connect support and UX is essential. Having designers sit in on support calls. Sharing frequent patterns and frustrations across teams. Treating support tickets as signals, not just problems to be solved. These are habits worth building early, before silos harden and proximity is lost.

In more mature companies, the structure is different. UX is firmly embedded within product, with dedicated researchers and product designers. Customer support is highly professionalized. CX has a leadership voice, orchestrating the end-to-end experience. At this point, it no longer makes sense to formally combine UX and support into a single team. Their work is different, their mandates are different, and their greatest value comes from deliberate collaboration, not structural blending.

Should UX and support be part of the same team?

So back to Anders’ question. Should UX and support be part of the same team? Not quite. In the early days, there is a natural proximity that should be nurtured. In the middle stages, UX must maintain a proactive focus, while still valuing the practical insights support can offer. In mature organizations, the relationship needs to be orchestrated through systems and trust, not through shared structures.

There are no simple answers, of course. Every company carries its own history and its own trade-offs. But if you are working in a place where UX feels fragile, or where it struggles to be heard, merging it with customer support will likely just turn UX into a reactive function rather than a strategic one.

I would love to hear from others who have wrestled with this. Have you tried combining UX and support in the same team? Did it help? Did it hurt? What would you do differently next time?

Let’s talk. The best answers come from conversations, not conclusions.