Happy New Year!

For 2025, I will be publishing a series of practical posts focused on common challenges in support and success organizations, all organized around 5 reasons why we struggle with that particular challenge–with suggested solutions of course. If you want me to opine on a challenge you are facing, please suggest it in a comment.

For today, let’s talk about boundaries, or, more specifically, why support engineers (analysts, agents) can be shy about setting appropriate boundaries with customers, leading to slow to close cases, frustrations on both sides, and escalations.

1. The boundaries are unclear

Scope definitions can be very vague viewed from the trenches. For instance, many software support organizations have a rule that “we don’t write code for customers.” Sounds good, but what does that mean, really, for the support engineers? Are they expected to debug dense, badly thought-out code written by obvious novices? Where can they draw the line?

Support engineers can be very literal, so take time to create tangible definitions and examples for what they can or cannot do for customers. It’s useful to both the support team and also customers.

Lesson: Clarify boundaries so they make sense both to customers and to the support engineers.

2. There is no plan B

If something is out of the scope of support, what are the options for customers, whether within the organization or outside? Can you give them some free self-service information (like sample code)? Is there a discussion forum they can visit? Can you Professional Services team get involved? Are they other avenues outside your particular organization? Being able to present options to customers makes it a lot easier to decline a request.

And it may make sense to create a premium support plan that includes more generous boundaries. Some customers will pay more for a more inclusive plan, and here again it’s easier to decline a request if one can point to an alternative path.

Lesson: Provide options for customers when you cannot help them.

3. The support engineers don’t agree with the boundaries

Imagine you are a support engineer and you are told not to write code for customers—but you write beautiful code, and if you write code for a customer while telling them you are doing them a special favor, you will feel great and also get a great CSAT rating. Tempting, right?

The support engineers who don’t play by the rules are usually well known. Managers need to coach them to do the right thing for the organization, not just for themselves. And make sure incentives align with doing the right thing.

Lesson: Explain and reinforce that support is a team sport.

4. The support engineers don’t know what to say

It’s hard to turn a customer down, especially if your self-identity is that of a helper. Many support engineers just love to help people and are very uncomfortable turning anyone down.

Provide them with techniques and coaching until they can gracefully and firmly explain what they cannot do. Usually the best way to proceed is to explain what you can do, and what other options are available.

(FT Works provides training options for support analysts to say no gracefully and with a clean conscience.)

Lesson: Provide training and coaching on how to say no.

5. The support engineers get overruled—often

This is the most destructive reason of all: support engineers are actually doing a great job setting boundaries, but then customers appeal to their CSM, or their sales rep, or their executive contact, and the word comes down from above that, of course, we will make an “exception” for this special customer. If this happens often enough, support engineers learn that it’s useless to say no and stop doing it entirely.

If you want boundaries to work, make sure they are clear for everyone, regardless of title. And grow a spine.

Lesson: Align the organization around the boundaries.

Are you experiencing boundary-setting challenges? What have you done to overcome them?