We made it through the first year folks! April 1st, 2012 John and I started full-time on Customer.io. In January 2012 we set a goal:

Have 5 people paying us $10 per month by April 1st, 2012.

And when we hit that number, so began our journey on the Long Slow SaaS Ramp of Death. If you haven’t seen the video, Gail Goodman, CEO of Constant Contact gave a wonderful talk at the Business of Software Conference.

One thing in particular stuck out as a big difference between starting an internet business in 1999 vs. 2012:

Constant Contact’s original billing system cost $250,000!

Whoa. We’d have been dead in the water. Today, you can use Stripe and get it set up in an hour for no cost.

Our business is a testament to doing more with less but we still underestimated the time it takes to build a SaaS business and get to Minimum Critical Mass — which as Gail Goodman defined is “enough scale to pay people”. If you’re our customer this might leave you wondering:

How likely is Customer.io to go out of business?

Unlikely. We’ve been building the company and product to be around for a long time. We’re not going out of business any time soon. Today, if we never made another dime, and raised no more money, we could continue until mid 2014 thanks to some fantastic investors. We’ve also been increasing recurring revenue month over month as you can see in the chart below.

Let me explain a little. The big jump in March was unusual. Our revenue just about doubled. I don’t expect that to continue. Things will probably level off back to 10 – 30% revenue growth month over month.

We’ve taken a long-term view with the company and are focusing on creating a self-sustaining business before growing the team and our costs. Practically this means we all wear many hats. You’ll find John, Asha and me helping with customer support for example. This is really hard to do, and I can understand the temptation to raise additional money and staff up.

Our rules for starting a SaaS business

We’re not yet a successful company, but in our first year, we stayed alive. I want to share a few of our philosophies that make me so proud of our team and what we’ve done in year one.

1. Charge from day 1

If you ever want to charge real money, charge from day 1. You can rationalize that you want more people using it to get feedback, but if it’s not worth paying for on day 1, you should know that and adjust accordingly.

2. Do things that don’t scale (then scale them)

On day 1 our product worked by running map reduce queries every 10 minutes. Someone would describe what they wanted to do and John would manually write the map reduce query to do it. We later added an interface for it and John would take what people put into the interface and translate that into a map reduce query. Then we replaced map reduce with real time processing, and John didn’t have to write map reduce queries anymore.

Had we tried to start by building the system we have today, we probably would have failed. We wouldn’t have understood the things people wanted to do and how they wanted to use the system. John earned the nickname “The Wizard” (like Wizard of Oz) during this time because he was essentially pulling levers behind the scenes to make sure the software did what people wanted it to.

3. Release early, release often

If you have an idea, build it and get it out there. When we released newsletters and transactional emails publicly, a lot of our customers were already using those features. More recently when we released a new dashboard, we did the bare minimum and then put up a feedback form to better understand what people want to see.

When you release, keep your chunks as small as possible. For us it’s at most a week’s worth of work for 1 person. It’s less painful to make a lot of small adjustments along a clear path.

Year 2: Continue on the long slow SaaS ramp of death

There’s light at the end of our tunnel. We’ll hit profitability within the year on our current trajectory. Starting a business isn’t easy and a SaaS business probably means months (years?) of operating at a deficit. Like any business there are amazing days and hard days. But if you love what you do, then it’s always easy to get out of bed in the morning. There’s nothing we’d rather be doing than building Customer.io.

If you’re our customer, we’ll continue to earn your business every day by making Customer.io serve you better.

If you’re not our customer yet, I hope we meet you soon.

Sincerely,
Colin

You’re done writing the copy for your latest marketing email in Microsoft Word or a Google Doc. Your boss has reviewed it, and you’re getting ready to send.

From one WYSIWYG editor to another WYSIWYG editor.

Something about your email now looks a little funky, but you go ahead and send a test to yourself.

Those last minute additions you did appear to be in Helvetica. But the rest of the document is in Verdana.

You delete that new addition, but the cursor keeps getting stuck at the beginning of the line. There’s something else going on here. All you see is a bunch of text that doesn’t look quite right. All you can do is make the text bold, italics or underlined.

Your email looks like crap. You don’t know what’s happening. You don’t know how to fix it.

WYSIWYG editors must be one of the leading causes of hair-loss on the internet. Both the developers who created them are pulling out hair with all the buggy edge cases. People like you and me who use WYSIWYG editors are pulling out hair when the WYSIWYG editor does something unexpected.

Websites with a technical audience often want to move away from WYSIWYG, and websites without a technical audience often try to simplify their editor to the point that you can’t screw it up.

I could go on for hours, no, for days, about the pain WYSIWYG has caused, but rather than that I want to show you a way to do better in a world where WYSIWYG exists.

Focus on the words

Like many nerds, rather than typing in Microsoft Word or a Google Doc, I’ve found that writing in Markdown helps me formulate my thoughts better. It helps separate content from presentation. Every article or email that I write starts in Markdown.

For the uninitiated, writing in Markdown is like writing in plain text with some special formatting syntax. Like two stars to **bold** the text it surrounds.

Markdown converts to HTML in a predictable way. Whether you’re writing for an email or for the web, you can create HTML from Markdown that works the same way every time.

Wysiwyg editors create ugly, unpredictable HTML

As a quick comparison, let’s look at what happens when you copy and paste from a Google Doc.

The equivalent in Markdown is **EXAMPLE** which generated <strong>EXAMPLE</strong> in html.

In Markdown and in HTML, it’s easy as the writer to see what you just did. WYSIWYG editors try to hide the complexity and often create redundant or broken code.

Tools to get started with Markdown

So, now you want to start writing in Markdown. What do you do?

Learn more about Markdown on the official page by its creator.

Start experimenting with Markdown tools. My favorite ways to write in Markdown are:

• Draft (A brand new, hosted markdown editor with some great reviewing tools)
• iAWriter – A Mac, iPad, and iPhone app
• Advanced Sublime Text markdown plugins

How to get from Markdown to an email?

If you’re writing in Markdown, you’re probably going to want to switch to the HTML mode of your email editor and get ready to copy and paste. Gmail doesn’t do this, but Customer.io, Mailchimp and many others do.

For example, if you’re using iA Writer, you can Edit -> Copy as HTML, and paste the pristine HTML right in to your email editor. Draft and Sublime Text as well as almost all other Markdown editors have a way to export to HTML.

Take a look at the code, and at how it looks in the WYSIWYG editor. The amount of code used is MUCH less than our messy example above. The email is smaller in size and will display faster on the recipients screen.

What tools are part of your process?

You can go a little tool crazy. Like people who buy a Moleskine because it’ll help you write like Hemingway — no joke, it will. This is not that. Writing in Markdown will help you focus on your words and not the crazy, unintended things that happen to your words when you use a WYSIWYG editor.

Do you already write in Markdown? Or have another process to share?

Show the world a better way in the comments:

Happy Emailing,
Colin

P.S. Are you interested in workflows? Like how to quickly edit and upload images for use in an email, or how we syndicate our email content to the blog at the same time? Let me know if you’d like to know more about how we do things.

P.P.S. A few people emailed in some more things:

• Lauren G. said Editorially looks like it might help with the problem.
• Nathan M. suggested “A good tip to avoid annoying paste issues: ‘paste and match style’ command + shift + v”

Last night there was a packed room at the class “How to write emails people will read” at General Assembly. We went way over time deep in conversation about email. They eventually kicked us to the curb to continue the conversation. It still blows my mind when people introduce themselves and say they attended because of this email list. Thank you.

One of the things people seem to value in a presentation is real data. Today… for you… I’ve got some never-before-seen real data.

Here are open rate and click rate for this list for the past 17 emails

As the list has grown, you guys haven’t opened emails like you did in the early days when opens were over 50% and the list was tiny. But that’s ok.

Note: The 23% click through was when I forced you to click through to read the content. People hated that!

I’ll leave you with two questions:

1. Can you draw any conclusions from the data?
2. How do your stats compare?

Share your thoughts in the comments below.

Happy emailing,
Colin

P.S. Team Customer.io will be in San Francisco all next week. Mon – Wed we have a table in the “Demo Pit” at the Launch conference. Thursday we’re open. We’d love to meet you – so stop by our table or email me if you’d like to meet up.

Every time you write an email to your customer, it’s an opportunity for you to get feedback and strengthen that relationship. But as your business starts to scale, how do you handle the volume of reponses? You might be tempted to switch your email address to “noreply”. Please don’t do it.

Sending emails from “No-reply” is the death of your customer relationships.

One thing you can do to handle the volume of replies is to split replies among different people. You could give each customer their own contact within your company. Then when they reply they get the same person every time.

Another thing you can do is aggregate all the responses in to helpdesk software. I’d recommend using helpdesk software that is invisible to your customers. When they reply to you, you wouldn’t want to send them an automatic response with a ticket number.

Why send replies to your help desk?

You might be thinking to yourself, “I’m handling all the replies anyway — why put them in the helpdesk?”

Stripe recently talked about how everyone has access to every email within their organization. I’m advocating that at least for customer replies, you want to bring communication in to one place.

• New hires can get up to speed fast
• Everyone on the team can passively stay up to date
• It makes it easy to spot the same person contacting you through multiple channels
• You’ve got history and someone covering for you can pick up the conversation.
• You’ll be able to track things like response time to see if people are slipping through the cracks

I’ll show you how we handle this. You could set up something similar with your tools in about an hour today.

3 steps to getting it set up

1. Create a support inbox for customer replies to emails
2. Set up forwarding for those replies to your helpdesk software
3. Respond to customers from the helpdesk

What tools to use?

I’ll show you screenshots from Google Apps and Helpscout, but you should be able to accomplish this with your email provider and helpdesk.

• Google Apps for Business
• Helpscout

1. Create your support mailbox

To keep things simple, we didn’t go overboard with creating mailboxes. “Replies to Colin” handles replies to the newsletter and replies to customer onboarding emails. In both of those cases, we send the emails from me, and often use the address colin.n at customer io.

2. Forward the email

Most helpdesks work by giving you a really long email address that you forward support email to. To wire everything together, you just go and forward your helpdesk email (in this case colin.n) to the helpdesk address.

In google apps, to do this the easiest way is to create a new group, and add your long helpdesk email as the member of the group.

3. Handle replies like a boss.

If you get too busy and won’t be able to reply to you quickly, a colleague can take over and still deliver awesome customer service. If I’m stuck in a meeting, John or Asha can jump in seamlessly. Rather than everything flowing through my private mailbox, the team can see all previous customer conversations as and is up to date.

We were really excited when we got this flow set. Handling replies to emails can be tricky, and a little chaotic. This gives us structure and metrics. Importantly though, it’s not at the expense of the the experience of people hitting reply.

How have you tackled the same problem? I’d love to hear your thoughts in the comments.

Happy emailing,
Colin

P.S. Are you in NYC on the evening of Tuesday 26 February? I’m teaching “Write emails your users will actually read“. Last time I taught a class people seemed to get a lot of value out of it.

P.P.S. 177 people responded last week to say they were interested in a community to discuss email. It’s up and running, and if you responded, you should see an invite today.

Screwing up gave us the opportunity to write an apology email to our customers. Our screw up affected just a fraction of our customers. But each of them received a personal apology.

Over the weekend I was reflecting on how we handled the situation and learned that Subway was caught selling “Footlong” subs that were only 11 inches! How Subway’s public relations department handled it makes them look like a bunch of jerks.

With regards to the size of the bread and calling it a footlong, ‘SUBWAY FOOTLONG’ is a registered trademark as a descriptive name for the sub sold in Subway® Restaurants and not intended to be a measurement of length.

So, basically they got caught deceiving their customers? They decided to tell you that the joke’s on you. “Footlong” is not intended to be a measurement of length?

I’d never want to be in their shoes.

Being pro-active in your communication during a crisis will help you keep things under control and avoid frustration and unhappiness from your customers.

3 simple rules for when a bug or outage affects your users

1. Find out the root cause of the issue (and fix it)

As quickly as possible figure out the root cause, and stop it from continuing. Ideally you want to write to people to say the problem has been fixed. But don’t delay.

Make sure you talk to the right people on the team so you understand the problem. Then figure out how to communicate it to people in a non-technical way.

People are afraid of the things they don’t understand. So help your users understand why the problem occurred.

2. Identify people affected

Who was affected? How badly? In the event that someone reaches out to you before you have sent the email in step 3, you want to be prepared.

In our case, we had a spreadsheet with every incidence of the bug. I could quickly look up any customer and how they were affected to communicate the information by phone or in chat.

Nothing makes your customers more uneasy than when you’re surprised that they have a big problem.

Nothing makes your customers more comfortable than when you understand their problem before they explain it to you.

3. Email your customers before they email you

Once you know the scope of the problem and who is affected, you now need to create your response.

Act swiftly.

In your email:

Tell people what happened

Succinctly and in plain english. Have enough detail to help people understand it. This proves you understand the problem well and builds confidence.

Show people how they were affected

You could skip this step, but you build non-trivial amounts of trust if your email communicates specifics.

If you tell someone “we accidentally deleted data on your account”, they can’t do much. If you say “We accidentally deleted 5 files on your account. Here are the 5 files” that is way more useful.

Give people enough information that they can act to repair the damage.

Share how you’re fixing the problem

Ideally, you’re saying this will never happen again. But share what specifically you’re doing about it.

Give people compensation for your screwup

If you’re writing your customers with bad news, and it causes them damage, bend over backwards.

Err on the side of overcompensating. We gave people credit to the service depending on how they were affected.

Don’t make people ask for it. Just give it to them.

No business wants a crisis

In the end it seems most of our customers wouldn’t have noticed that anything had happened. But we did. When people wrote back, their feedback was that they appreciated us reaching out and keeping an eye on their account for them.

What are your examples of a crisis handled well? What about crises that turned in to full-blown disasters? Share your thoughts in the comments.