The FT Word – July 2006

By Technical Support

The FT Word

The FT Word is a free monthly newsletter with support management tips. To subscribe, send us email with your email address. The subscription list is absolutely confidential; we never sell, rent, or give information about our subscribers. Here’s a sample.

Welcome

Welcome to the July 2006 issue of the FT Word. Thank you for sharing it with your colleagues to continue to spread best practices in support.

Topics for this month:

· What to do if a customer gets too close

· Should Support organizations take on bug fixing?

· A new FT Works booklet: A Big, Happy, Multicultural Family? Managing the global operation.  Your guide to successful worldwide support, whether you already have a worldwide operation or are considering one.

What to do if your customer gets too close

An anonymous reader suggested this topic, which reminding me of a similar situation I faced with a member of my team many years ago. Of course we want our customers to love us, but what if they love us too much? What do we do when they send us overly-personal presents (and I’m not talking flowers or chocolates, which are always welcome from my perspective)? What if the unrequited flirting exceeds a low grumble?

1. “Fog” or ignore

If a customer makes a comment that the rep finds inappropriate, she can simply not respond to it at all. (I’ll refer to the rep as “she” and the customer as “he” because that’s the usual setup for the problems I’ve experienced, but clearly problems can occur with either gender, whether for the customer or the rep.) For instance, if the customer says “I just love your voice, you must be cute too”, just say “Can you tell me more about the crash you were talking about” and move on. Fogging works best for random comments, less well to undo established bad habits. It also requires a calm attitude from the rep not to come across as hostile or upset.

Along the same line, if the customer sends an inappropriate card along with yummy chocolates, thank the customer for the chocolates and pointedly say nothing about the card. Hope the customer gets the hint!

2. Try humor

A well-timed lighthearted comment can work wonders, as in, “O dear, my husband would be so jealous to hear that” or “I’ll be expecting a ring and a bended knee next.” Humor works well if the relationship is based on kidding around. Here again, delivery is important: the rep must be comfortable delivering the repartee. Don’t try to use humor if you’re not comfortable thinking on your feet.

3. Make a statement of fact

Especially if you support highly complex products I would bet some of your customers are a little awkward socially and may need a gentle reminder to behave more appropriately from time to time. For instance: “I’m not comfortable with this kind of personal discussion. Let’s stick to the product issues” or “Thanks for the present but it went too far for comfort. Let’s stay more professional from now on.”

This approach also works well across cultures in situations where flirting is tolerated in the customer’s culture but not in the rep’s culture.

4. Confront calmly

If gentle reminders don’t work, you will need to be more confrontational. Better confront early on rather than say nothing and risk more inappropriate comments and behaviors later on. A calm, but assertive statement should do the trick:

  • “I am very uncomfortable with this kind of conversation. I want to think that you meant it as a compliment but I find it inappropriate and I’m asking to come back to a professional way of interacting”

  • “I’m shocked to hear you say that. Please stay away from personal comments and focus on the technical issue in the future.”

Don’t expect an apology (although you might get lucky) and put the whole incident behind you in the future: don’t rub it in, at least if the inappropriate behaviors cease.

5. Escalate the issue

With luck you won’t have to get to this point but there are situations where the manager should step in. “I find that the present you sent to X was over the top. Please keep the relationship on a professional level” should suffice.

In stubborn cases the support manager should escalate to the contact’s manager. No company that I know of is foolish enough to tolerate behavior that could be construed as sexual harassment so you will probably see swift action. Of course getting the manager involved could well destroy any hope of a positive relationship with the rep but you would only do it if the problem is unbearable in the first place. Try requesting that a different individual be assigned as the contact if you think that would be the best outcome.

6. Coach the rep

If a particular staff member seems to have this kind of problem repeatedly, she may need some coaching to ensure that she is not unwittingly encouraging flirting and other too-close-for-comfort talk through her choice of words or tone of voice. In my experience, however, the problem is a customer with a poor sense of boundaries responding inappropriately to an appropriately friendly rep, and nothing more. Coaching will help the rep define boundaries better and hang on to the friendliness.

And keep an open mind. I remember a (male) customer who had noted on an evaluation form that he wanted to marry one of my (female) staff members. I called him to see what he really meant and all he had in mind was to make an outrageous compliment that would get noticed. It certainly did…

Should support organizations take on bug fixing?

Thanks to David Perrault for suggesting this topic.

The “normal” setup is that Support handles customers, and any bugs that need fixing are handled by Engineering. The logic is that Engineering owns the code and therefore 1) knows what to do to fix bugs and 2) can use bug fixing as a way to improve the development process and product quality as a whole. But the division of tasks rarely yields an easy relationship, as any support manager is painfully aware.

· Delays. Engineering’s bandwidth is limited. I have yet to work with a single support team that reports getting requests from Engineering for more bug reports, if you see what I mean. For some support organizations the engineering backlog is larger than the pure support backlog. And, as backlogs increase and age, customers get mad. Guess who has the joy or working with escalated customers?

· Extra work. Engineering usually requires that bug reports be accompanied by reproducible cases. Case reproduction can be a very lengthy exercise, even in situations when a short explanation would suffice. In addition, bug reports may need to be vetted through an additional layer in the support team before they can be accepted by Engineering. So an inflexible process creates a lot of extra, boring work for Support.

· Difficult coordination. When the reproduction is not possible, or additional information is required, coordinating with the customer on one hand and the engineer on the other can be very time-consuming and frustrating for all the parties involved.

· Lack of customer focus. Many (sustaining or development) engineers are focused purely on the code and find it difficult to understand the varied and unexpected ways customers use the product, and the business imperatives that require fixes or disallow certain workarounds.

· Low technical skills. Even though we may thing that Engineering knows best, too often the engineers in charge of fixing bugs are not particularly knowledgeable in the specific area of the bug. If they did write the code, they may have forgotten work they did months or years ago.

· No feedback loop. Many Engineering organizations assign bug-fixing tasks to new engineers, to a separate Sustaining organization, or to an outsourcer so that any beneficial feedback from the bug-fixing activity into the general development process is non-existent or ignored.

Faced with a mounting backlog of bugs, many support organizations contemplate taking over the job. After all, many Backline organizations include very competent, code-capable engineers. How hard could it be? Here are some recommendations for how to go about deciding whether to bring the bug fixing function into Support.

· If bugs are being fixed reasonably promptly and you find you can escalate hot issues appropriately, leave bug fixing to Engineering and focus on other issues. I would not volunteer for hazardous duty unless there’s a very good reason to do so.

· Many Sustaining problems can be traced directly to the simple fact that the Engineering VP is measured exclusively on product delivery and has absolutely no incentive to create fixes, let alone to get them done quickly. Before concluding a takeover would help, start by streamlining any cumbersome reporting and communication processes and push for simple, across-the board SLAs and metrics.

· If the individual development engineers fix the bugs in the sections of code they own (in other words there is no Sustaining team), think long and hard before taking over the responsibility for fixing bugs. Once Engineering sees bug fixing as your problem you may not be able to get any assistance at all even though at least at the start you must have training and assistance from the development engineers.

· If Sustaining is outsourced and it’s not working well, offer to take it on managing it. Chances are it’s neglected and will do better under your enlightened management.

If you decide to create a Sustaining team, you will need to staff up! If your current staff doesn’t interact with code at all, expect to have to hire people who can. And remember that your staff may be able to read code and may be able to troubleshoot the cause of a particular bug without necessarily having the skills to fix the problem. Think of the consequences on your budget too: you don’t want to have starve the support side in favor of fixing bugs.

· If you think the divide between Engineering and Support is bad right now, it will get worse once Sustaining moves to the other side. Sure, it’s difficult for Sustaining Engineering to get resources from the development team itself when faced with a difficult bug, but at least everyone reports to the same VP. If you put Sustaining in the Support organization you may need the CEO to referee disagreements. Not a pretty sight!

· Regardless of who fixes bugs, the fixes will need to be packaged both for immediate delivery and for maintenance releases. Since you probably don’t want to take over the packaging of releases, work out in advance who will be responsible for packaging and how it will work in detail before you take the plunge.

· You should not give up entirely on the feedback process into Engineering, but as a separate organization you probably won’t get much of a voice into improving Engineering’s practices. Be realistic.

Despite the dire warnings, hosting Sustaining in Support can work quite well. The two main benefits are a more enlightened approach to customers from the individuals who fix bugs and fewer problems with resources yanked from existing customers and dedicated to future products. But you can’t hope to function completely separately from the Engineering organization, so you will continue to need your relationship-building skills!

FT Works in the News

I just released a new booklet for the managers of global support operations, both those who already have a worldwide presence and those who are thinking about it. It’s called A Big, Happy, Multicultural Family? Managing the global operation. You can find more information and order the booklet here.

Note that if your interest is strictly about offshore outsourcing the booklet to read is Successful Support outsourcing. Information here.

Curious about something? Send me your suggestions for topics and your name will appear in future newsletters. I’m thinking of doing a compilation of “tips and tricks about support metrics” in the coming months so if you have favorites, horror stories, or questions about metrics, please don’t be shy.

Regards,
Françoise Tourniaire
FT Works
www.ftworks.com
650 559 9826

Back to Newsletter Archive

Tagged under: