The ultimate guide to photography for beginners, coming soon to a bookstore near you!

What struck me, was that there is a huge difference between the different companies present. Some of them were very clear about what they do, who they are, what their ambitions are, and who they are hoping to hire, whereas others do not.

Getting it wrong is a huge problem; You’re in a market competing for a lot of talent, and if the people who might potentially want to work for you don’t know what you do, they’re unlikely to come talk to you.

I’m pretty famous. Or so said the sticker.

If you are running a company, you really ought to be able to put together a mission statement in less than eight words.

Writing a good one is really hard, but here’s a hint: “Striving always to provide better service”, for example, is a terrible mission statement. You may well be doing all of that with your business, but imagine you had a business card that read the following:

ImaginaryCorp: Striving Always to Provide Better Service.

It’s absolutely rubbish: What does the company do? Who are they doing it for? What is their service, and why will it impact my life to improve it?

It’s worth noting that a slogan is not the same as a mission statement. You may recognise ‘Every Little Helps’, ‘Have it Your Way’, ‘Just Do It’, ‘Think Different’, ‘I’m Lovin’ It’, and ‘Delighting you Always’… But in isolation, each of those statements says preciously little about what the business is or does.

You need a good short mission statement

Creating a good short mission statement is infuriatingly tricky, but there are a lot of businesses who have managed to distill their entire ethos into only a few words. It’s valuable, because it can help as a crash introduction to what your business does, and who they do it for.

A few examples of good mini mission statements:

Bose: Better Sound Through Research

Kodak: A Virtual World of Live Pictures

Triggertrap: Creative Ways of Triggering your Camera

As you can see, a good mini mission statement is crucial to getting context about a business.

Let’s go straight to the examples

So, why am I harping on about this? Well, at this Silicon Milkroundabout event, there were examples on both extremes of this.

Dattch

The first example is Dattch. I’ve got to admit that I don’t get the name, but that’s irrelevant, their strapline says it all: “The Lesbian Dating App” explains that it’s a mobile product, aimed at lesbians, and aims to find you a date. Easy, clear, and concise. Brilliant.

City Mapper

The next example is Citymapper: They have an advantage in that their name is very descriptive.

Their banner doesn’t have a lot of content on it, but it’s all extremely relevant: They have maps of cities, they make cities easier to use, and they are ‘the ultimate transport app for London’. A bold claim which I happen to agree with, but the key point here is that they’ve really nailed their message, three times: In their name, in their strapline, and in their description. One glance, and there can be no doubt what these guys do.

Pivotal Labs

Pivotal Labs were another example: They had one of the smaller booths at the show, but they stood out because they had really maximised the use of the space: Two pop-up banners, a skirt around the table they were using, and all very well designed.

The problem? Well, the banner says “Pivotal Labs”, “We’re growing”, “We’re Agile”, and… that’s about it. I would hazard a guess that every single business at this particular careers fair was both agile and growing. Without a useful name (Do you know what a Pivotal Lab does? I don’t…), it basically means that they have all this fantastic space, which they’ve wasted, because you still can’t figure out what they actually do.

Makers Academy and GulfTalent

Finally, I’d like to show you the photo that inspired this article in the first place. On the left is Maker’s Academy. Their banner is really simple, and reads “Learn to code in 10 weeks”. And… I guess that’s all we need to know about them: Their entire business summarised into 6 words.

I don’t think I would have even noticed that, if it hadn’t been for the incredibly poor banner right next to it. “Take on the Challenge Make an Impact. Fast-growing online business. Market leader in 9 countries. Over 3 million users. London. Dubai.” Have you ever heard such an enormous amount of fluff? Of course you want a challenge, make an impact, and all that stuff. But WHAT DO YOU DO?!

Does it matter? Well, I think I wouldn’t have bothered to go talk to GulfTalent to even find out what they do, but since I had decided to write an article, I had to know. So I asked them. It turns out they’re a recruitment agency, that are recruiting themselves. I suppose I ought to have been able to infer that from ‘GulfTalent’, but my point is this: Take a look at the two banners, side by side, and draw your own conclusion: Who would you rather talk to?

TL;DR.

Think very carefully about how you project your company in all circumstances… And if you haven’t yet, find a phrase that can summarise what you do in less than 8 words. And if you ever print a poster, remember to stick them on there.

So, yesterday, when I spotted that somebody had vandalised the Virgin Media box up my street, I decided to get back in touch with them. When I did so, I made a couple of assumptions:

• They would want to know where the box was
• They would want to know a reference number or similar
• They would want to see proof of this vandalism

Luckily, Twitter is a great tool for that; my tweets are geo-tagged, and so I tweeted them a picture of the box. I also decided to add the reference number of the box in the tweet itself.

Now, let’s pause here for a second, and think about the following: if you worked for a large a large utility company, and you received a tweet stating that some hardware you operated had been vandalised, what would you do?

What happened

I… Don’t think you’re meant to be able to see these bits.

So, the correct answer to the above question would be:

1. Report the picture, location, and reference number to an engineer
2. Thank the person who reported it, and let them know what the engineer said. Preferably something like “We’ll send someone out to take a look at it ASAP”)

Instead, I got a message advising me to fill in their social media response form. That’s lovely and all, but all the information they needed to completely resolve this inquiry was right there in the tweet. If Virgin Media need more information from me to prevent further vandalism to their own property, well that’s their problem, really.

I couldn’t help myself, and decided to voice my frustration. Not particularly polite, perhaps, but there you go. And, before you ask, no, they didn’t take the opportunity to redeem themselves.

An exercise in mild futility

What went wrong?

Well, it’s pretty obvious, really.

Either, it’s an individual failing. In that case: Whoever responded to the initial tweet didn’t decide to take the initiative to look into the issue in greater depth, and take the logical steps to resolve the issue (send out an engineer…)

Alternatively, it could be an institutional issue: that Virgin Media have their social media team on the case primarily to placate the social media masses, that another team is actually dealing with support, and that never the twain shall meet.

It’s a sad day, when even what ought to be the simplest, most basic customer interaction turns into an exercise in mild frustration.

And this, ladies and gentlemen, is how not to do social customer service.

TL;DR.

If the full and complete answer to a customer support enquiry fits in 140 characters, don’t make your customers e-mail you or fill in a form. That’s just daft.

The Met is a great organisation, but it has a few challenges around technology. The key one, in my mind, is that they are spending a staggering amount of money for old tech – again and again – so I decided to demonstrate the concept of a rapidly iterating Minimum Viable Product.

One example where there is huge costs involved, is the MDT (Mobile Data Terminal) that is installed in police cars. Though various Freedom of Information requests and conversations with police officers at the hack day, I was able to determine that the hardware alone costs between £4,000 and £6,000 per unit. There are at least 700 vehicles in the Met that operate MDTs – that’s £2.8-4.2m worth of hardware installed in Met vehicles.

Replacing these units with iPads would do some interesting things. At £370 per unit, measuring 700 iPads in millions of pounds becomes a silly-looking figure: It’s £0.26m. I don’t know how long a police car stays in service, but I’m willing to bet that the huge difference in cost would be noticeable in budgets very quickly.

There are several steps to cutting cost; Using commodity hardware instead of custom-made MDTs is an obvious first step, but there are also enormous savings to be had in relation to processes, especially in re-considering how software and systems is developed for the Met, for example

Thinking like a start-up

Since I’m a big fan of lean start-up methodologies, I decided that my demo for the Hack the Police wasn’t going to be a finished product.

In fact, it was never meant to be a finished product. Instead, it’s a demonstration of how you can gain valuable feedback and information from front-line officers by developing a Minimum Viable Product (an MVP). Think of it like a highly advanced and very visual wireframe, that gives the illusion of being a working product. As such, when you are looking for feedback and validation for an idea.

Why would you bother with a prototype?

What the Met would usually do is to spec a full MDT system. 18 months later, it is delivered. Then it gets deployed, the officers are trained, and everything is gravy. Except it’s 18 months and several million pounds later. Some organisations are willing to accept that sort of investment and risk; as a startup founder, however, it scares me: There’s no way I would even consider working in the dark for 18 months, and investing several million pounds into an important project.

So… How can you de-risk a project that is so large, and so core to front-line policing? What would a start-up do to get early product validation and a tight feedback loop to ensure that if you are running at full speed, at least you’re running in roughly the right direction?

Thinking Minimum Viable Product (MVP)

As a police officer, you sometimes have to check people’s details – to see whether they are wanted by police, for example. At present, the procedure is as follows: You go on the support channel and hail an operator. You’re then put in a queue, which can sometimes be pretty long. Then you use the phonetic alphabet to read the person’s details (“Last Name Sierra Mike India Tango Hotel. First name Mike India Charlie Hotel Alpha Echo Lima Alpha, Female, date of birth 20 June 1988″). They look it up in a computer, and tell you the results.

In summary: You use a radio to talk to someone who types something into a computer, and then reads you what’s on the screen. In my mind, that’s like calling your sister, who is a nurse in a busy A&E department, asking her to take time out of her day to Google something for you.

So, my MVP – the smallest possible slice of the Mobile Data Terminal project – is to replace the most common requests done over the radio with an app.

The basic idea is to find an answer to the following statement: “Yes, we do want to replace everything about the MDT. Simultaneously, we want to give you something that can be completed as quickly as possible. If I were to give you an app that does X, would you use it?”. If the answer is ‘yes’, then you go build it. If the answer is ‘no’, then you scrap the idea. If the answer is ‘yes, but how about you do Y and Z instead? That would make more sense to me as a front-line officer’, then you are really onto something: You will be building the right thing, but better than you would have without proper feedback.

My ‘app’ is a type of MVP – a prototype. The idea is to create a highly realistic mock-up of how an app would work, and talk to a series of police officers. I would talk them through a very visual and hands-on mock-up of how something could work.

What’s the benefit?

Well, I demoed this simple prototype to a load of officers throughout the week-end, and was able to make a large number of adjustments as I was iterating through feedback from the officers.

One example: One of them said “Why can’t I check Crimint as well?” The beauty of using rapid prototyping is exactly moments like that. In my mock-up, I am able to add 5 lines of code, and I’ll have added a slider for Crimint.

Compare that with the risk of finding out at the end of a 18-month project, that an officer would like to be able to check Crimint. Adding it into a ‘finished’ product is a much larger task, with huge costs associated. The flipside is also true: What if you included an interface for checking a particular system, that no front-line officer would ever use? In that case, you’ll have spent time and money developing something nobody will ever use. In start-up world, that would be an unacceptable level of waste — and in police world, the same rules should apply.

Enough talking already, show me what it does!!

Launch the app, and admire the fantastic splash screen. With apologies to Simon Pegg:

You’re then taken to the home screen, which enables you to choose the mode you want to use. In the demo, only the top 4 menu options do anything:

Click on ‘Vehicle check’.

You’d be taken to the ‘what to scan’ screen. ANPR mode would be a running mode for doing continuous ANPR scanning. Instead, we’re going to take a look at a single vehicle, so click that button:

Obviously, this is a mock-up – in the ‘real’ version, this’d be a  camera app, much like the one you’d find in your phone. Instead, however, you’d also have OCR – Optical Character Recognition – built in.

Now, after the photo has been taken, the app has gone to the server, and it has discovered that there’s something fishy about the car you just scanned. Instead of showing you any other details, it goes straight into ‘officer safety’ mode, and flags up the relevant details right away. In this case, it flags that this vehicle has certain warning codes associated with it, and should only be stopped with Trojan assistance as a result.

On the other hand, the last incident is quite a long time ago, so the green dot signifies that this information might be out of date. As such, it’s down to the officers to do a dynamic risk assessment, and decide how to handle this particular case.

The user can now click Full Results to get the full results of the details. It shows the picture of the car…

And prompts the user to tick which databases you want to query.

In this case, let’s check all of them…

Press ‘go’, and the details come back right away. In this case, the registered keeper is Steven Smith. The vehicle is insured and taxed, and has three named drivers:

One of the drivers have a red dot next to their name, signifying that there’s something odd going on with that person. Perhaps they have a driving ban, or maybe there is something else you need to know about them before stopping the vehicle. In this case, since the red dot is next to the only female on the list; if the driver is female, that should increase the risk assessment.

Click on the person’s name to check them. In this case, it is shown that this person is known to the Police National Computer, with several warning flashes.

Route 2 through the app

Go back to the main menu and click ‘Person Check’. You’re now taken to a menu where you can choose what you want to scan – a passport, driving licence, or just manually enter details:

Click Driving Licence, and take a photo of the D/L. The app then returns the fully OCR’ed data:

When you scroll down, you can correct any details that are incorrect, before sending the request off to the relevant databases…

In this case, let’s check PNC, DVLA, and Electoral roll data:

The details came back… And should look familiar, because this is the same screen as you got via the other route:

“Hello, I’m Haje,” he says, and clears his throat. “And I’m a nerd”

“Hello, Haje”, the crowd says, in disinterested unison.

Okay, so I’ve never quite been in that situation, but I have tinkered with technologies – and especially online tech – ever since I mysteriously got my first modem to work, and so one of my Frequently Asked Questions, is related to which tools start-ups should be using when they are first starting out.

So, without further rambling… The top tools for start-ups!

Google Apps for Business

Google Apps for Business gives you a ton of useful tools to help you get started

The first two tools I install on any computer are basic communications tools, including a good e-mail client, a decent VoIP solution, and a web-browser that doesn’t suck.

For e-mail, I would always reach for Google’s solutions, for many reasons. Running your own mail servers is a pain in the arse, and there’s almost never a good reason to do so – so sign up for Google Apps for Business and be done with it.

With Google Apps, you get a solid mail client (Google Mail), a great way to collaborate on basic office documents (Google Docs includes a word processor, a very strong spreadsheets solution, and a simple presentations interface), a way of getting information from your customers (Google Forms), and a place to store your files (Google Drive), and much, much more.

For VoIP (Voice over Internet Protocol), you can’t really go wrong with Skype. It has strong encryption, so it’s a relatively safe way of communicating with your co-workers, and it supports video calling, voice calling, and screen sharing. It’s also a solid Instant Messaging client, for when you have to quickly share links or short text messages with colleagues.

As far as web browsers go: Pick any recent web browser that isn’t Internet Explorer (Apple’s Safari, Google’s Chrome, Mozilla’s Firefox, or Opera), and you’ll be fine.

A Web Presence

There are a lot of schools of thought about how you should do your website, and some of them are easier than others.

Personally, I’ll do one of the following: Buy a web domain from Gandi, rent server space with pre-installed WordPress from WPEngine, pick a good starting theme from ThemeForest, and then customise the theme to be slightly different from the basic design, add a blog and an ‘about us’ page, and you’re done.

Other things I would sign up for right away is Google Analytics to track the traffic on your website, Mailchimp to start collecting e-mail addresses (and subsequently being able to ship out newsletters).

Web Presence: The easy option

However, if you want an even cheaper and simpler solution, head to WordPress.com. Note the difference, by the way: WordPress.org is a piece of software that you install on a server. WordPress.com is basically the same software, but you get the server space, too. You can buy a domain from them, and set up a simple website. It isn’t as flexible, but if you’re brand new to websites, it’s better to be fast and foolproof, than getting stuck half way. There’s also epic amounts of help available if you get stuck.

Bookkeeping & Accounting

For bookeeping, there are a few Web 2.0 friendly solutions, but my go-to solution is Xero. Easy to use, easy to understand, relatively customisable, lots of available plug-ins and additional services, and the invoices look pretty, too. Best of all, since your accounts live in the ‘cloud’, it means that your accountant can log in and go through your accounts quickly and easily, without having to lug around shoe-boxes full of rumpled-up receipts.

Customer Support

There are a lot of customer support solutions out there, some of them are much better than others. My two favourites are Zendesk and Reamaze, although I would start with the latter (and then read a few of my articles about how to get customer support right)

Sales

There are a thousand and one ways to do sales, but a key element to getting it right is having all the data you need, and reminders about how and when to do follow-ups etc. I’m a huge fan of Capsule CRM; It is similar to Xero in many ways, in that it is extremely easy to use, yet deceptively powerful. It’s also a pretty affordable option, which is good news for new businesses.

What Else?

This is just a quick brain-dump of some of the tools I use on a regular basis; I know I’m missing out a load of them, but that’s the beauty of the Internet, isn’t it: I can (and will) add to this article later! If you have any specific requests, dump them in the comments, below.

Oh, and if you liked this article, you may also like What Books should I read before I start a company?

Good. Congratulations. There’s just one more little thing I’d like to mention: Empowerment.

I have recently been Tweeting back and forth with a large internet provider, which turned out to be an infuriating exercise in futility. This particular internet provider is very good at community management – in other words, they try to contain any infuriated customers, and they reply surprisingly quickly. However, as far as I can tell, the army of twitter-enabled drones don’t even have access to the regular customer support tools – and they certainly don’t have the power to actually help.

Without empowerment, you may as well not bother.

So, if at any given time, you are thinking ‘containment’, then stop. You are not going to get anywhere, and whilst some customers may be appeased by a tweet in return, others (myself included) are going to be furious. Allow me to illustrate:

A typical reply from this particular media company

So, in this case, a customer tweeted to find out whether the internet was down for anyone else, and this is what the customer support representative replied with. Of course, they do deserve credit for actively monitoring what people are saying about the brand, and yes, it’s great that they are saying they are there to help, but they failed, for one second, to place themselves in the recipient’s shoes.

“Not ideal”? Followed by a sad emoticon? No fucking kidding it’s not ideal. and the “Tell me everything’s all better now” is something you say to a 5-year-old.

But okay, despite the slightly wonky tone on that tweet, they made another mistake: Offering to help, when the Twitter support reps, in my experience, don’t have access to any of the tools they need to offer actual help.

Okay, but I’m not a major utility company, why is this relevant to me?

Not empowering your customer support gang is like sending a fireman into a blaze without a hose. A group hug in a burning house might be reassuring, but it isn’t going to actually help.

If you are an one-man-band, you are per definition empowered: You per definition have the full decision-making power to decide how you can help your customers. This is the best possible situation: you have 100% of the information required to respond to any customer enquiries, and you have 100% control over how your budget is spent. If you wanted to, you could decide it was worth while to get on a plane to go visit the customer in person, to help them with their web browser. Would you? Probably not, but that isn’t the point, you could.

The challenge starts when you add more staff members to the team – and especially if you are adding people who are dedicated to customer support. If they don’t have the decision-making power required to actually help customers with their problems, then you have two problems: Either, the customer support rep is going to be bothering you several times per day to get ‘sign-off’ on solutions – or you end up in a situation like the above, where your customers are being ‘helped’ by people who cannot help.

Fully empowering employees may be scary to some people/organisations, because you are giving away a lot of power to another person, but there are many tried-and-tested ways of keeping staff empowered without too much risk: Set a budget, for example, or set up a tight feedback loop, where you go through a stack of support requests and their resolutions retrospectively.

TL;DR.

Anyway, that was 600 words that really could have been summarised as follows: Make sure your customer support crew have the decision-making power they need to fully be able to help your customers. Anything else is a waste of time.

The unavoidable truth is that even though a question looks as if it is ‘the same’, it will never be identical. The tone of the question might be slightly different, for example, or you may find that one question is subtly different, or asks for information about a different aspect of the same thing.

Two ways of looking at this: Would a canned response be an adequate answer to three slightly different question? In many instances, probably. In that case, the logical conclusion from a business point of view, is to use macros: It saves time, and enables customer support reps to close as many tickets as possible, as quickly as possible.

The other way of looking at it is this: If you were a customer support rep, and you received three subtly different questions on three different days – would the replies be identical if you had to write up an answer? Of course not: You are writing a reply to suit the specific customer, and it is going to be customised – not just on the factual information in the message, but also to suit the tone, flow, and apparent language skills, and level of technical knowledge of your customer. Seen from a customer’s point of view, then, a custom-written reply is always preferable.

Should you use macros in your customer support workflow?

Flow-charts and decision making trees, oh my.

The answer to this question hinges on why your business is doing customer support. Are you overrun with customer support requests, and are you desperately struggling to keep up with hordes of customers asking a limited set of questions again and again? If you are struggling to keep on top of the support load, then definitely; write some good macros, and use them to fend off the requests. If the alternative to getting a canned response is getting no response at all, a customer will presumably prefer to receive a response of some sort — but I would argue that if you are in this situation, then you have a bigger challenge to solve than whether or not you should be using macros…

With Triggertrap, we discovered that breaking away from macros was a crucial step in our mission to leverage an advantage we have over the competition: We are a relatively small company, and we have a relatively small number of support requests per day. As such, we do have the luxury of time, and we are able to give people a personal response.

Deciding that good customer support was important to us led us to make a lot of decisions, including the tools we chose to do our customer support, and, of course, choices we make around the use of customer support macros.

Ultimately, our goal is to give better responses, ensuring  that customers receive replies to all their questions, in full, every time. In turn, the gamble is that the extra time we spend on making customers happier, will translate into direct business benefits, including customers who care about a company that cares about them, and additional spread of word-of-mouth recommendations.

One exception: Step-by-step troubleshooting

There is one key exception to the ‘no macros’ rule, which is when there is a very specific process that needs to be followed to troubleshoot a particular problem. This process, once it has been refined to be foolproof and easy to understand, should probably be kept as standardised as possible: There is nothing quite as frustrating as not knowing quite what the customer has tried to do to resolve a problem, because the troubleshooting guide changes from support request to support request.

In this instance, however, it may be a good idea to create a macro that covers the actual step-by-step process, but top and tail that reply with a more human touch, that addresses any other concerns or questions the customer has added to the ticket.

What is universal, however, is that there’s an oddly unintuitive dark art related to doing good customer support.

This article could serve as a checklist, to ensure that your support requests are dealt with in the best possible way.

What is customer support?

To take a quick step back for a moment, it’s worth keeping in mind what the purpose of customer support is. The best way to determine that, is to think about why companies do support at all.

It doesn’t really matter what type of organisation you are, the key purpose of support is to take a confused, disgruntled, or unhappy customer, and inform, re-gruntle, or happi-fy them. The key to making this happen is all about empathy, and being able to grok what a customer needs, and how you can fulfill this need.

The other thing to keep in mind is that customer support is a fantastic opportunity for standing out from the competition. Even if a customer has a bad experience with your product or service, you can completely save the situation with incredible customer support. There is even some evidence that companies who deal really well with their screw-ups are more memorable, and receive more word-of-mouth benefits, than a company that never makes any mistakes.

I wouldn’t go so far as to say you should make mistakes on purpose, of course. The simple truth is that if you are like most businesses, you’ll occasionally do something wrong. It’s how you deal with the resulting fall-out and tidy-up that will be remembered, so make it count.

How to approach a support ticket

Customers: This is the kind of expression we’re going for…

For the purpose of this exercise, assume that a support ticket comes in via an e-mail based ticketing system. A customer is reporting some sort of a problem they are experiencing with the product. As the eager customer support person, you throw yourself at the task… But how do you ensure that?

The Trigger: why did the customer email us?

There will always almost be a pretty clear ‘trigger’, which is the event that makes a customer e-mail you.

One interesting thing I’ve found in my own business ventures, is that sometimes, customers with old grievances will surface, and try one more time to resolve an issue they have given up on. Be aware that the ‘trigger’ that caused them to e-mail you may not always be the same thing as what they are e-mailing about. Why this is important will become apparent, but suffice to say that it may influence what the customer sees as a suitable solution.

The Ideal Solution: What does the customer want?

In my experience, a customer will usually e-mail you with a question or a concern, with an obvious ideal solution in mind. If their complaint is that “My widget doesn’t work”, they want their widget to work. If the question is “Why does my widget not work on my car”, they are looking for an explanation of some sort.

The upshot of this is that you have to read the support request very carefully: The two questions above might look very similar indeed, but the response they require are vastly different. This is particularly important if you use some sort of macros (i.e. canned responses) for customer inquiries: Send the wrong canned response, and it appears to the customer that you don’t really care about them.

Think about it: If you walk into a grocer, and ask what the price for grapefruit is, and they say “Grapes cost £1.99 per kilo”, would you do business with them?

Before you start writing up your response, spool up your empathy-drive, and think about this: What could you do to make the customer 100% happy? At this point, you’re not deciding whether what you are doing is realistic, or even possible: You are just trying to come up with the absolute ideal solution for the customer; the solution you would implement if resources and the laws of physics didn’t apply.

Why? Because when you know what the ideal solution is, you know what you are aiming for. If you apply the aforementioned resource limitations and laws of the universe, you know how you can make the customer as happy as possible.

The Information Gap: Who knows what?

The next thing to consider is whether there is an ‘information gap’. Do you, as the customer support person, know something that the customer might not know? Could what you know influence their question or concern somehow?

Similarly, you’ll often receive an incomplete support request. You don’t have to be in customer support for very long before you get a “Your website is shit, and nothing works” support request. Now, there is an enormous information gap here: It is unlikely that your website is, indeed, shit. It is also unlikely that literally nothing works. So, the information gap is finding out what the customer is trying to do, and at which point their mission failed.

Identifying whether you have all the information you need to be able to sufficiently solve the ticket is crucial – but sadly often overlooked. It is probably better to not make assumptions, but to follow up with the customer, and find out all the information you need to create a full reply.

Writing up your reply

Okay, you now know why the customer contacted you, what their ideal solution would be, and you have all the information you need in order to give a full response.

At this point, you need to consider the ‘trigger event’ – if this is a new customer, it is probably just that they’ve found a problem and want a solution. If it’s a customer who may have been struggling with something for a while, pay extra attention: They are willing to give you one more chance. Don’t waste it.

Next, think about how you can fill in the information gap. The customer’s request may very well be based on a lack of data, a lack of knowledge, or a lack of skill. The ‘solution’ to their problem may simply be a piece of information, or an explanation for why something works in a particular way. Perhaps there is a workaround you are aware of, for example, that will enable the customer to do what they need to do, whilst a more permanent solution is in progress – that’s perfectly acceptable.

If something has happened that the customer is unhappy with, don’t bother with excuses. Customers don’t care: They don’t want to know whose fault something was, especially if it happened to be their own fault. Customers want:

• A reason: Why did this thing happen?
• An apology: Did you do something wrong? Then apologise, and outline the steps you’ve taken to ensure this particular issue can’t happen again.
• A solution: What are you doing to solve the customer’s query?
• An invitation: Does this solve your issue? If not, what can we do?

A support reply doesn’t have to be long, but it does have to be a full response.

For example: “Dear Tim, We failed to send out your parcel because we ran out of stock. We’re really sorry about this, and have fixed the system so customers can no longer place orders when a product is out of stock. In your case, I have refunded your shipping cost, and your parcel will be with you on Thursday. I am always here to help, so don’t hesitate to get in touch if you have any questions. Best, Me.”

Add a couple of paragraphs to the above, and you have a perfectly acceptable customer support reply: It shows that we understand what the issue is, it explains what happened (note that it doesn’t blame the shipping warehouse for failing to mark the item as out-of-stock. It may be true, but it is irrelevant to the customer – they don’t care, remember?) and it explains a permanent solution, which implies that this issue was an one-off (people are much more likely to endure one-off glitches than systemic problems). Finally, it offers some compensation (a refund of the shipping cost), and aligns the customer with what the solution is: The parcel arriving on Thursday. In the closing statement, it keeps the conversation open, which is always much better than ‘closing’ a support ticket.

Now, this may not be the ideal solution for every customer (they might have needed it by Wednesday, for example), but the vast majority of customers are unlikely to have a problem with the above: It is straightforward, easy to understand, takes responsibility, and offers a solution to the problem.

If the customer does not accept the proposed solution, they can always hit ‘reply’ and demand a solution that is more in line with what they were expecting. However, since you already considered why the customer contacted you and their ideal solution, it’s likely that this wouldn’t be an issue.

One last thing…

Before you send your reply, it’s worth rattling through a quick checklist, to ensure that you have a complete response.

How many questions did the customer ask? How many did you answer? If there is not a 1:1 correlation between those two numbers, there’s a problem.

Check the flow of your reply. A top tip if you’re not naturally ‘a writer’, is to read it out loud. Yes, it feels silly, but if you find yourself stumbling over what you’ve been writing, it probably means there is a better way of saying it. Use shorter sentences. Use simpler words. Use more paragraphs.

Check spelling and grammar. You’re a spokesman for you’re company. They’res no excuse for not getting the basic’s of spelling, gramar, and apostrophe rules right. The Oatmeal might be able to help.

Test all the links. If you linked to something, the link has to work. No exceptions.

Check that your tone matches that of your customer. If the initial request is formal, you may want to be slightly more formal in your writing, and if the original request was a bit more relaxed, it’s probably appropriate to the same in your reply. Although, if the initial request is very sweary and angry, you may not wish to reply in the same tone…

Walk a mile in their shoes. Finally, before you hit send, spend a second thinking about how you would react if you received this reply, as a customer. Would it improve the way you see the company? Would it make you more or likely to use them again? If, on the whole, you’re unconvinced… Start over.

Institutional Learning: The 5 whys

Finally, as a support representative, you’re likely to be the first point of contact for a lot of queries. Some of them are very simple to solve (“Your tracking number is 1234AB”), others are tricky (“I am not able to reproduce this particular bug on the website, and will need to talk to our team of developers to figure out what might be going on”) and others are impossible (“Sorry, we are unable create a Commodore 64 compatible version of our PDF manual”).

The one thing you do have in your favour, though, is that as the main point of contact for a lot of customers, you’ll be able to solve a lot of really big problems, or at least inform the rest of the organisation about what is going on in the wider world.

Especially in small companies, you’ll often find yourself being the ‘consumer champion’ – you’re almost like an ombudsman between the customers and the company on the whole: It is probably going to fall for you to pick a few fights with the company, to ensure that the customer experience is as good as it can be. Don’t shy away from that task: The better the customer experience, the better the product, and the easier the customer support job becomes.

Ideally, as a customer support person, if you get the same question several times, it probably means that there’s something you can take charge of, and fix. If parcels are always arriving too late, you can investigate why this might be – perhaps you are setting unrealistic expectations, for example.

One of the best methods I’ve found for getting to the bottom of these types of issues, is to ask why 5 times.

The way Amazon is structured, it means you don’t get to pick your shipping lead times yourself, it is set by Amazon, and based on country. So, if you are based in Aldergrove in Canada, your shipping time is estimated as 5-10 business days. If you happen to be a 10-minute drive further south, in Lynden, Washington, USA, the estimated shipping time is 18-26 business days.

Now, I’m sure Amazon have legitimate reasons for having a 21-day span between deliveries to locations that are a lazy stone’s lob away from each other, but that doesn’t help us…

What does this mean?

Getting one of these bad-boys to you in something between 5 and 28 days.

I complained to Amazon, of course, and received twenty-four (yes! Twenty-four) “we are still looking into this issue” messages – I opened this support inquiry in May 2012, so it’s getting close to its one-year anniversary. It’s one of the reasons we decided to launch our own shop – it doesn’t look like Amazon are able to sort out this discrepancy, and we were tired of asking our customers for ‘just a few more days, please’.

This real-life situation has taught me a lot about expectations. When we ship from Hong Kong, in reality, the delivery time to both Lynden and Aldergrove are pretty much the same – it’s around 15 business days. The eagle-eyed among you will have spotted the problem: It falls neatly between the two delivery estimates.

What is doubly interesting though, is that we are essentially offering the same service to the same customers, in exactly the same way. Both the Canadians and our US customers go into the transaction with wildly unrealistic expectations, just in two exactly opposite ways. In the US, we are over-delivering by 3 days, whereas in Canada, we are under-delivering by 3 days.

The difference in customer feedback (and, by proxy, in customer reviews and the overall impact on our brand) is enormous.

It does nothing but re-proving the adage ‘Under-promise, over-deliver’;  And it is well worth taking a closer look at whether you are living up to your customers’ expectations.

So… How? It’s actually not very hard, and there’s some simple rules you can follow to make the techies’ jobs as easy as possible. Why would you bother making their lives easier? Well, it’s not because they’re lazy (although some are, I’m sure), but because the easier you make it, the quicker the problem can get solved.

Remember that a good bug report does one thing: It enables an engineer to understand why something is a problem, and then ideally gives them enough information to be able to reproduce the problem on their own system.

A good bug report has the following:

A good summary

Think of this as a headline that can be used to refer to this specific bug. “Problem on website” is a dreadful summary. “Login fails with a 500 error message on check-out page in Firefox, but works in Safari” is great.

Try to strike the perfect balance between brevity and information.

Background information

This is like a pre-amble, explaining the background of what you are doing.

If it’s a bug on a website, a typical condition might be what web browser and operating system you are using.

If it’s a mobile app, you’ll need to know what version of the app and operating system you have, etc.

If you’re reporting a problem with your boiler, the make and model of the boiler, along with when it was installed and by whom, is all great background information.

Steps to reproduce & ‘why this is a problem’

Some bugs are worse than others. If your bug causes balls of fire, it’s probably on the ‘serious’ side of things.

Then comes the description of the problem itself.

Don’t leap straight to the problem, explain how you got there, and what results you expected. The latter is especially important, because what you consider a bug may instead be a clumsily implemented piece of functionality, rather than an actual bug. To you it doesn’t make much of a difference, of course, but it does make a huge difference to how a particular bug is handled by the tech teams.

It is also worth mentioning why the problem is a problem, if relevant, as it can help decide how serious a bug is, how urgently it needs to be resolved, or help contextualise the situation where something might be a problem.

One example of steps-to-reproduce for a clumsy implementation could be:

1) Go to example.com/myprofile
2) Enter username in login field
3) Enter incorrect password in password field

Expected outcome:
4) Login fails with error message: “incorrect user name or password”

Actual outcome:
4) Login fails with “Incorrect Username” error message. This is confusing, because it led me to try with a different username, although it was the password that was entered incorrectly.

An example of a steps-to-reproduce for a critical bug might be:

1) Go to example.com/myprofile
2) Enter username in login field
3) Enter incorrect password in password field

Expected outcome:
4) Login fails with error message about “incorrect user name or password”

Actual outcome:
4) Login succeeds, and takes me to my profile page, giving me access to the editing tools.

In this particular case, it’s obviously a huge security risk; there’s a bug that fails to check for passwords, but still logs users in.

Repeatability

If you can make a bug happen, try to make it happen again. If a problem is intermittent, it’s crucial to mention this under the ‘Repeatability’ header – because otherwise, a developer is likely to reject the bug as ‘cannot be reproduced’, and it may be assumed that it was a bug that resolved itself somehow.

If your bug only happens every third time you try something, this is still relevant information. Make a habit of adding a note on how easy it is to reproduce the bug, even if it happens to you every single time.

Additional resources

It’s often helpful to include a link (if relevant) or a screen shot (if possible) with a bug report – you’d be amazed how often a screen shot shows something that is relevant, or that may help a developer figure out what is going on.

The photo on this page is (cc) Niklas Freidwall.