Lessons learned from building an accessible support team

From the earliest stages of product design until the moment we release a product to the public—accessibility is front of mind. But that commitment doesn’t end there. Every day our support teams offer help and advice for people who use our products, and we want to make sure that support is accessible to everyone, including people with disabilities.  

In 2017, we launched our Disability Support team. The team is available to answer questions about using assistive technology with Google products and the accessibility features and functionalities available within Google products. In our first year we received more than 13,000 inquiries and with each question we learned how to better build a support team that centers around accessibility. 

Today we are launching a playbook of everything that we’ve learned to help other companies and organizations who might be interested in creating their own Disability Support Teams. Here are a few of the key lessons that we learned.

Names matter: “Disability” vs. “Accessibility” 

When naming our team, we had to consider using “disability” or “accessibility” to describe the focus of our work.  Ultimately, we learned that including “disability” made our focus clear. “Disability” is a more widely searched term across the globe, and widely accepted and understood. Making that focus clear helped reduce the number of questions we received that were outside the scope of our team. Before launching the Disability Support team, more than 70 percent of the questions we received were not related to assistive technology or accessibility features. 

Build with and for people with disabilities

When it comes to setting up and staffing a support team, make sure you work with people, organizations and tools that are focused on disabilities. First, we learned that hiring people who personally use assistive technology helps them share better insights because of their own experiences using assistive technology. Community members notice when support agents don’t use assistive technology themselves, even if they can provide the correct answer.

When working with vendors, do your due diligence to identify and partner with experienced vendors. Conduct on-site visits, speak with support agents (without management present), and shadow existing processes. Look for vendors who already have strong inclusive programs in place, such as The Chicago Lighthouse and TELUS International, and partner with organizations like the American Foundation for the Blind (AFB) to train support agents. 

Similarly, make sure you use support tools that are accessible. Conduct thorough accessibility testing on your own support channels and tools. Go above standard testing to determine both usability and usefulness and work with your engineering team to prioritize fixes where needed prior to launching your support team. 

Meet people where they are

When we initially launched the team we received less inquiries than expected. We wanted to reach more people in the disability community, so we partnered with established and experienced organizations that could connect us with the communities we were trying to help.  We worked with organizations like Be My Eyes and Connect Direct to spread more awareness about our services within the Blind and Low-vision community and the Deaf and Hard of Hearing community, respectively. 

Consider cultural differences

In addition to the typical forecast planning (i.e., cost per case, headcount, time zone, languages, etc.), consider cultural differences and the ability to recruit experienced support agents. Consider places that meet all of your requirements in addition to proven positive cultural perception for people with disabilities (i.e., accessibility laws, typical jargon usage, etc.) For example, in the U.S. it is common to use “person-first language” like “person with a disability instead of “disabled person” or “handicapped,” which can be considered offensive. In addition to the U.S. office, the Google Disability Support team is located in Ireland.

The full report is available in view-only PDF and Google Doc.