Routing help requests

At smaller companies, it is often possible to know enough about your colleagues and their teams to find the right person to help with a problem. Employees may also know enough about the company to resolve issues outside their role.

As a company grows, this is no longer true. The organization, systems, and domains eventually become too large for individuals to know where to get help. At the same time, the number of support requests increases, making it infeasible for people in unrelated roles to absorb the support load.

Left unaddressed, the cost of routing help requests is delays and duplicated work. This impacts both the ability of the business to serve its customers and the productivity of employees.

This is not a new problem, and many companies have established patterns, systems, and processes to manage it. The approach below is the one I've liked the most.

Problem breakdown

These are the core challenges, as I see them:

1. How do folks self-discover where to send a request for help? Anyone in the company should be able to figure out how to raise an issue or ask a question.
2. How do we set resposibility for addressing the issue?

Turning these into some explicit requirements:

1. ALL domains in the company MUST have an individual or group which own solving problems for that domain.
2. ANY empoloyee at the company MUST be able to find options of where to ask for help WITHOUT needing to know specifics about a domain.
3. We SHOULD be able to correct mistakes in assignment quickly. Requesting help is done by a human; humans make mistakes; we should be tolerant to mistakes.
4. We SHOULD be able to easily make changes as the company grows/evolves

A solution: map domains and experiences

Assign owners to domains

• a domain is an area of expertise - its up to you to decide what these are in your space, and I have some opinions around how to set these up, but I'm skipping that in this note. Some examples: "payments" (a domain building expertise around a business concept), "first time customers" (a domain building expertise around a particular persona), "frontend" (a domain building expertise around a tech component)

Each domain should have explicit owners which are responsible for handling issues in that domain. Think about what it is exactly that can own a domain in your business. Ideally this would be teams or roles, but can also be individual people.

Lightweight definition of domains and how they map to owners is enough is simple enough that updates are easy to make as your business needs and teams change. For some companies, this responisbility map provides enough context that folks don't need anything else to figure out how to reach out for help.

For larger organizations it might not be enough. When domains are complex enough that looking at a list of them is not enough to to give folks confidence about who to reach out to, it helps to also model experiences.

Experiences

• an experience is a part of your product/business that users (internal or external) interact with. Some examples: "the onboarding flow" as a customer facing experience, "IT approval requests" as an internal user facing experience, "the backend testing pipeline" as an internal engineer facing experience. The key here is that experiences should be something that users and employees are familiar with from just having used the product.

Take the example of an e-commerce site. Delivering a good experience depends on marketing, product, software development, inventory management, and billing teams.

If a customer reports "a website issue", that isn't enough to route the request to the people that can help. By pre-defining experiences we basically create labels that helps you figure out where it might be best to reach out, without you needing to have knowledge of how your whole organizational is structured.

• Bad label: “Website - issue”. unclear which team this would actually go to; not granular enough.

• Better label: “Website – ‘What’s new?’”. specific experience, owned by one team, which is where the request for help will go.

Notes:

• More granular labels can be created where needed. You should tweak/modify/try labels until people can self-route.
• Fallback labels should exist to capture issues that do not fit well into an existing one.
• Domain mappings remain useful internally when questions do not map to a specific experience.

Tooling

To implement this in practice, tooling must support:

• a place to define/manage owners (teams/roles/individuals)
• a place to define the labels that represent your domains and experiences
• a place to map domains to teams, and map experiences to domains OR teams (both can work; it's somewhat aesthetic)
  • domains can move between teams or be deprecated
  • experiences can move between domains/teams or be deprecated
• a place to request help (a ticket, an issue, etc) for a specific experience or domain
• some process that can look up the team for the label and assign them to the help request
• the ability to change the label of a help request, which allows a request to be routed to the correct team in case of mistakes

Closing

Start simple: list your domains and assign owners. Add experience-based labels so employees don’t need insider knowledge to ask for help. Support it with tooling that makes requests easy to file, route, and reassign. This maintains your ability to handle support requests as the company grows.