It should come as no surprise that you have to communicate with your customers. Sometimes this will be good, like when you announce new features, and other times it won’t be so good, like when you’re updating during downtime. In both scenarios, though, it’s important you have a reliable way to communicate with your customers. And it’s important that your customers know where these channels are.

You’re even likely to have several channels, like social media accounts, a blog, a status page, a newsletter, and in-app announcements. They all have their strengths and weaknesses, but they can complement one another nicely as long as you plan ahead. There are some key considerations to being successful with these channels, though.

Show Signs of Life

One of the most important signals about a business is recency. How old is the copyright notice in the footer? When was the last blog post? The last tweet? If you have these channels, update them regularly. A month-old latest blog post is a small red flag; but if it’s been six months or more since you posted, customers might question whether the business is still active or that software is still under ongoing development. If you can’t commit to steady updates, then keep the channels to a manageable number, or set clear expectations about how often you’ll communicate. Don’t bite off more than you can chew.

Don’t Forget Existing Customers

Much of your effort will inevitably be about reaching new customers. When you push news out there, it’s often focused on marketing, but your existing customers need information too. Have you launched new features? Is anything big coming down the pipe? Do you need their help testing and providing feedback on upcoming changes?

This is even more important if you create a tool that customers don’t have to log in to on a regular basis. If they just set it up and it works, they may not know about new things you’ve created that could make their life easier.

One of the best ways to do this is by segmenting your newsletter sign-ups and keeping track of who your customers are–and who they aren’t. You can send changelog updates to customers, and with most email newsletter tools you can even automate this process using an RSS or Atom feed from your public changelog.

Scheduling Downtime

There will be times where you’ll need to schedule downtime in advance. You’ll need a way to notify all of your customers–you’d probably mention it on Twitter, but building a simple messaging system into your application can help. If you’d rather not build something into your application, tools like Intercom can be great for communicating with customers about planned downtime.

Handling Downtime

Downtime happens. Sometimes it’ll be minor and few people will even notice; other times, your application will be offline long enough to inconvenience customers. The question you should ask yourself is, “If my application is offline, how do I communicate with my customers?” If you rely on messaging within your application, you’re going to be in a tough spot when it’s offline. Plus, when your site is offline, you’re probably busy working on fixing it and you won’t have a whole lot of time to provide detailed status updates. Sending status updates may sound easy, but it can become quite the juggling act when you’re trying to fix the problem while receiving a constant stream of emails and tweets from frustrated customers.

You could rely on Twitter for downtime updates, but it’s unlikely that all your customers follow you (or will even think to look there). Twitter is all right, but it’s only part of the story; you’ll need a standard status.yoursite.com subdomain set up so that people can find out for themselves what’s happening. It’s equally important that this status site is hosted somewhere outside of your production environment.

This is an area of your business that you need to set up before it’s required. It’s a pretty safe bet that your application will go offline at some point. Prepare for it and put mechanisms in place to keep your customers informed while you fix the problem. The sooner it’s up, the sooner customers begin to learn that they can discover updates there during downtime.

Making Announcements

New features aren’t silver bullets. It’s unlikely a new feature will grow your customer base significantly, but a constant stream of updates and enhancements definitely helps. New features are even less helpful if people don’t know about them or if they don’t have an easy way to learn about them. Set aside time to announce new features on your blog and within your application. If you’re updating frequently enough to send a regular newsletter, that’s a great channel as well.

I’ve even published reminders about existing features, and customers loved it. People can become so familiar with using an application a certain way that they easily overlook features that don’t have attention-grabbing interface elements. Whatever you do, don’t assume that building a new feature is enough; you’ll need a few ways to easily let your customers know about all the great new things you’re building.

Supporting and Listening to Customers

We launched Sifter with a simple email address as our help desk. This worked well enough with only one person answering emails, but if you have more than one, it can get messy fast. Don’t drop the ball when it comes to support: almost every time someone contacts you, they’re either frustrated by a problem or disappointed by the lack of a feature. Make sure your interaction helps turn those feelings around.

Encourage people to do more than write an email to support. Email addresses don’t provide information about the person. If your customer uses an address that’s different from the one on your files, you might not be able to look up their account without emailing them back; and you probably won’t know which browser or operating system they’re using. All these get in the way of providing the best possible support. Invest in a friendly, simple support request form and a good help desk tool. Ideally, the form will cover some standard and common questions, and capture some information about their operating system and web browser. It will make your life easier and save you time, and you’ll have happier customers as a result.

Use All of the Recurring Channels

Setting up your channels of communication is critical. If you can automate them, that’s even better. Regardless, promote those channels heavily so people know how they can keep up with the latest news.

All of your customers are different, and all of the types of channels for communication are different. Social media posts and announcements are more temporary and fleeting. Newsletters are more likely to reach more people. In-app announcements are great, but only if people regularly log in. Blog and changelog posts make for great permanent homes for announcements. Of course, there are plenty of other channels that could be relevant and useful.

As a small business, simple automation can save you a ton of time. If you have a blog and changelog, you can use almost any newsletter service to automatically email out new blog posts to subscribers. You could use a tool like Zapier or a CMS plug-in to automatically post to social media. And you can have code in your application that monitors the feed to know when to display a link in your application.

You probably don’t need to implement this level of automation right away, but these are the kinds of things to think about to ensure you have clear and open lines of communication with all of your customers and potential customers.

Creating an FAQ

In the past, I’ve had a low opinion of FAQ pages. I had always viewed them as a dumping grounds for leftover content. In Sifter’s case, however, the large majority of our support requests were actually more like feature requests. Many of those were features that we had given an incredible amount of thought to, but in some cases, they were features we had no plans to add to Sifter. In most cases, there were blog posts explaining our thoughts on these features, but the reality was that there wasn’t really a good place for content about features that don’t currently–and likely never will–exist. An FAQ was a perfect place for that type of content.

Once we added the FAQ, we received fewer requests for some of these features, and when we did receive feature requests, they were much more thoughtful, considered, and clearly explained. This may have hurt us because we had fewer conversations with customers, but I was comfortable that I was still having more than enough dialog with them.