Today my mind went towards customer requirements and feedback mostly due to having addressed those issues at work this week. We do have a process to handle customer feedback, but it’s not working well enough and it is causing us headache. I mean the feedback is accurate, but the process is not working too well internally.

It’s been long since I last tried to engage developers to discuss 100 Days DX series topics. I decided to remedy that and I did ask in Twitter about the preferred feedback channels.

I expected to see something like “Yeah, I use email” or “Address them directly in Twitter” or “I try to find a person in the company and…” I was expecting to see a media list in preferred order. That’s not what I received. Expectations are different. The story today is wrapped around short discussion in Twitter with one developer.

The media is irrelevant as long customer is not tossed around and it has an effect eg it results to something other than filling some hard drive in the cloud.

We ended up having a small conversation with Michael Hibay who is Enterprise Architect.

Support request is feedback

Although offen feedback and support requests are seen as different items that is not always the case. If you are aiming for self-service (as most of us are) your support requests indicate you have failed in something. Your aim is to minimise the support requests (cuts costs) to offer fluent customer and developer experience. You can’t totally get rid of the support requests, but aim should be decreasing it rather than increasing.

Remedy is often documentation fix, offering another guide or even self-service tool for the developers. That is also why services like statuspage.io have become expected “self-service” tools to see if the API or related system is having issues. Below is one example from https://www.intercomstatus.com/ status page.

If such as dashboard is not offered, developers will most likely email to you or send a tweet. In that case the tweet content most likely is not good advertisement to your product. Analyse the support requests and find a fix rather than add more bandages (support personnel)

The response from Michael was a small surpise to me because I had McLuhan’s “Medium is the message” in my mind. The selected media does affect our communication and it can itself be part of the message. Selected media affects the message. Nevertheless, at that point Michael raised two possible patterns in feedback:

Twitter for urgent small issues

I see the two patterns quite likely. Social media is used to raise the issue (for example outage) for larger discussion. The reporter is using publicity as a tool. The API provider is “pressured” to give some kind of response quite fast since slow response or no response at all is going to cause damage to reputation and it’s just bad customer experience. I’m not claiming that Twitter is the only social media channel to use in feedback. I’m just saying that it’s where I see a lot of company - customer interaction.

Twitter is a medium made for efficiency and urgency. It lets people in on what is happening in the world at that very moment. Hashtags and handles draw attention of a larger audience. I do use Twitter to report problems with services rather than sending email to some faceless corporate email address. Once I even requested a subscription model to be added for one service provider in Twitter. Anyway, it has to be something that does not take too many chars to communicate.

I can see this Twitter pattern quite a lot in my bubble. It’s kind of expected that the provider has an account. Some organisations avoid though have faceless corporate or product handle. I understand that since I’d rather not address issues with such an account (much like faceless email), but that is better than nothing and often employees of the company follow the corporate account anyway. Then they can jump into the discussion and provide face for the customer.

Other channels for complex or delicate issues

Ok so Twitter probably for quick things what ever those might be. Other media for more complex and delicate issues. One of the things I’ve been working lately is the requirements for APIs and setting up that channel to work with rest of the API development engine in the company. Before you jump into throwing email link all around your sites, consider the context aspect.

Think about the context

In my thinking call for actions (CTA) for feedback should be situation and context driven. From where the developer is most likely to need to find quick and easy way to give feedback? In our platform that is most likely at least from API documentation. They are reading the docs to find an answer on how to use one of our APIs. They seek and seek, but do not find an answer. They actually find out that adding a feature like this or that in the API would ease the use in given use cases. As DX Lead I want to capture those ideas!

I agree with Michael that media not the most important thing. Setting the opportunities to engage in giving feedback from spots in consumer’s path or workflow is more important. Hiding email addresses somewhere deep and providing that as only way to give feedback is the opposite of what for example Michael requested:

"Don't make me jump through hurdles to communicate with you."

Don’t just collect the feedback

Now that you have channels which give you tons of feedback - positive, negative, written, indicators - all sorts of feedback. Make sure you have an efficient machine to process the feedback and make use of it. And engage with the customer (or prospect) accordingly. Offering blackhole for the feedback and support is one of the nightmares indicated by Michael.

Create a clear process internally to address the feedback. You will have multiple channels from where the feedback comes. Build a funnel so that you can see all the feedback from one location. Use Zapier and more sophisticated tools to collect feedback together. If you don’t do this, you’ll miss some of the feedback for sure (not taken into account) and you are not able to analyse the feedback as easily, you don’t get the big picture. You might miss a pattern if looking just at individual feedbacks.

Close the circle

Most important thing is that regardless of the media, the feedback has to be processed and acted accordingly. Being able to respond to feedback giver closes the circle and brings peace of mind (occasionally) to the developer. Knowing that someone actually gave this issues a minute or two is better than no response or closure at all.

The thing is that feedback channel is not a one way street. It's supposed to be part of the professional relationship with your customer.

Responding is not always possible if you don’t have any contact information. In Twitter you have. If you have some kind of form or chatbot as media channel, then at least offer a chance to leave contact information for response or further questions.

Quick feedback

Written feature requests or alike is not the only format of feedback you would like to get. You might want to offer simple “Hot or Not” kind of quick feedback buttons in your getting started guides for example. I would not put even any kind of scale in there to make a selection. That easily forces the person to go into “thinking mode” and really start to review what they just read. Was this helpful or not? That’s it.

The silent and ultimate feedback

One nasty form of feedback is just not to use your API. If all else fails, stop banging your head to the wall. Look for alternatives.

Some more to read from 100 Days DX