Customer wants me to fix support requests in real time

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.