Learn how to onboard customers

Join Al Hahn, Executive Director of the Association for Support Professionals, as he interviews me on techniques for successfully onboarding customers. The discussion will be applicable for SaaS vendors (who invented onboarding in the first place) as well as on-premise vendors, who also have an interest in ensuring that customers have a successful experience right from the start.

You can register here.

And please leave a comment if there is a particular aspect of onboarding you would like me to cover during the interview. I look forward to the session.

The FT Word – September 2015

The FT Word

The FT Word is a free monthly newsletter with support management tips. To subscribe, click here. The subscription list is absolutely confidential; we never sell, rent, or give information about our subscribers.


to the September 2015 edition of the FT Word (just a few days late, but if you regularly read the blog you did not miss anything!). Topics for this month:

FT Works in the News

Upcoming Webinar on Onboarding. Mark your calendars for Tuesday, October 20th at 11am PST. I will be interviewed by Al Hahn, President of the Association of Support Professionals, about techniques for onboarding customers. Please email me if you’d like a reminder on how to register for the program.

The Art of Support, Second Edition  went out to reviewers early this month. After months of wrestling with the text I am so happy to have reached this milestone! I expect a ton of suggestions from the review team, and I have yet to create a slew of graphics and checklists, but that is real progress. Two questions for you:

  • What checklists would you particularly want to see in the new edition? I have plans for many, including a case quality audit checklist, an outsourcing checklist, and a metrics checklist, but please vote for your favorites. Thank you!
  • If you are currently working for a SaaS vendor or a hardware vendor and want an early peak at the book, consider joining the review team. We’d love to have you. [9/28: the review team is now complete. thank you]


Curious about something? Send me your suggestions for topics — or add one in the comments — and your name will appear in future newsletters.

Françoise Tourniaire
FT Works
650 559 9826

About FT Works

FT Works helps technology companies create and improve their support operations. Areas of expertise include designing support offerings, creating hiring plans to recruit the right people quickly, training support staff to deliver effective support, defining and implementing support processes, selecting support tools, designing effective metrics, and support center audits. See more details at www.ftworks.com.

Subscription Information

To request a subscription, click here. The mailing list is confidential and is never shared with anyone, for any reason. To unsubscribe, click here.

Back to Newsletter Archive

Building a Support Operations Function

Many thanks to Kevin Williams for suggesting this topic.

In small support teams, everyone is focused towards support delivery, with some time carved to address planning, training, tool administration, and other essential functions. As the team grows, multi-tasking becomes more challenging and it makes sense to create a team dedicated to non-delivery functions. This typically occurs as the organization exceeds 20-30 people.

If we define the delivery function to include everyone who is either delivering support directly (customer service reps, support engineers, customer success managers) or managing people who are, non-delivery functions include the following roles:

  • Knowledge and self-service management, looking after the website and the knowledge base, knowledge management, metrics, and tools. Self-service management does not usually include the administration of the tool itself, but instead focuses on processes.
  • Tools development and administration for the various tools used by the support team. This includes long-term planning for future tool additions and upgrades. For on-premise tools, system administration for the hardware is usually handled by the IT organization rather than support.
  • Metrics and data analysis, which includes defining metrics, analyzing trends, and recommending appropriate actions based on metrics.
  • Planning for new products and releases, coordinating with the product marketing organization.
  • Training, for new hires, ongoing technical training, and process and soft skills training.
  • Support marketing, designing, pricing, and selling support offerings
  • Process management to define and refine  support processes

Note that these are roles, not positions. For smaller teams, one individual may fulfill multiples roles: training/process management combinations are common, at least when it comes to process and tool training, as are tool administration/metrics. And the roles may be held by support managers (think about process management, for instance) or support engineers (for tool administration), not just when the organization is small but sometimes long after a support ops team is in place.

Can you get these roles staffed from non-support departments? Of course and indeed some roles such as support marketing are often staffed by other departments. Note that, even if you outsource your non-delivery needs, you still need to manage the work. In fact, when I speak with IT teams that administer support tools, their top frustration is that they do not have a single point of contact in the support organization that can organize and funnel requests. Think of it the next time you bemoan the poor service you are getting from IT! Still, some roles cannot be outsourced at all (knowledge management and process management, for instance) and many are likely to receive much more attention and resources if funded within support (such as tool administration and metrics).

It’s usually fairly easy to tell when to create a support operations team: when delivery and non-delivery duties collide. The first roles to be formalized tend to be the first ones on the list,  knowledge/self-service management, tools administration, and metrics, because they require both ongoing attention and specific technical skills, which means they are likely to conflict with delivery duties and cannot easily be handed by the support managers, who tend to have more flexible schedules.

In contrast, managers can often juggle planning and process management along with their other duties, and support engineers, at least some of them, enjoy some job diversity when they can train, so specialization is usually less urgent for those roles. Still, each organization is different and should make its own choices based on the skills of the existing members and the requirements for non-delivery roles.

I am a great fan of the “slightly too small” support operations team. What I have observed is that fully-resourced operations team tend to generate more bureaucracy than results, and also cut themselves off customers’ needs. So by all means hire a knowledge manager, but make her collaborate with the support engineers to create and maintain knowledge. Hire a trainer to create curriculum, but ask support managers to deliver process training. Hire a planner, but assign support engineers to vet the new products. The support operations team members should function as project managers rather than do all the work themselves. With that, the ratio of support operations staff to the overall organization should not exceed 5%, going down to 2-3% as the organization grows.


What are you doing for support ops? Anything you’d like to add? (This will be a hot topic for The Art of Support, Second Edition, so let me know what you think!)

The Truth About Trust – a book review with practical lessons for customer success

I recently read The Truth About Trust: How It Determines Success in Life, Love, Learning, and More by David DeSteno and found many relevant observations for us in the customer success and support field, where developing trust with customers is so important. Here are 6 practical lessons, carefully culled from the book for their relevance to our jobs.

  • Find common ground. People are more likely to trust people who are similar to them.
  • Be in the right emotional state. When we enter a situation angry or nervous, we are less likely to trust others (and, on the other hand, when we feel extremely calm we may trust someone we should trust). This explains why it’s so difficult to turn around customers once they have reached a state of anger. And why taking a moment to allow emotions from a prior conversation to dissipate before starting the next one is good discipline.
  • Expertise counts. Trust stems from integrity and competence. Integrity is great but when the choice is between integrity and expertise, most of us choose expertise. This is why abrasive, but super-knowledgeable engineers can have a fan club despite their unpleasantness.
  • Trust your hunches: Our unconscious mind is made to measure trust, and is less amenable to our own influence than our rational mind.
  • Power can break trustworthiness. Powerful people are more likely to disregard the trust that less powerful individuals may place in them if doing so furthers their own ends. The memorable example from the book is that BMW drivers are less likely to stop for pedestrians than drivers of more modest cars. For our purposes, it’s very useful to establish what I call a trusted peer relationship with customers to avoid the trust-busting effects of unequal power relationships.
  • Look them in the eyes. People conversing face to face are much better at predicting behaviors than those who use a written medium. Face-to-face may not be practical with customers, but a phone conversation is a lot better than email or IM. And if you do have the luxury of face-to-face conversation, remember that individual gestures mean little: analyze nonverbal cues in sets, not individually.