Landsman’s 10 Rules of Customer Support

I’ve been building customer support tools for about a decade now. Over that time I’ve pretty much seen every random thing a help desk can do.

There’s a few core principles though that I really believe all help desks should strive for. We build our products with these in mind.

These have served me pretty well, both as someone running a help desk and a software vendor creating them.

1. Do not require help desk software registration to contact support

This list isn’t really in a specific order… except for this one. I find nothing more rude and inconsiderate as a customer than to be forced to register for a separate help desk website/application when I go there needing support.

There is NO upside to this for the customer. I need help. At that point I’ve probably looked through your self help docs (well if those also aren’t behind registration!) and I’m getting worried/scared/mad. The very last thing in the entire world I want to do is go through a registration process.

Even better, often you will have registered in the past. Years ago. So now you get the fun of going through a password reset process. This also inevitably causes MORE support as people have trouble with the registration, they get confused by where they are and if it’s the correct place and so on.

The most infuriating part is that 100% of the time on these sites if you go to the sales contact form you can submit with no registration. Better yet, very often those emails go into the same system as support. So a customer that’s paid you already ends up with a worse experience than a potential customer asking sales questions.

2. Do not tell the customer “we’re marking your ticket closed”

I get these all the time. These days they’re almost always automated which makes them even worse. I don’t care if my issue is marked “closed” or not. Guess what, I already know if my issue is resolved or not!! There’s is no reason at all to tell the customer about the internal workings and organization of the help desk.

Also, these almost always come several days after the issue has been dealt with. If the issue is fixed I know that already and it’s worthless. If it’s not, then this only makes me angry as you’re closing my ticket and presumably done working on it even though it’s not resolved to my satisfaction.

3. Do not expose help desk data to the customer

In all but a few very rare circumstances there’s no reason to expose the customer to confusing metrics or data points stored by the help desk software. For example, the current “status” of a ticket. It’s category, who’s assigned, the ticket volume, etc.

From the customers perspective it’s all irrelevant. Even worse, it will often be confusing, especially if the status types, for example, are written in a way that makes sense to the staff in the help desk but not to customers.

4. Do not make the customer jump through hoops in order to acquire better metrics

We all love metrics, statistics, anything that purports to give us an edge. I don’t have a problem with that in general, but you shouldn’t modify the optimal experience for the customer in order to get them.

Don’t make me register before I get support so you can track me one extra step, don’t make customer ID required when I have a simple question unrelated to my account (can’t you look that up from my email anyway!) and so on.

Keep the flow smooth for the customer and work on filling in the blanks on your side.

5. Honor the customers time

This one’s obvious. I think we all know about the cable company and it’s policy of arriving between 8am and 6pm.

Just recently we had the same sort of experience with a Poland Spring water bottle setup. They were supposed to come between 9am and 6pm. OK, annoying but I was going to be to the office by 8:20 at the latest so no problem.

What time did they arrive? 8am and left when I wasn’t there. Now they’ve wasted my time by going to the office at all (which I otherwise wasn’t going to do) and having to reschedule and go there and wait again on a future date.

Wasting the customers time is one of those big ones that get people talking very negatively about you to everyone who will listen.

6. Organize self help resources for customers, not staff

It’s just natural instinct for support staff to write self help documentation in the way that makes the most sense to them. Unfortunately, as they have in depth knowledge of the product if they’re not careful it can often become difficult to navigate for customers.

The worse offenders tend to be support portals that are organized into folders as traditional knowledge base software tends to do. Folders are the worst as their nesting makes it impossible for people without fairly specific knowledge of the topic to find what they need easily.

Search isn’t always the solution either as it’s not uncommon for a customer to know what they need but not what it’s called. Whenever possible try to make self help resources easily visually scannable. This way customers can scroll through information without a lot of clicks and navigation.

It’s also a good idea to track the search terms entered into your customer self service area so that you can figure out what customers think things are called and adjust the docs as needed.

7. It’s OK to say I don’t know

It’s much better to say you don’t know then to provide inaccurate information. Usually this isn’t an issue on the policy level of the help desk, but rather staff don’t feel comfortable saying this to customers.

It’s OK if they don’t know. Replying quickly with an I don’t know, but I’ll find out is better than replying very late with an answer in most cases.

8. You will not use Do Not Reply email addresses

It’s amazing how often you still see these. Never ever ever send out an email for any purpose with a do not reply address. There’s just no reason for it. If someone has a reason to reply why would you ever make that email bounce for them?

If you feel like you must prevent replies then I would suggest still using a valid email and have the help desk software automatically reply to any emails to that address with useful information and where to go if they need further support.

9. Listen carefully

In the constant mayhem of the help desk it’s not uncommon to forget to simply listen. Your queue is a mile high, more are coming in, you’re trying to respond in a timely fashion to everyone and you just forget to actually listen (or read in the case of email).

I’ve done it myself more times than I’d care to admit. When it gets crazy try and take a moment and keep your cool. This is only email after all and the vast majority of help desks aren’t dealing in life or death issues. Be efficient, but don’t skim or be distracted while you’re working tickets.

10. Be human, be helpful

When the customer is coming to support they’re often a bit frazzled. Just be human with them. Empathize with them. We’ve all been on the other end of that support ticket. So stay cool and always be focused on remaining helpful.

Bonus #11

Don’t use your support email address for newsletters and other mass emails. This is done all the time and it’s a huge problem. Newsletters and such are much more likely to be marked as spam. That degrades the deliverability of emails which use those email addresses. Then, in the future when support replies from that address to customers they’re more likely to be marked as spam and the customer not see them.

So use an alternate email address or even a different domain ( vs for example) to send newsletters. That protects your deliverability and you can still have your help desk software track replies to both email accounts.


Article: Why Bitcoin Matters by Marc Andreessen

I was a big detractor of Bitcoin I have to admit. I’ve gone through more than a couple rounds of fighting in the UserScape chatroom on it.

I thought it was all silly geek stuff and maybe it is, but the article linked above has really connected some dots for me. It’s the first thing I’ve ever read on Bitcoin that was well thought out and talked about more than what’s on the surface.

All the chatter about people trading it like currency has little interest to me, but the article points out much deeper possibilities. The article really struck a nerve with me.

The closest thing I can relate it to is someone explaining the web to you in 1990. Could it be that kind of thing where right now is the time to get in and help shape it?

There’s definitely something there. Just like the internet isn’t only for viewing porn, Bitcoin apparently isn’t only for buying drugs. It’s potentially bigger than just making (or losing) a few bucks off a currency trade.

So what to build? How do you contribute? It’s a fairly complex technical challenge to even involve yourself in and base level apps and services are only starting to form to abstract some of that (which is why it smells like opportunity).

Money to be made, surely. But even beyond that, the potential to be in on the ground floor. That rare event that only happens every 10–20 years in tech to participate in something radical and brand new like PC’s or the Web.


Metrics Porn

Bootstrappers and startups in general are addicted to Metrics. Measure everything, that’s the only way to succeed!!!

I’m not totally against measuring things, but if you’re just starting out I think it’s highly overrated. Even when you’re more established most bootstrapped companies lack sufficient volume and repeatability of traffic to make meaningful analysis.

It sure does make for good blog posts though.

A post with how you retained 450% more of your 10 customers when you do XYZ is prime Hacker News fodder. Does it matter though? At such small numbers it’s very hard to be sure.

When I started out there were no metrics other than basic web traffic analysis, so perhaps that’s why I don’t put as much faith in it as others. I’ve managed to sell millions of dollars in software without it. I still see plenty of metrics driven companies go out of business, so I definitely don’t think it’s a magic bullet.

To me, metrics are much more useful if you’ve already established your product. At that point, small tweaks directly == cash. Before that point they’re going to eat up lots of time for at best a small gain and at worst a huge distraction.

This is all related to another phenomenon which is the removal of gut instinct from the equation. I’m a big believer in listening to your instincts. Some things cannot be measured, sometimes measurement limits your options. There’s still a place in business for instincts. Most of the great business leaders of our time have them.

Not to say they didn’t have help, they didn’t measure, etc but there’s an X factor that cannot be calculated by Mixpanel. It can’t be pulled from your Stripe data. Optimizely can’t determine with 99% confidence the optimal outcome of all things.

Something to keep in mind.

9 Tips For Working Remote With Kids

Never lock your office door

You’re going on a phone call and you want to lock that door so the kids won’t come in and interrupt. All you’re doing is guaranteeing a barrage of knocking and yelling that you’ll have no way to stop since you’re on a headset plugged into your computer.

Instead, leave the door just touching the jam. You get most of the benefits of a closed door, but kids can poke their heads in easy so you can play a mime and shoo them away.

You should have office hours

Most people think of working from home as working anytime you want. Some people do work this way, but I’m not a huge fan of it in general. With kids I think it’s even worse. Having set times of day that you’re working vs not makes the entire thing much easier for children to grok.

Get a decent noise canceling microphone

This is obvious, but you’ll want a decent headset that can remove at least some of the background noise. It’s impossible to keep kids quiet so don’t try, you always have to be thinking mitigation not prevention.

Try and be consistent about play time

I try to be as consistent as possible about post work time. We do dinner and then play/read after work. The kids know what to expect because it’s our regular schedule every night.

Limit exceptions

If you make a mid-day exception to your normal working routine to play a game you’re opening yourself up to constant interruption thereafter. The child will require all new retraining 🙂 This makes you sad when they come in to play games all the time and you have to tell them no.

Wait for lunch or after work.

Make exceptions

Sometimes you just need to make those exceptions! You hear a crisis in process, go ahead and find out what’s going on. Some kind of special occasion, take some time to celebrate with them. You’re working from home after all!

Yes, I just contradicted myself. It takes some time to learn to balance the right amount of “I’m working so I can’t acknowledge the outside world” and “I’m home so it’s silly not to do xyz”.

It’s 2014, people know about remote work

If your child does interrupt your call or is making some noise it’s OK to say you’re working from home and sorry for the interruption. Most of the time the other person on the phone just says it must be great to be able work from home!

3pm intrusion

If you have school age kids you’ll probably get interrupted around 3pm when they get home. I find it’s best to allow this intrusion. Take a minute to get a hug and ask how their day went. It gives you a short cuteness break and gives them a moment of attention before they go off and play.

Be understanding

It’s really confusing for kids when you work from home. Home for them is where they relax and play and you working there just doesn’t jive with that. It takes a lot of time and patience to get them to fully understand what you’re doing and why it’s important.

To The Laravel Community

There’s been some recent commentary from Phil Sturgeon and others that people who are excited about Laravel and using it to make great things should cool their jets and think more about PHP as a whole.

Rather than continue to hash it out with them I’d rather talk directly to the community about my thoughts and hopefully they’ll get where I’m coming from.

Laravel is PHP, We Are Not in Bizarro World

If you want to add a line in a twitter bio about Laravel, DO IT. If you want to put on your LinkedIn profile that you use Laravel on your projects, DO IT. You’re not hurting PHP. You’re helping it and anyone who was around during PHP’s dark days should know this.

People will not be confused by this. Employers will not be confused by this. As someone who has probably looked at 1000 resumes for Laravel developers I’ve never seen even one where the only reference to anything PHP or development related is Laravel.

There is always talk of other projects, other systems, PHP versions, on and on. Why would anyone have a resume or LinkedIn profile with literally ONLY Laravel on it. To me in fact, this is the most personally offensive part of this entire interaction. The assumption that people are so stupid as to need this advice.

Package This

Should you write your packages to be perfectly usable completely outside of any framework? In a perfect world yes, of course. Alas, the world is not perfect.

So if you have unlimited time, resources or simply the desire to write packages which work in pure PHP along with the major frameworks DO IT.

If you don’t, I submit that doing what you can do and sharing it is still great. Even if that means it’s only Laravel. If it’s a package that many other people find useful perhaps they’ll be a chance to abstract and help to do it (isn’t this open source where we help each other and even have a huge system of tools to do so?). If not, others in the Laravel community will find it useful. Many people will learn from it if nothing else.

One of the best things I’ve learned working with Taylor (creator of Laravel) is that people shouldn’t be afraid to code no matter their skill level, to code how they want to and to be free from persecution when they do so.

So go forth and code your packages in the way your time, skills and desire allows.

Sharing Knowledge is Good for PHP and Laravel

If you’re someone who wants to share what you’ve learned with the rest of the Laravel community don’t be scared off from doing so. We’ve seen a huge surge in books, tutorials, videos (how’d we get by without Laracasts?) and other information sharing initiatives. Both free and for profit.

These are AWESOME. I can only hope you all continue to do this and to double down on it. Every new developer that comes into Laravel from another language or completely new to programming is LEARNING PHP. Yes, you read that right. They’re LEARNING PHP by learning Laravel.

In fact they’re learning it a hell of a lot better than the ways I did forever ago from the generic PHP books of the day. They’re seeing PHP used properly, organized well, using dozens of external packages from other groups and even other frameworks. This is modern PHP done right.

Human Nature

If you want to be friends with other Laravel developers DO IT. Want to follow their blogs, twitter feeds and learn from them DO IT. There is nothing wrong with this. In fact, it’s the very essence of human nature.

We’re interested in being around the people who are interested in the same things we are. We want to work together on those things. We don’t want to part of the faceless nameless herd.


It’s worse, much worse. Only a few short years ago we were there remember? Millions and millions of developers using PHP, but no fun, no inner communities that were excited and prospering.

Trying to make every meetup a PHP meetup is not the answer. In fact, we’ve already found the answer. Modern PHP is doing better than ever, we need to double down on what we’re doing not step back from it.

We Hates The Learning, Yes Precious We Hates It

Uhhh no, we don’t! The argument that you shouldn’t get all caught up in being a Laravel community because in 5 years you might have to learn a new framework is just silly.

First, we’re developers. If you haven’t noticed we’re kind of addicted to learning. I sit in the UserScape chatroom on the weekends and the team is in there talking about the new side thing they’re working on, the new tech they’re messing with, the new library they found. THAT’S ALL THEY DO!

So, should you not do what you enjoy and what makes you productive today because maybe in 5 years you might have to learn a new PHP framework or even a new language?

20 years ago to play music in my car I carried an shoebox sized CD player with an audio tape adapter, now I stream music from a satellite to my phone and play it over bluetooth.

15 years ago I had to be home or at a pay phone to make a phone call, now most of the world carries a supercomputer in their pocket.

You’ll probably have to learn some new stuff over the next 5 years. I wouldn’t worry about it and if you are worried about it this is probably the wrong line of work for you.

Fight, Fight Like You’ve Never Fought Before! Never Surrender!*

Laravel isn’t even 3 years old. Taylor started working at UserScape just about 2 years ago today. It’s still so very early, the community so very young.

Laravel is the finest online community I’ve ever been a part of. Stay strong.

  • Anytime you can quote Sean Connery you do it (First Knight, 1995).