Have Every New Employee Do Customer Support For Two Weeks

A few weeks ago an entrepreneur of a fast growing consumer-oriented company told me that he has every new employee do customer support for two weeks. Their approach is they onboard the new person, given the a one week “get settled into your role / get up to speed on the company” period and then they spend weeks two and three full time in the customer support organization.

I’ve let this roll around in the back of my head and think it’s absolutely brilliant. The first week is a typical “first week at a new company” which includes a formal day of orientation on the first day. The next four days are structured around on-boarding the person and getting them involved in their role and their team, but not too deeply. This allows there to be a “break in period” where the person is learning the systems and structure of the company.

Week two is a full time immersion in the customer care organization. Total front-line stuff. The same first week any new customer care rep would get. Day one is whatever the normal orientation is followed by four days of “training wheels customer care.”

Week three is a fly on the wall from a managers view of customer care. Rather than front-line support, this is involved in all the meetings – up and down the customer support organization – to understand what people are dealing with. The last day includes a debrief meeting with the CEO.

I think a version of this process could be created for virtually any size company in any market segment. You are trying to have the person do three things: (1) be on the front-lines of the company and understand what that looks like, (2) engage directly with the product and customers, and (3) understand how the organization works from the customer point of view.

There’s a powerful second order effect, especially if every employee does this regardless or rank or title. In the first month of their tenure, they see the organization from the inside out. This creates a powerful common view that can generate an entirely different set of early actions for anyone in a new role. It also creates a powerful culture dynamic. And it does a little of what we try to do in the first month of TechStars – which is to “slow down to speed up.”

I’m curious if anyone out there is doing something similar or has suggestions to add or modify this.

This is a great thing to do. I would even add to it. Senior ENGINEERING folks in particular should do this periodically, maybe at least once a year and particularly after product rollouts. Those with the vision and responsibility for design of products all too often are the ones most disconnected from the actual user experience.

NowEntrepreneur

Sharing my experience while I was with a telecom company. Being a part of the Enterprise business team, we used to always include someone from the Network and IT team along with us during the pitch. This enabled them to understand the customer’s pain point and were sensitized about the service level expectations. Reduced a lot of internal friction.

http://startupcfo.ca/ Mark MacLeod

Freshbooks does this for a month and it is SO ingrained in their culture. Every company should do it.

http://www.andyswan.com andyswan

Since his company bought my company, I had a front-row seat to how Tom Sosnoff (thinkorswim) operated.

One of the things that struck me was from day one until “Sold to AMTD for $606m” and beyond… he replied to every client email that he got, as well as a small % of general client support emails that were randomly tossed his way. Every day. Hundreds. Too small to fail is a mindset.

Further to the comment by @startupcfo:disqus I just completed my month of training on support at FreshBooks. What I learned about our customers and our business during that month would have taken a lot longer without this front-line training. By far the best onboarding I’ve experienced, and a great example of our focus on customer support. Great article.

Jeff Osborn

Even more important is for upper management to do it. Back at UUNET when I was running Sales and Support, I made sure to spend at least an hour a week on the phones in the front lines of tech support. Besides gaining a lot of cred, you get the unfiltered feedback that management can otherwise avoid all too easliy.

Bill Adkins

At one of my previous companies this was baked into the culture for virtually _everyone_ in the company to touch customers. For engineering it was part of the job (and they were scaled appropriately to handle the workload) that they all did support along with development (there was no separate dedicated support dept). Many engineers scoff at this but IMO the company results proved it out. With a staff of ~10 engineers and ~8 sales folks, the relationship to the customers (7,500+ including nearly all the F500) was super tight, the intimacy between sales/engineering was nearly perfectly aligned and the product iteration (agile before Agile was Agile) was quick. If you remove the distance between the person experiencing the pain (bug, feature) and the person capable of remedying the pain, you not only create a happier customer but the implicit longterm learnings are dramatic. Plus it’s a reminder to the developer that if they create the issue, they will have to hear the feedback directly so get it right the first time (more reliable releases become the norm).

Now that the engineers know the CONTEXT of the pains/needs, (which can’t be under-estimated) product dev takes on a different trajectory based on known need/pain. In conversations about priorities, no longer is it a customer-facing person “on an island”. There are now multiple people speaking from experience whether this client worth $x value is contributing/costing $y/ and what to do about it. Meanwhile you have these clients raving about how they “go right to the engineer”, telling everyone how awesome you are and your product is, generating another 10 inbound leads for you. Trust me, it worked for 6+ years.
The comment argument is “wow, that’s an expensive way to solve problems” but engineering’s ability to help drive business paid for itself in every conceivable way: customers were impressed to be talking to the folks “coding the solution”, time lag went down, risk of miscommunication was minimized, feedback to sales was direct – we now knew who was leading the way in our prod dev and therefore needed to be cared-for when negotiating a new deal or a renewal, reference customers were easy, and the company had a holistic understanding of the customer from the most valued/knowledgeable people in the business.
I acknowledge that this is not possible in every business or at every size of business but the effects were mind-blowing.
The one caveat to this whole concept is it has to be INGRAINED INTO THE CULTURE. Whether it’s a formal part of the job, a 2-week requirement or some other derivation, if it’s not drilled in why it matters and enforced at a cultural level, then it is not more than window-dressing and failure of the model will be a self-fulfilling prophecy.

http://www.DomainRegistry.com/ LE

An excellent idea.

Noting as well that at Cornell’s hotel management school, the waiters in the school’s hotel restaurant, the people who valet your car, as well as the front desk staff, are clearly labeled as being students training as part of earning their degree. (Personally I think the labels are a mistake since then they don’t get viewed as real world employees but as “students” and probably get treated better which detracts from the process of understanding real world interactions.)

There is so much you can learn from being in different operating positions at a company. If you were going to be in management at a ski resort you’d want to work in the rental department, the ski lifts, ticket sales, phone help, whatever you could (for as long as practical) in order to learn the ins and outs of various parts of the business as well as the challenges.

Having worked in every position at any company I started and finding it extremely helpful I can’t stress this approach enough.

http://drewfrey.com/ Drew Frey

I’ve been doing this personally for the last 2 weeks and it has helped me immensely. I think answering emails is something that I will continue to do and work on until I feel 110% comfortable fielding any and all questions, no matter what they are.

Thanks Brad.

http://www.facebook.com/nick.a.ambrose Nick Ambrose

Yes, I am totally 100% for this. I’ve tried to implement it at previous companies but was never in a position where I had the influence to make it happen. As a development manager, I always made sure to spend as much time with the support teams as possible as they are the ones that really know what’s going on with the product.

http://twitter.com/techguy John Lynn

Zappos has been famous for doing this for a long time. Plus, they pay you cash if after the training period you choose not to work at the company.

http://engag.io/ William Mougayar

Excellent idea. I would add to it- repeat that at regular intervals, e.g. every 6-9 months, about 2-3 days then.

http://www.engag.io/Abdallah Abdallah Al-Hakim

very interesting post and the response from the comments is one of overwhelming support. I must say that the ‘break in period’ of the first week is not something that I am experiencing in my new official role at Engagio To be fair I have been working with them for few months prior to that.

We aren’t doing anything but I’d love to suggest it … not sure it would be taken very far though. “slow down to speed up” = money quote!

http://www.facebook.com/david.dupont.144734 David DuPont

From the beginning of our company, everyone spends at a day per month on Support, including me. We have reaped tremendous advantages in customer loyalty, feature prioritization and teamwork. I am a huge believer in the practice.

http://www.charliecrystle.com Charlie Crystle

I tried that, and the hires absolutely hated it (I guess they didn’t identify themselves as customer service). But they learned the product and about the customers

http://jasoncrawford.org/ Jason Crawford

Amazon has a “Customer Connection” program like this for execs. They spend time doing customer service and also time working in the fulfillment centers.

http://twitter.com/WilliamCrawford Will Crawford

I’ve always tried to do something like this with new hires, With engineers, I also try to make sure that everyone has at least some experience on the operational side – installing the software, managing updates to our SaaS infrastructure, or working with customers on integrations, even if that engineer’s primary role was more product facing. You get much better results when everyone involved feels the pain – in particular, the engineers got a lot better at removing repeated manual processes that went along with customer installs.