How to tell a client a reported "bug" is not actually a bug, but something they need to fix themselves?

Question

Context

I am new to client relations. It's my first year at my company, but even though I am 24 years old, I've never had a job where I had to do customer service of any kind. I program things and often times I need to leave notes for the client or talk to them directly. We work together and we each have our assigned tasks.

My Issue

The current project I'm working on involves a system we set up to allow the client to write copy directly into the program using XML. That way, if something needs changing, they don't have to wait for me to change some string within the program, they can edit it directly and see the changes live on the build.

Every week or so, there are bug notes in the production journal that the client has found, so that I can fix them before the next build. Frequently however, there are bug notes involving the copy itself, things like "Change this word to X" or "Add a line after this sentence: ".

I want to know how I can let the client (or this specific person) know that those bugs are their job to take care of. I'm a little annoyed by these notes but I don't want that to bleed through into my notes. I also don't want to do these myself because we have reasons for why tasks are given to whom, and I don't want these tasks to be assumed to be mine by mistake.

I work in a small company, about 10 people. This project is 2 people, myself and my boss, who is the owner and the one that finds our clients and makes the deals that get us money. No customer service department. I asked my boss, he said I should indicate which bugs are their responsibility, so I want to let them know in the best way.

How can I tactfully, respectfully let the client know that these notes are irrelevant to me and are actually one of their member's jobs?

Answer 1

How can I tactfully, respectfully let the client know that these notes are irrelevant to me and are actually one of their member's jobs?

You can try something like:

• "Hey, can you explain what these bugs are so we can know who to assign them to? It seems like they are related to text copy, which would be John's responsibility. But if they are implementation they would be Susy's - it would be helpful for me to better understand what they are in order to know who to assign them to."

Approach it from the "help me understand" perspective. This is normally non-threatening and does not come across as "you idiot stop assigning me your work." It's also probably best to do this in person so you can have a dialog about it (rather than an email) if you are wanting to minimize it being received poorly.

It's likely the person requesting this will go, "oh you're right, I should fix myself (or have John fix it)" or "I don't know how to commit code changes." If it's the latter, just show them how.

If you want bonus points, you can try to help your customer setup a system to track these requests after this conversation. Be careful doing this too effectively or you might end up in management/consulting.

Answer 2

Dear Client,

Thanks for reporting this. You should be able to amend this yourself by logging onto the content portal at http://coolstuff.example.com/ and the results will be available on the live site immediately.

If you have any problems using the portal, please let me know.

Cheers,

Tom

Answer 3

This sounds like a customer training issue. Bring it up with your manager and you may consider becoming the customer service agent. You cannot just close the bug reports as "not bugs" and respond with a gruf reply of "This is your issue." to the customer.

At an old place I worked there were certain issues that kept coming up so we had documentation we could send to clients on how to perform certain tasks. We also had our customer service department train clients when they first came onto the platform and offered training classes on the various features of our application at various times of the year. This kept some of these types of "We think this is a bug because we don't know how to use it." complaints out of the system. However if we got enough complaints we filed a UX bug where it was not really a bug but needed to be looked at.

Overall the old addage that "The customer is always right" applies to some extent in this instance. If something is not clear its a UX "bug" that needs either training or to be corrected through code changes.

If you dont have documentation to send the client to walk them through how to do this that would be where I start. Once the documentation is written up a nice email such as

Hi Customer,

I noticed you opened a bug relating to the copy on the site. Unfortunatly that is not something I could resolve for you as we have made that configurable for each client.

Attached is our documentation on how to change the various parts of the copy. If you need additional help to make the change, I would be happy to walk you through how to make the change your self so in the future, if changes are needed, they can be made as quickly as possible.

Thanks Tom

sent off to the client will hopefully resolve the issue. I would work with your boss and come up with a form letter that you send clients who open these types of bugs so it is a consistant message to every client.

Answer 4

How can I tactfully, respectfully let the client know that these notes are irrelevant to me and are actually one of their member's jobs?

I've been in this exact situation before. This is basically a communication and training issue. The customer hasn't been trained enough to understand the distinction between a bug (which you must fix) and content (which they must modify). You can help to clarify things and make it better for both you and the client.

I have found that it's best to respond to this sort of report by:

• Indicating that this is not a bug, but is rather a content issue
• Explain who is responsible for the content (perhaps even the name of the individual client)
• Demonstrate how the client can make their content changes. Sometimes there is a help file that can be referenced. If not, you can write up an example (with pictures) to show them how to modify their content.
• Offering to help more if this isn't clear

Basically, you are saying that this isn't a bug, but I'll help you do what you are supposed to do in order to change your content.

You can convey these messages by email, phone, webex, or in-person depending on the context of your project, and the usual practices. After a while, they'll start to understand how these things work.

(Try not to be annoyed. This sort of thing happens all the time.)

Answer 5

1. It's not the fault of the customer.
2. Include something specific of the customer report in your reply.
3. Don't make the customer explain something obvious. You really can't ask:"When you say, you want the word 'Standard' replaced by 'Default', what do you mean?"
4. Tell the customer how to proceed further with the least effort.

Dear Customer,

I received your bug report #489 about [problem]. According to your description, the undesired behavior you have reported is not caused by the code we maintain, but by the XML file in use. Please forward the issue to [responsible person of the client], who should be able to resolve this problem for you.

Best regards,
Tom

This might look simple, but is carefully crafted.

This answer specifically avoids blaming the customer. It is not the XML file "he" uses and created in the first place, it is the XML file that is (somehow magically) used.

You don't talk about financial aspects, unless you are trying to sell a service package which includes maintaining the XML file. The customer obviously doesn't pay you per hour, so he doesn't care at all how cost-efficient it is for your company to have you edit an XML file.

You don't tell him that he should have been able to fix this issue on his own. If this is true, you tell him he is dumb; if this is wrong, f.e. because you didn't understand the bug report correctly, you are an arrogant ass.

You don't tell the customer that you can't do something, especially not when he knows that you can. The customer will properly decode the "I can't fix the issue" as "I won't fix the issue for you".

Answer 6

Try this

"Change this word to X" is a configuration that is under the control of you the customer. It is not bug as it does not throw an error and software reads the configuration properly. In configuration file ... you simply need to change ... to .....

Answer 7

As other answers have covered, training/education may be relevant in the longer term, so that [all] people at the client know it's their job, but for a reply to a specific bug report you might want to start by emphasising the benefits of it being their responsibility:

When we set up the [editable content system] one of the main advantages this offers [you/your company] is that it gives you the ability to make immediate changes to the copy without the inconvenience and delay of having to raise a bug report. Not only does this let you see your changes more quickly, it means we can spend more time on other improvements you have requested.

I'm a developer but in my company's early days (when we were as small or smaller than yours) I also had to handle a lot of support/customer relations. One of the secrets I found -- especially with "awkward" customers -- is, although you know they're being awkward, to not let them know you know. Also, if they're "wrong", you phrase things in a way that gives them an "out" without losing face.

Answer 8

It's important that you are focused on being polite since you're not use to doing customer service. For the most part, everything you've said sounds fine, but the following:

I want to know how I can let the client (or this specific person) know that those bugs are their job to take care of.

Do some training if needed and focus on the idea that you built a way for them to take care of this themselves to save time. Most people prefer this anyway unless they feel it is too complex.

I'm a little annoyed by these notes but I don't want that to bleed through into my notes.

No one cares about your little pet-peeves and customers especially don't. Your problems are your own, so don't even think about mentioning this. If you focus too much on this, you run the risk of saying something rude to the client. Sorry, but you have to get over it. That's why it's called customer service and not customer I'll help you if it's convenient.

I also don't want to do these myself because we have reasons for why tasks are given to whom, and I don't want these tasks to be assumed to be mine by mistake.

Stick with the timeliness factor mentioned above. Once you get them trained to a level they are comfortable doing the task on their own, just let them know you are going to remove their entry from your system. Also, let them know what to do if they have any other problems of this nature besides entering them into your system. Maybe they should send an email for training, usage question and any other non-bug related incident.

Answer 9

As a programmer with a deployed system you are going to constantly be getting these bugs.

The quickest resolution to the problem is to point out the cost implications. I rarely say no to a customer, however I'll phrase things correctly:

"I can make these simple text changes, but you are effectively paying a programmer to do something anybody in your organisation can do. Are you sure you want me to handle these types of changes?"

You'll find that raising the point about the cost will focus anybody's mind.

Answer 10

Clarify the responsibility

if something needs changing, they don't have to wait for me to change some string within the program, they can edit it directly and see the changes live on the build.

Call in a meeting to clarify the responsibility of changing the XML. It's possible that they think they'll only need to change the XML themselves in case of urgency. Tell them what's your point of view about it.

You should keep it small at the beginning. Only talk to the person which creates the bug reports. Maybe he/she agrees with you and changes his/her behavior. If you'll notice that you're not on the same page, you might involve your boss, if they want your team to do the extra work.