57

I work in a support role for one of our products. We have B2B customers and frequently they will contact me with issues. When a request comes in, I let them know I'm troubleshooting and will give them an update soon. Many times, the customers will then subsequently send a meeting notice to me. Sometimes when I join, the issue is fixed and other times it's not. When it's fixed the meeting is really just "what can we do it prevent this in the future", which is a fine question.

The problem is that when it's not fixed yet, I'm starting to be asked to troubleshoot and fix it in real-time. I literally had a customer ask me to share my screen (when I was on their network) and ask me step-by-step what I would try next. Because it's a customer I feel like I can't say no. And I have a very hard time working when someone is right over my shoulder judging my every move. It makes me feel incompetent when I don't know something even though I've been doing this job for years.

How can I ask the customer to give me some space in a polite manner?

1
  • Comments are not for extended discussion; this conversation has been moved to chat. – Neo Feb 1 at 19:37
126

Don't accept a meeting invitation unless the issue is already resolved. You can reply to their meeting invite with something like:

Hello X, I will not be able to attend this meeting as I am still working on your request. Once I have completed the request I will send a meeting invite so that we can discuss the issue.

If your company owns the product, then the customer usually does not need to see any of the internal code, servers,...etc. In fact, you may be violating company policy by sharing your screen of your company's internal systems. When in doubt, talk to your boss and ask how these cases should be handled.

6
  • 15
    I was going to say the same thing. It sounds like a pushy customer who probably wants you to do it "right now." I want to say when you talk to your manager, try to establish a clear line of what you can or cannot do when a customer has a problem. Of course, you already heard and acknowledge the problem but it sounds like the procedure on how to give updates or how customers might inquire about your status are unclear. – Dan Jan 28 at 17:02
  • Same. I'll also send a mail to the manager in advance explaining the situation and your next course of action. – lal Jan 29 at 10:56
  • In my experience as an IT support person, this will leave the customer unhappy and it will not resolve the issue. What will help is ObscureOwl's approach: tell them when it will be done. If necessary, negotiate. Better still, point to company policy or your boss for that. Customers understand you have other things to do. They don't understand being ignored. – reinierpost Jan 29 at 14:13
  • Ultimately the SLA defines the terms. When they state let's say 2 or 4 hours (which isn't uncommon in break & fix business), one cannot always prevent to have someone looking over one's shoulder, or have some security guy following every single step one makes; but sharing the screen goes indeed a little far (I'd call him a control freak). – Martin Zeitler Jan 30 at 3:30
  • Regarding the SLA, that's a business concept. Just cause the SLA gets breached doesn't mean that the customer automatically gets to intrude on the support process. Just work diligently to resolve the issue, and let the business folk deal with the contractual issues that arise from not meeting targets. – Gregory Currie Jan 30 at 8:26
33

Make clear promises, but make sure to under-promise and over-deliver

The clients want to know that their issue is taken seriously and that it's going to get resolved in a reasonable amount of time. Of course they'll try to get bumped to the front of the queue, why wouldn't they?

From their perspective, they're being "on the case" and "making sure it gets done" and that they're not being bumped to the back of the queue because some other client is pushier. Consider it a mental scar: they've probably dealt with a vague vendor in the past and learned that you have to chase your suppliers.

But being diligent can turn into bullying, and that's what's happening to you. They're trying to control you doing your job and that's wrong.

So you need to get them off your back, and the best way to do that is to tell them when it'll be done. You give them an estimate and then make sure to deliver on that, so it's key that you make your estimates realistic. In fact, the estimates should be a tad pessimistic, so that even if something goes wrong or an even more pressing new issue comes in, you can still make your deadline.

They may try to pressure you to advance the deadline and get it done sooner. Don't agree to this. If they don't like it, they can take it to your boss - your boss can say "drop what you're doing for other customers and prioritize this". Even then, you only promise things that you know you can deliver on.

You need to earn a reputation for reliability. They'll still try to push you because that's their job, but they'll be easier about taking "later" for an answer if they know exactly when "later" is going to be.

3
  • 8
    Promising a fixed time when you don't yet understand the issue is just setting yourself up for having to go back and tell them it's more complex than you thought, or that you need to wait for some dependency. Padding your estimates will save you some of the time, but not every time. Just tell them that they're your top priority and promise to keep them updated. – Robin Bennett Jan 30 at 17:21
  • I'd be careful about telling clients they're your top priority when they aren't - if you get a lot of tickets you have to triage. So yeah, generously padded estimates are a good thing, even when you normally have quick turnaround. – ObscureOwl Feb 3 at 9:23
  • I didn't mean to imply that. If they're not top priority you can give them an estimate for when you expect to have time to look at their problem (but be clear that it's just an estimate, not a promise) and who they can talk to if they think they should be a higher priority. – Robin Bennett Feb 3 at 15:22
8

Threat and opportunity and potential train-wreck

If the customer is genuinely curious about how you fix their systems when they break then that is an opportunity for further engagement. Otherwise they're wasting their time and possibly being tempted to do some DIY fixing next time. Yikes! Until you have established shared goals the answer should be no. (You don't have to give reasons because it's them who want to change the status quo and to do that there needs to be a proper discussion at management level.)

It is quite possible that the client, or one of their staff, is keen to understand your wizardry. That's nice, but if they get any keys to the toy box there will be a Sorcerer's Apprentice situation in no time. It's also very handy to have somebody at the customer who takes and interest in the system. It makes it easier to head-off silly things and explain workarounds or the correct sequence of operations or whatever. I still wouldn't do any live troubleshooting but I might explain what I did after the event, and why even if not the exact truth. For goodness sake don't give them any way whatsoever to meddle with things. For example you might DROP a database table to clear some corrupted data, then tomorrow the keen client tries the same spell and everything goes dark.

3

It's tricky because how you deal with some customers depends on their importance to your business. Your management/business leaders should tell you which customers are in that special class of "too important to ignore". For the rest, they need to follow some standard procedure like use the ticket system to make a request and wait for you to contact them when you think best based on their report/history of issues. Avoid responding to customers outside of the ticket system or email unless it's unavoidable. That's because the ticket system and email document everything that happens which protects you from false accusations. So even if someone sends you a text message or calls you on the phone you'd be wise to document what was said in your ticket system.

No customer should be ordering you into a meeting. That's going too far. Meetings are always voluntary unless your boss is the one ordering you.

Bottom line: Tell your management that customer behavior is putting pressure on you and ask them to help you deal with that. They will probably come up with a plan or tell the offending customers to back off from bothering you.

4
  • 7
    Note that "too important to ignore" can backfire; the OP writes "I have a very hard time working when someone is right over my shoulder judging my every move. It makes me feel incompetent when I don't know something", which suggests the risk that a "too important to ignore" customer may come out of this interaction with a negative view of the company. – ruakh Jan 29 at 1:35
  • I would draw a distinction. Yes, some customers are too important to ignore. If you're working support desk, the CEO's ticket jumps the queue. That's not the same as doing the support on-camera like that. What any client (including the important ones) really wants is assurance that you're on the case. One of the ways they try to get that is by making you do it on camera. It's an awful way to do it, and not necessary if you can assure them in another way (like a good ticket system with assurances) that their ticket is getting processed in a timely way. – ObscureOwl Jan 29 at 11:37
  • @ruakh That's true. Hopefully OP talks to his management and they get limits set. – HenryM Jan 29 at 13:40
  • @ObscureOwl I don't support the client forcing the guy into a meeting at all. If I'm him I wouldn't agree to that. Although sometimes it's unavoidable if you can only access a client's system over a desktop sharing program. The client is always able to watch. You don't have to talk to them while you work tho. – HenryM Jan 29 at 13:42
1

Personal computers and their programmers began with youngsters building and programming with each other, sharing what they found and methods they worked to solve problems. I remember at school we knew great programmers who would (try to) take up all our time telling us what they were doing and how we should do what we were doing. This was stimulated by the excitement and the great newness of computers.

As the hobby grew to an industry this friendliness and youthful openness often became the norm. This is in great contrast to the tradition of mature professional activities where a professional, almost priestly boundary was kept between the customer and the people doing the work. Scheduled coat and tie meetings and office space made this the reality. You would never let the client know how easy or hard the project might be. You would work out the best price with your competition in mind and let the user know that was the price for the stated work. Changes required further meetings and more money.

Despite my friendly nature I've learned never to show a user how I simply type a new word into a line of code or change a button color with ease. Whenever I have the user was sure to come back with many ideas and changes they would not have otherwise. "You only need to change a word here or a button there. That's not much work. It can't be too hard." They cannot count the 2 to the n changes in tests and error traps such changes will require.

No matter how well you get along with the customer it is vital that you both understand the professional boundary you must observe. Once they are allowed to see you working at your job they will take offense at your asking for privacy. Once they see how "easy" it is they will take exception to any price you wish to set.

On occasion I have restored this boundary by using a negotiating tactic know as The Higher Authority. "My boss (or the team) now requires that we not allow anyone outside the company, you, to see our screens or our code. Not because of you, of course, but some other worker had let an outsider spot a trade secret (the McGuffin) - big trouble. The policy applies to all of us of course so I have no choice. Please don't be offended." Then you will be able to promise to work on the problem and set a schedule of review.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .