About Kevin Hale
This past soapbox was simply one of the best in terms of actionable takeaways people can go out and implement. As always, we had a very eager and energetic crowd, great food, and a lot of discussion about building product.
Enjoy!Kevin started out by saying that human beings are "relationship manufacturing creatures." This is why his team is fanatical about creating meaningful relationships with their software. How do they do it? Kevin says that they look at the science of relationships, how dating works. They approach new users like they're trying to date them and existing users like they're trying to create a marriage.
It's like picking your nose on a date
In terms of getting new users, it has mainly been a word of mouth game for Wufoo. One person telling another one about an experience they had with Wufoo. Most of the time this experience was one of the very first ones, kind of like a first date. When people are on a first date, they have very short tolerances for others, says Kevin. For example:
So if you're on a first date and you find out that your date starts picking their nose in the beginning of dinner, there will be no second date. But if you've been married to someone for years and they start digging for gold, you don't immediately divorce them right away. There is something different once the relationship is already established.
The Wufoo team looks at those small moments as a first date with people who come to their website. Obvious things are the homepage, the landing pages, the plan and pricing pages, the login and the sign up pages, but there are a lot of other places which can make great impressions. The very first email you send them, the account creation process, the first advertisement they'll ever see, the first support request.
Our login link is a tiny little dinosaur, and right next to the login link, when you hover near it it goes "RARRR!" This experience is very memorable. Some of my favorite login pages are those like Wufoo, which have a beautiful login page where they have very pretty vector illustrations. The old Flickr login text said "Get in There!" When you contrast that with Google or Yahoo sign up pages, there is a big personality difference, you don't start off your journey with a smile.
Retaining your customers is all about Money, Sex, Jealousy, & In-Laws
Wufoo needed to sustain all the folks who signed up for their service. They turned to the top marriage researcher, Dr. John Gottman (who's work has been mentioned by Malcom Gladwell as well as This American Life). Gottman conducted many studies where he would bring couples into a lab and film them arguing about some little disagreement they had.
He would then predict if the couple was going to stay together for next four years. If he extended the session to an hour and asked the couple to share their hopes and wishes, he was able to predict the divorce rate with up to 94% accuracy. He literally turned marriage into a science. One of his major findings is that the fact whether a couple splits up or not is based on how people fight, specifically how people argue.
Everybody fights, even the successful couples. Everyone fights about the same stuff, which translates directly to a web business: Money (how much you charge), kids (does the tool impact the kids in a bad way), Sex (performance issues on your website, how long you're up and how fast), Jealousy (competition) and In-Laws (your partners, if Amazon S3 goes down you have issues).
The people who create Wufoo support it as well
When you look at a typical singup/conversion funnel it turns out that customer support issues are in between all the places where people can fall off: I can't find out how to accomplish something, I can't find the information I need, Upgrade to paid from Trial, I'm having problems singing up, i can't remember my email address.
How you deal with all these problems lubricates that funnel and makes sure people get through. Focusing on customer support is not a new thing that Wufoo came up with. Craigslist, Rackspace, Zappos are all examples of firms that are fanatical about customer support and the relationships they establish. However, in most companies, there's a big disconnect:
In most companies engineers and designers are divorced from the consequences of their actions. When they create, engineer, design, they don't follow the product all the way through to the end. Support driven design helps Wufoo with that. We add responsibility, accountability and a bit humility on to everyone who works on something which needs to be created for our site.
Kevin mentioned that at Wufoo, it's the engineer and designer who do all the customer support. This helps them drive their product in the right direction.
The main philosophy is do on to others as you wish others to do on to you. Support driven design is: create for others as if you have to support it. The people who do the creating are the people who do the supporting. The reason we came up with that is that early on we had no customers, no users, just three founders, and so it's a purely joyful act of creating, everything you come up with is an awesome idea. Once you launch it, you split your time between bug fixing and new features. You get overwhelmed. So designers and engineers hire customer support people and delegate it as if it's a lower priority. For us, because we couldn't hire someone, we were becoming better at our craft as a result of doing customer support. As a designer, when I would receive a few requests of something not working I could call the guy an idiot a few times, but if it comes in 30 or 40 times, there must be something I can do here to never get this request again. I had direct interaction with the customers.
The discussion continued with how customer support is scaled at Wufoo, their enormous dedication to writing thank you cards for their customers, and many more details of small things which had big impacts. Once again, the entire ZURB team would like to thank Kevin for such an inspiring and actionable talk!
Transcript
Kevin: Software engineers and designers are divorced from the consequences of their actions, and so the people who do the creating are the people who do the supporting. What I came to realize, as I had to do my shifts in customer support was that I was not as good as I thought I was at designing software.
Moderator (Dmitry): Let's welcome Kevin to ZURBsoapbox.
Kevin: Thanks, Dmitry. I'm one of the co-founders of a company called Infinity Box, Inc. I do all of the interface design and did most of the marketing for the first four and a half years of the company. Recently, I think in April, we were acquired by Survey Monkey. We were based in Tampa, Florida, and they moved our entire team, about 10 people, out here to California.
The reason that they were interested in us is because we built a piece of software called "Wufoo." It's a service for helping create content forms, design online surveys, power event registration, and process simple online orders. Basically, I guess, the best analogy for it is like a Microsoft Access for the web that looks like it was designed by Fisher-Price. Even though it's really, really easy to use, it's pretty powerful. It's available in forty different languages, it's used by industries, markets and verticals all over the world and it has a number of very popular brands using our services, enterprise companies like Amazon.com, Best Buy, Wal-Mart, Discovery Channel, Kodak, etc.
In 2008, Jacob Nielsen, sort of the king of usability, actually declared Wufoo one of the top 10 user interfaces for the web, and what a lot of people are interested in is, "What are our secrets? What is part of our design philosophy? What is it that allows us, with a very small team, to create this service that is really, really well done on limited resources?" And that has to start off with our intentions at the very beginning, where we wanted to create a software company. My background is mostly in fine arts, and I wasn't interested in creating any kind of software … software that constantly reminded you that were working inside of a cubicle, basically.
Wufoo was going to be a database application. We thought, "What can we do to take it to the next level?" What we were interested in building was software that people wanted to have a relationship with, because what we noticed is that human beings are relationship-manufacturing creatures. With the things that we interact with over and over again — the brands, the companies, the services — we create these relationships with them.
We anthropomorphize them, and we have this understanding of how we want the personality of the software to be, or we get an understanding of the kind of relationship that we're going to have with it, based on the personality it conveys. So at Wufoo, we're fanatical about creating meaningful relationships with our users, and the way we establish those relationships are pretty science-y.
We don't actually do it with just lovey-dovey stuff and look at, you know, sort of [inaudible @ 03:22] cards and stuff like that. What we actually look at is the science of relationships, sort of like how dating works in science. We approach new users as if we're trying to date them and at existing users as if we're trying to create a marriage, and we look at all the research on what creates successful marriages. Then, we try to apply to our design strategy.
As far as new users and dating is concerned, origin story is the biggest point, right? Word-of-mouth marketing based on, "I'm going to tell someone based on this service or this experience that I had, with this product, service or company and I'm going to share it," usually, those stories are origin stories. So if we think about first dates that we've had or that we have with each other, we have very short tolerances with those first dates.
Here's a good example. Say you're on a first date with somebody, and he starts picking his nose in the middle of dinner. That first date is pretty much over. You won't be seeing that person again. But if you're married to someone for 10 years or so and they're sitting in the Barcalounger and they start digging for gold, you don't immediately divorce them right away, right? There's a difference there once a relationship is established.
So, for us, we look at all of those first moments — the date — that we have with the people who come visit our website or come interact with our services. Obvious things are the homepage, the landing pages, the plan and pricing pages, the log-in pages and the sign-up pages, but there are also lots of other places where you can make first impressions, like the very first mail you ever sent them, the account creation process, that starting interface when they haven't built anything yet and we get to show them something, the log-in link, the first advertisement that they'll ever see to come to your website, and then, also, the very first support request that they'll ever make with the service.
One of the examples that we have if you go to WuFoo.com is that the login link is a tiny, little dinosaur. It's right next to the login link. There's no explanation for it, but when you hover over it, it goes, "Rawr!" right at you, which makes it very memorable. Lots of other companies do the same sorts of things. One of my favorite login pages is Vimeo. They have a beautiful login page that's done with all these really pretty vector illustrations and such.
Flickr had a great one. It was copy; it wasn't a fancy log-in page, but on the old Flickr, before they were bought by Yahoo, the text on the log-in button actually said, "Get in there!" when you typed in your user name and password. When you compare and contrast that to, say, Google sign up pages or Yahoo sign up pages, you see that there is this personality shift and difference. You don't start off your journey with a smile.
Something that we were interested in and that was an interesting first for us was an API contest. We did a third revision of our API code, and it was, like, "It's a new REST API. We want everyone to start building on top of it," but we were, like, "How do we get people interested in it, because it's pretty boring?" "We put some new code out there, and you have to sit in your dark coding cave and make something and maybe you'll make money off of it."
So we were, like, "Let's have an API contest, and let's try to think outside the box on it." Chris, Ryan and I are huge medieval fanatics, so we said, "Let's give away a battle axe." How awesome would that be? In medieval times, none of us would have survived, but wow, if we could've programmed for an axe, that would have been awesome.
So we went to Armor.com and got some blacksmith over there to build us a custom-forged Wufoo battle axe, and then we said, "All right, we're going to give some cash prizes, but the number-one best API contest submission will get a battle axe." We posted pictures of the battle axe being built and being forged … it was really awesome, and we got 25 submissions.
We got a WordPress plug-in, we got an iPhone app, we got an Android app — it was really amazing the sort of apps that we got — and it all had to do with not focusing on money and prizes, but with thinking outside the box so that the impression, the bragging rights, the origin story about "my first programming contest" or "the programming contest that I entered" would be something that you'd want to share with people even if you didn't win.
The other way that we look at relationships are long-term relationships. When people finally sign up for the service, we need to sustain them for a long period of time. We looked at marriage research, and the top marriage researcher you can look to for advice on how to do these things right is Dr. John Gottman. He's based up in Seattle. Features Editor Malcolm Gladwell has talked about him, This American Life has focused on him.
Basically, what he does is bring married couples into a lab and videotapes them for about 15 minutes having an argument or talking about something that they disagree about. Then he's able to look at that videotape and, with an 85% degree of accuracy, predict whether or not those people will be together four years down the road.
If he extends that to an hour and asks them to also share things about their dreams, hopes and wishes and stuff, he can predict with up to a 94% degree of accuracy, which is ridiculous. They showed these videotapes to marriage counselors, priests, sociologists, psychologists, people off the street and people who have been together for a long period of time, and they can't predict better than random chance.
So Dr. Gottman has figured out something. He knows something. He's turned this into sort of a science, and it has to do with how people fight, how people argue. One of the interesting things that he found out was that it wasn't that successful couples don't fight at all or only fight about minor stuff while the people who don't stay together fight about big stuff. It turns out that everybody fights and everybody fights about the exact same things — money, kids, sex, time and … others being jealousy and in- laws.
It turns out that you can map all of those different sectors to customer-support issues that happen in a web application or on a website. Money is the cost of the service or billing issues. Kids … if you're building a tool or a service that has to cater to their users or clients or clientele, those users' users are basically their kids, and if anything happens to them, they get really pissed off about it.
Sex is about performance issues on your website — how long you're up and how fast. Time is what you're working on, what you're doing with your spare time. That's usually the road map of your application: what you're building, what features you're working on, what you're adding to the future of your app.
"Others" are jealousy or in-laws, so jealousy is often the competition and in-laws are partnerships, the people you're stuck with or that you stick your users with. Say you're on Amazon S3 and, if there are issues with that, then you often get customer support issues for it.
What's interesting about this is that everyone fights. Gottman determined that it's not that you don't fight, it's how you fight, and he came up with all these key strategies of how you're supposed to fight. What's interesting about it is if you start off with sort of a typical funnel graph, where you start off with the log-in users, the sign-up users and trailing down to the active users, they paying users, you're typical web application funnel, trying to get people to stay and become active, paying users, it turns out that in between all the different steps is a funnel.
All the places where people can sort of fall off involve customer support issues. I'm visiting a website, and I can't find information I need or I don't know whether it has the feature I want. Going from sign up to trial, I'm having problems signing up — I forgot my password, I can't remember by email address, I'm not getting the email for the confirmation page, etc.
Every single step results in sort of customer support issues. How you deal with that sort of lubricates the funnel and makes sure that people get through fairly accurately and quickly. Focusing on customer support to create long-term relationships is not a new thing. It's not something that we've come up with, obviously. Craig Newmark's actual job title is Customer Service Representative. He's the head of his company, a huge operation going on there, even though it's done by 12 people. The way he sees himself is not as CEO or founder, but as someone who helps other people at a fundamental level.
Rackspace, if you look at all their marketing, they can claim that they are one of the largest technical providers. They have the most engineers, the most money, the best data centers and they're technologically advanced, but that's not the stuff that they focus on. They focus on fanatical customer support. It's the first thing you see. They talk about their customer support people and that it's about the relationships that they establish and that your relationship with them is the better than you've had with anyone else.
Then, of course, Zappos is sort of the king of customer service. Everyone has heard the stories. They actually pay people through the customer support training cycle to quit the job after they do the training so that way the only people that stay are the ones that are committed to the mission, who forego money and understand that this is about the emotional journey. This is about something sort of bigger than themselves.
The way we tie customer service into our design process is that we came up with this thing called support-driven design. The way it works, or what it's focused on are sort of the same things that agile development or test-driven development are focused on. It tries to solve this one, singular problem that software engineers and designers are divorced from the consequences of their actions. Whatever they create or design or make, they don't follow it all the way through the end cycle. Agile development and all that stuff helps you sort of quicken up that pace.
For us, support-driven design is just, like, we'll plug it in directly, and what we do is add responsibility, accountability and a bit of humility to every person that works on something that has to be created on our website. So support-driven design is really simple. It just follows the Golden Rule: "Do unto others as you wish others to do unto you." In support-driven design, you basically create for others as if you had to support it, and so the people who do the creating are the people who do the supporting.
The reason we were able to come up with this is that early on, we started out with just three founders. When we were going through Y Combinator and we got the funding and we were building the app and building the prototype and stuff that we're going to show the investors. At that point, you have no customers, you have no users, and so it's the pure, joyful act of creation during that process. It's 100% development. It's this really sort of beautiful process where no one is interfering with you. Everything you come up with is just an awesome idea.
Then after launch, you find out that you have to start dealing with all these other tasks, so you can't just keep creating new features. It turns out that you're splitting new feature creation with bug fixing and also customer support. Often times what ends up happening is that designers and developers and the founders are immediately, like, "I need to get this stuff off my plate," and they start hiring customer support people to take that off of them. They delegate it as if it's not important.
For us, we realized at a certain point that, because we had limited funds and we couldn't hire someone and we had to do it, we were becoming better at our craft as a result of doing customer support. Now, in the beginning, I was not a big fan of this because it was basically a fairness issue. Chris was doing most of the customer support at that point, and he was, like, "This isn't fair. I shouldn't have to do this all the time. This stuff is coming in 24/7." And so he said, "We have to split this stuff fairly."
What I came to realize as I had to do my shifts in customer support was that I was not as good as I thought I was at designing software. You can go through one or two people saying, "I can't use this," or, "I'm not finding the button," and you can call them an idiot two or three times and preserve your ego. But when it comes in, like, 30 of 40 times, you realize, "Okay, there's something that I haven't done. There's something that I can do here." You realize, "You know what? I could probably change this copy and this guy will never email me again."
What was interesting was that I wasn't as good at designing software as I thought I was, but I was better at designing software because I had this live feedback coming from the customer interaction, and I was really good at helping those customers solve their problems because I was basically ground zero, and I had all the ultimate power to solve their problems. There were no other levels of bureaucracy that they had to deal with in order to get their problems solved. What I'm finding is that the customer support that the founders are delivering is the best kind of customer support that you can have because they're super intimate with the product and service.
So one of the other tenants is that support-responsible developers and designers can give the best kind of support. They don't always, but they have the potential to do so. The reason that I think this is true is something that I coined "the Voltron inefficiency." It gets over this process. If you're too young for Voltron, every episode of Voltron starts off like this: Prince Lothar lives on an evil starship and he wants to take over this planet Aris, and he sends these giant monsters down there to disturb the peace.
Then, five intrepid heroes go and fight off this monster and these robotic lions. The robotic lions would fight the giant monster and they would not be successful, then eventually, the robotic lions can merge together and form this giant robot called Voltron. Voltron would then fight the giant monster and it would not be successful, so then what it would do is, like, Penn-and-Teller this giant, flaming sword out of thin air, and it would slash the monster in half in one strike.
It wouldn't be, like, a knife battle; it would be one strike and it's over. As a child, all I could ever think, because this happened in every single episode, was, "Why the "F" don't you start with the flaming sword and the giant robot in the beginning? Why do you start with the tigers and stuff?" Obviously, we know why - you've got 30 minutes that you have to fill up. But at the time, it seemed super inefficient.
That's customer support for most people nowadays. You go through first tier, which is an automated answer that totally sucks. Then, you talk to a customer service representative. They have troubles or they don't speak your language or you have some sort of issue with them. You have to get it sort of elevated, and then the manager says, "Oh, I can do something," they do a clickety-click-click, and it's done. So for us, we figure that by having the designers and developers do the customer support, you're able to basically put Voltrons with flaming swords doing customer support.
We're actually not the first ones to do this, either. Paul English is one of the founders of Kayak, and he and all the engineers do support. There's this really great quote by him. It goes: "The engineers and I handle customer support. When I tell people that, they look at me like I'm smoking crack. They say, 'Why would you pay an engineer $150,000 to answer phones when you could pay someone in Arizona $8 an hour?' Well, if you make the engineers answer emails and phone calls from the customers, the second or third time they get the same question, they'll actually stop what they're doing and fix the code. Then, we don't have those questions anymore."
What's also interesting that they do is that their QA control goes like this for customer support. There's a program that they wrote that emails out a random email from customer support from the prior day to all the employees and the investors in the company, so it could be one of your emails that you handled for customer support that goes out to everyone in the company, and if it's not stellar, you're in big doo-doo.
What's interesting about that kind of culture, and what we've seen first-hand, is that when everyone has to do customer support, the features that make software complicated and unfriendly become everyone's problem. Everyone starts looking at, "Hey, my customer support shift is coming up, and I notice there's no documentation, here, there are no tool tips for this thing, this thing looks a little confusing, this documentation hasn't been written," etc. There are all these checks and balances in place because people know that it's going to be their responsibility later on and they want to have a good answer for it.
Ultimately, what ends up happening is that support-responsible developers and designers create better software, and this is actually supported by some recent research. Jared Spool, who is a big talker about usability and usability testing, wrote a recent article on March 30, 2011 on User Interface Engineering, a great website for articles about usability, and he has this quote about this study that they did about exposure hours.
He said, "As we've been researching what design teams need to do to create great user experiences, we've stumbled across an interesting finding. The number of hours each team member is exposed directly to real users interacting with the team's designs, there's a direct correlation between this exposure and the improvements we see in the designs that team produces."
Direct exposure, so not just looking at the documentation or looking at videos of people doing stuff. What they said is that it only works if you're being exposed to these users a minimum of at least two hours every six weeks.
That's interesting because in our company, we make everyone do customer support, and you have a shift between four and eight hours every single week. Lots of companies make everyone do customer support. Amazon is pretty popular for making every Amazon employee do the call center one week a year. FreshBooks has a two-month training cycle in customer support before people can do whatever job they want to do, and they have this huge personalized graduation ceremony for those people who move on to do their jobs. And then, of course, Kayak also does it.
Here are some of the metrics of the kind of support that we expect from our developers and designers: We have a little over 500,000 users on our system. About 5 million people see a Wufoo form or report whether they know it or not. We get about 400 issues a week. We send out about 800 or 900 emails, and the average response time for any support time for any support ticket is between seven and twelve minutes, between 9:00 a.m. and 8 p.m., and between 8:00 p.m. and 12:00 a.m., it's about an hour, then on the weekends, it's every four hours.
Let me bring this graph up. This is what happens when you have support-level developers and designers do that support. This is a graph of the first four years of Wufoo. We didn't do any paid marketing; it's all word-of-mouth marketing at the time.
This sort of nice, curved graph is our user growth, and this is our support growth at the time. I think, up to that time, we were only at six to seven employees, so we were able to support this user growth with no marketing dollars, just on word-of-mouth marketing that happened mostly through customer support, because our philosophy that we told a lot of people is that customer support is an opportunity to make someone into a fan.
We never see it as a problem. We always see at as this awesome sort of lead. This person is already using the service. They're having an issue and they're inquisitive and they want to have it solved. They're asking for sort of an excellent experience.
What's interesting here is the reason we're able to do it with so few people is that we also spend a lot of time scaling customer support. You hear all these companies looking it at it like, "Oh, God. How do we scale for the users and the system and all that stuff?" For us, we figured what we have a problem with is that if everyone has to do customer support, how do we scale that? We had sort of a profit revenue sharing scheme, so the more people we hired, the less everyone is going to take, so how do we scale this one thing, excellent customer service, that can't be scaled with servers and equipment and machines?
The way we do it is with a really simple tool. Our support is just a simple Gmail. What happens is that we come onto a shared Gmail account that everyone has access to and we just use the tags to assign things to different people, and anything that's not archived is an open ticket. So once it gets responded or waiting for a response to someone, it gets archived.
So there are obviously some color-coded tags with names and initials to know which developer is responsible for it. We don't track tickets over a long period of time. It's not integrated on track with SBN and all that stuff. It's all about direct, immediate customer support-related problems. We have those sort of other bugs that developers and designers are aware of. That's in a different sort of system.
We also ended up building some tools for that Gmail. We actually build a Gmail plug-in that actually ties in with our database interface and it shows up, there, in the side in the Gmail account. It will parse through the Gmail, figure out the email, the account name and all that stuff and it shows all the stuff that you can log into our account and all that stuff.
We also spend a lot of time on FAQs, documentation, lots of screencaps and videos. You can't launch a feature in Wufoo — it's a policy in our company — without writing the documentation first. All the things that need to be done to support the user have to be done ahead of time. We do lots of tool tips all over the application so it's "in help" sort of stuff. The whole point is that by helping users help themselves, you'll reduce what the customers need from third-party people.
We only do email support, also, no phone support. I did phone support for AOL broadband technical support for a couple of years back in the day, and what I found is that it's really hard to scale. It's hard to give really great customer service for it, and it's hard to prevent people from being sort of addicted to that phone support, because things we can't do on the phone that we can do are email is give links to people, show screen shots, step-by-step tutorials where they don't have to write everything down.
There are a lot of things that we can do with email in addition to using really nice things like text expanders, so we have of [inaudible @25:54] for most common problems like, "I forgot password," "I forgot how to log in," "Where's the information about billing?" All the stuff that's usually on the website, we could have these little extenders. You type out three words, it feels it all in and includes the links to different parts of the website. It helps them learn that the way you can get this information faster is by doing a little browsing on your own. It helps to reduce the customer support that comes in.
Our philosophy on support tools is very big. We actually spend a lot of support time on the support tools that we build inside of our application. I'd say that a third of our time is spend building internal tools to help support our developers, designers and the software itself. So a lot of things that we build and create for ourselves actually don't get seen by customers, but they get the experience because of the speed that it helps us generate.
This is actually reflected by a Facebook engineer Yishan Wong. He wrote this article about internal tools, and he said, "As I've come to work with Facebook, I've come to understand that the best way to save money at a company, the best way to offer this great customer service, or a better service, and be a lot more profitable, is by building the proper tools to help us do so."
It's an amazing article in which he talks about all the different tools he built for Facebook, and it just shows behind the scenes how innovative and how amazing the work that is done is that supports the mass culture that Facebook has developed.
We have something that we created called the PQP/PHP Quick Profiler. It's a tool that we open sourced, but it helps us identify SQL limitations or design limitations. We have lots of internal tools, and we also do experiments. On the support request form, we did this one experiment after we saw Kathy Sierra speak. She wrote a lot about creating amazing experiences with users. She said that one of the problems with customer support is that there's this divorce between the emotions that I have coming into it and the tone of the copy that meets me when I see it on a website.
When I'm pissed off about something and I go to a customer service representative desk at, say, Target, they see my face, they see the nonverbal cues, and they don't act super cheerful. They're prepared for it and act accordingly. She said it would be great if we could just have face recognition on the software.
We're very far away from that as far as web technologies go, but what we figured we could do is just ask directly. We created this emotional state drop-down right on the support request form, and it just asks you if you're excited, confused, worried, upset, panicked or angry. It's just called "emotional state," and we made it as neutral as possible. We didn't want to have the copy be, like, "How does this make you feel?" That immediately makes you want to punch someone in the face.
It reminds you of a psychologist or a therapist that you don't want to be in the room with, and you're already pissed off. If you're dealing with a browser or computer, they would already know that and you don't have to tell them. So for emotional state, we said, "Let's just make it, like, 'What's your browser? What's your operating system? What's your emotional state?" and just get it through as fast as possible.
We didn't actually do anything different with a customer sort — we always answer it as it comes in. We just were, like, "Let's look at the data, see what happens and see if it's interesting." What we found out was that people had a huge response to it. We had all these articles at the beginning saying, "Wow, I realize, because they put the emotional state drop-down there, that someone is going to care about this and that some human is actually going to look at this."What ends up happening . . . think about this. You're pissed off and angry, and you can't help but get it out to someone. You're forced to use email to get it out, to communicate those emotions. The way you do it is by typing in all caps, you misspell a lot of things, you use curse words, and you waste all this time doing this emotional stuff that you have to add to the copy, and it's not any help to us, the developers and designers who are trying to troubleshoot your issue.
So what ended up happening is we put this up there, and BAM, it just cuts that. It cuts down the amount of swearing, it cuts down the amount of all caps emails coming in and it cuts down the tone of the people coming to ask us for help. They're able to now focus on the problem at hand, which was interesting. We didn't expect this at all. We also found out that most people didn't abuse this.
We thought everyone would put "panicked," because they thought it would just shoot them to the top of the support queue, and I guess because there was no reinforcement of that, none of that happened. Most people were mostly confused about stuff and very few were upset or angry.
All right. We're going to wrap up. I'll leave you with this. There was a study done by Harvard Business Review about the discipline of market leaders, and they say, basically, that if you want to be the market leader in your area or industry, there are only three ways to do it. And based on how you want to do, you have to totally focus and construct your company to focus along those pathways.
If you want to be the best-priced product, you have to focus your company around logistics and figure out how to be efficient with the resources at hand. That way, you can offer the cheapest price to the consumers and that's how you become the market leader. If you want to be the best product out there, you focus all of your money on technology and innovation.
Apple is a really good case study for that. If you want to be the best overall solution, you focus your money and resources on being customer-intimate. Customer intimacy is about focusing on relationships and having this sort of long-term approach, this sort of building equity and value for your users. You see this happening with hotel companies and groups.
What's interesting about those three different pathways is that only one of them doesn't require huge amounts of money, lots of people and lots of engineering of resources to make it happen. Anybody can be customer-intimate. One of the classic examples I give about this for our company is that in addition to making everyone do customer support, the way we add an additional level of humility is that we say, "You also have to write thank-you cards to the people that pay your salary."
So every week, all of our engineers and developers and designers have to write hand-written thank-you cards, and a program that we wrote randomly brings up customer names and addresses that we send the cards to. People actually love them, and they're super simple. These things are the cheapest things ever. They're simple, cardboard cards. We bought a bunch of dinosaur stickers from this Chinese company, and we just say thanks in our own handwriting. Every single week, we write these out.
The way it goes, and I've written so many of these, is, "Hi. My name's Kevin. I'm one of the developers for Wufoo. I just want to say thank you for using our services. You've been with us for such a long time now, and we just want to let you know that we're honored and delighted by your support. People like you help us achieve our dreams, and we won't ever forget that. So thank you, on behalf of the entire Wufoo team. Sincerely and respectfully, Kevin Hale."
So thanks, guys. That's my presentation. Appreciate it.
Dmitry: Thank you, Kevin. So let's do some questions. You guys listening to this probably had some questions come up during the talk.
Audience Question: Did you mention that you have this in a [inaudible @33:57] that we can access?
Kevin: Yes. You can go to our Twitter account, @Wufoo.
Audience Question: [inaudible @34:08] The graph that you showed was really interesting with your organic growth. I'm wondering what your focus was on the external part of that. Providing the customer support is awesome, being customer-focused, but when you've got some publicity event or something, how would you engage with the media, PR, etc. Do you spend much time on that, if any?
Kevin: I don't think we got much media and stuff that first four years. I mean, interviews came down, and as we had speaking engagements that were offered, we went and did those as quickly as possible. But the thing is they're shifts, the support shifts. There's always just someone on duty.
Nowadays, we have two people on duty because of the level of support that comes on, but at that time, it was just making sure someone was always going to be dedicated, that they're not programming that day or during those hours. They're dedicated to doing the best job possible to help whoever is asking for help. Everyone else is able to do all their normal jobs and functions and stuff. It's not that everyone is doing customer support at the exact same time. Yes, here.
Audience Question: [inaudible @35:14]
Kevin: Did I ever what?
Audience Question:[inaudible 35:18]
Kevin: I'll tell you, peg it right at the very beginning. Actually, when we pitched this idea to Y Combinator, we pitched it to a content manager, and the way we described it was, "You know how you can have the forms and you fill out the data and manage all that data on the admin side, we'll have something called "reversible forms," so people on the public side, like public comments and stuff, and you can have the content manager do this kind of stuff, and you can mix and match."
That sounds confusing as shit explaining it to someone. So the programmer looked at it [makes a noise]. "How about a form builder?" And we were immediately, like, "Google form builder." We were like, "No, build people suck. We don't want to do that. We want content manager. We want to be like WordPress and stuff."
Thank God, he saw that as a market opportunity and convinced us. That was a huge pit right at the beginning. I feel like if I had tried to explain "content manager with reversible forms," I would totally be dead in the water from day one. No one could tell that story, or no one could say, "I had this awesome experience with the reversible forms/content manager people."
Dmitry: You kept going back and forth with that, right, in that meeting?
Kevin: Oh, yeah, we did, and what was interesting about it was it actually helped us get the funding because we pushed back on it a good amount, and he saw that we had some cojones, there, and it made him like us a lot more. But luckily, logic prevailed in that instance. Now, there are plenty of ideas that he's floated to us — he's a crazy person — that we did not fly with and I'm very glad that we didn't, but that was one of the key ones.
Another pit is actually payment integration. We actually never thought doing forms that we would want to do payment stuff, but our users were begging us. These people I'm sending up for my workshops in registration and I was wondering if I could somehow collect the payment from them right at this step, because this is the most logical step in the lead conversion process. That ended up being a huge boon to our business. Tons of people use our payment app. I think we process over $500 million in payments since we launched, so we generate a whole sort of economy for our users.
Audience Question: Wasn't [inaudible @37:31] be buyer for that . . .
Kevin: Oh, definitely. We knew at the very beginning that we wanted to offer a free service, but always had a paid service. And we never launched with just "free only" and then eventually added a payment. We always had both together. I think it's because we were fairly conservative at that time. I think at the time, in 2006, everyone was doing free only, and so we really looked like suspenders and trousers, saying "We're charging. We're charging no matter what. We need money." Now, I think everyone has gone to that model, and we get asked all the time about our pricing experience and what we've done with pricing. We do experiments in little things all the time.
Audience Question: [inaudible @38:11]
Kevin: I can't answer that, I'm sorry. I'll tell you this about charging high prices and why you should consider doing it. I do this three-hour workshop talking about premium companies and all these different premium case studies and models. The reason people offer multiple-tiered plans is that it's something that you do in economics to capture consumer surplus. Anybody know what that is? No economics people, okay.
Capturing consumer surplus is basically like this. Let's say I'm a poor dude and I go to this pizza place and I have my rich friend with me who's an investor. We both go to this pizza place, and we both go, "Holy crap, that pizza is so friggin' ridiculous." The guy charges, like, $10 for it. And the rich guy goes, "Wow. I would have paid $50 for that pizza, that was so good." The pizza shop owner lost $40 in that transaction right away. He didn't capture the consumer surplus. So the whole point of doing these tiered prices is that you offer multiple plans because you know that certain people can pay more for it.
The most logical is resources used — people who are more collecting more entries or using more data or need more storage, those people have a greater need and therefore, should be willing to pay money more for it. To charge only one price means that you're making this bet that the average that everyone who uses your service, it's going to be above that average, and it's really hard to know that ahead of time.
The tiered-pricing plan does the high pricing, and it also has this psychological affect called "priming." Price priming basically means that we're really bad at understanding economics and numbers in terms of absolutes. It's hard for us to remember all the different comparisons from all the competitors beforehand.
Once we see a set of options before us, those are the options that we focus on. So when you see that high-priced plan on there, immediately, you're brain goes, "Okay, this is what I'm starting with, this number" if that's the first thing you see, or if you see it within a set of numbers. Then, you completely adjust your relative notions of what's expensive and what's cheap.
Audience Question: [inaudible @40:46]
Kevin: Well, we have a vision. There's always the vision in place for what we want to have done. I guess you do alternating cycles, so a lot of times, we're doing stuff on a most-requested basis. We had feature requests that lasted for two years before we implemented them. Then, we were able to go back to all those users and tell them that we had that feature set.
It didn't destroy our business having feature requests that lasted that long. But we do these interesting sort of [Spencer] advance for our developers and designers, because you try to keep it interesting for the people that work on the software as well.
We used to do this thing called "King for a Day." It was actually "King for a Weekend." Someone gets elected to King, and he gets to decide what the company is going to work on for the next couple of days. We have a crown and a scepter and a purple robe, the whole nine yards, and the King goes around saying, "You're going to work in this. We're going to do this. I always wanted this feature. I hate dealing with customer support." So you have sort of the vision being done there.
Every week, we reassess what we're working on, and then every three months, we have a longer-term plan that lays out roughly what we want to work on, but obviously, any emergency that comes up, we tackle those as needed.
Audience Question: [inaudible @42:17]
Kevin: How did it happen? Actually, someone from Spectrum . . . Survey Monkey is actually going through this really interesting evolutionary phase where . . . it was started by two brothers, Chris and Ryan — actually, my two co-founders are brothers and their names are Chris and Ryan, also, so we had this really interesting dynamic when we met with them — they started Survey Monkey back in 1999, and they grew it up to this ridiculous revenue-generating machine, but they only had 14 employees.
It was the two of them and two other developers, and the ten other people were doing customer support, but it was generating millions and millions of dollars. The Finley brothers were, like, "We don't want to go international. We don't want to do this other stuff. We're not interested in growing the company; it was interesting founding it."
So after ten years, they approached a couple of investors, and Spectrum ultimately won. They took over the company, they put a new CEO in, they established an office in Palo Alto, and Portland, which is where the company was founded, remained the support office. They hired all these engineers and developers and they were rewriting the whole code structure.
They had these mass additions doing the payment and all this stuff. Because they were going through this entire process of growing and growing and growing, they knew they were number one in the survey space, but they were interested in other people in the space, and they saw us.
Apparently, Chris and Ryan Finley were huge fans of our interface and our design. Spectrum, the guys that bought the controlling rights in Survey Monkey, they were the ones that got in touch with us and we started talking with them. It took about two years to hammer out all the details.
That's how it started. We didn't approach them. We actually had tons of investors. We only raised $118,000: $18,000 seed funding from Y Combinator and $100,000 angel funding, and we did that in the first six months of starting Wufoo. Then, for about five and a half years, we just ran off of our own revenues. We were going like gangbusters and doing really well.
We always had investors sort of interested, but we weren't interested in them because there wasn't a venture capitalist that I met that I felt like I needed his money so badly or that he was going to give me intellect that I felt would be helpful for the company.
Luckily for us, the new team at Survey Monkey is awesome. Selina Tobaccowala, one of the founders of Evite, is head of engineering. She did Ticketmaster before she came over here. So there you have this awesome dream team that they're assembling. They're super profitable, but they have this start-up mentality because everyone is sort of new and able to work on new things.
Dmitry: We're out of time. Let's thank Kevin for an amazing talk.
Kevin: Thank you, guys.
