Support & DevRev

The PLuG platform in DevRev was created by support people for support people.

I’m going to outline three different support team structures I’ve worked with, pros and cons of each, and how I’d recommend setting up DevRev based on each team structure.

Let’s start with the definitions.

1. Product Centric
2. Tiered
3. Chaos

Product Centric refers to teams where you have on or a few dedicated subject matter experts for each part of your product (or each of your products). This can be combined with a tiered approach but should still roughly center around products or parts of products.

Pros: Allows for in depth subject matter expertise, build relationships with specific PMs/Devs

Cons: Information may be siloed in case of absence of high impact if there are only one or two people per part

By Tier: There are typically 2 or 3 tiers. Tier 1 is the first point of contact and typically does routing and may handle simple account issues. Tier 2 is typically more technical and can perform troubleshooting tasks. Tier 3 is usually the Support Engineers who can and do write code and do advanced troubleshooting.

Pros: Gives some sense of career progression, faster first response time.

Cons: Negative impact to CSAT due to switching agents multiple times, unnecessary cost as many Tier 1 tasks can be automated

Chaos: Chaos is a bit of a dramatic word to use here, but it’s at least descriptive. This is usually a very small team. Any agent answers any incoming conversation. In the case of email support, they may not own a conversation end to end, and that conversation is just answered by whoever sees the next response first.

Pros: Minimal information siloing

Cons: Lots of context switching, lowered CSAT due to agent switching

Which Structure is the Best?

All three have a place depending on the size of your organization, type of customer, and product.

If you are an early-stage startup with only one or two support agents, a formal tiered approach does not make sense. A product-centric approach also does not make sense, as there are not enough people to have knowledge redundancies if someone is out for the day. A chaos approach here works best. My recommendation is for agents to see all of their conversations through from first pickup to close to reduce the number of handoffs. Research has shown that the more times a conversation changes agents, the lower the CSAT score will be. You can take an informal tiered approach here in addition to the chaos method. If a support agent has done all they reasonably can to resolve an issue, now it may be time to share the conversation with a developer or product manager.

If you are an early-stage startup with no support agents, however, a product-centric approach makes the most sense. While I admire a CEO willing to roll up their sleeves and answer incoming customer support queries so their engineers can focus, there is an important context in those conversations that your engineers and product managers will benefit from. Those who work on a specific product/part should answer conversations related to their work. This reduces context switching and time to resolution. This approach is challenged, however, if you have parts or products that haven’t been launched yet. Here you need to make a decision whether the ability to reduce context switching for groups whose work hasn’t launched yet is more important than the ability to respond to customers quickly. I’d recommend using as much automation as possible and sharing some of the workloads across the teams. Context switching can be valuable if it gives broader insight into the overall product.

If you are at a stage where you have enough support agents to dedicate one or two to each part/product, I’d recommend taking the product-centric approach. If you only have enough agents for one per product/part, pair up so each agent actually becomes a subject matter expert on one and highly proficient in another, thus creating knowledge redundancy in case the subject matter expert is out.

Last, as teams grow and scale, there is a natural urge to fall into a tiered system. I’d urge you to resist this as long as possible. Instead of having a Tier 1 to answer “easy” or “known issue” type questions, consider why those questions are being asked in the first place. Is there a way the product or system can be improved so no one ever asks those questions again? Create automation and knowledge articles around them in the interim. You may still want a Tier 2 and 3, and this can be done while remaining product-centric. Tier 2 should be subject matter experts in their respective products/parts and perform advanced troubleshooting. Tier 3 should act as mini product managers, often interfacing with engineering, product, and marketing to communicate technical questions/needs, product requests/needs, and clarification on marketing materials. Before you reach a tiered system, these functions should still be owned by the subject matter experts from the product-centric approach.

How do I do this in DevRev?

First, take a moment to assess the current organization in your support team. Are you currently taking the best approach for you, or should you try out a new method? Once you’ve decided, it’s time to onboard and implement DevRev.

If you’ve already set up your account and integrations that’s great! If not, visit our documentation. You can get started without all of these steps but will get the greatest value if you are fully onboarded.

Set up your Ticket Vistas

Chaos:

Untriaged, Triaged, Closed sorted by Date

These allow each member of the team to see Tickets that have yet to be triaged, the ones in progress, and just as importantly the ones recently closed so you can let your end users know in a change has been deployed in their Conversations.

Product Centric:

By Part(s), Group by Status

Breaking your Tickets down by product provides each owner/group a quick reference to what is most relevant to them. Grouping them by Status allows each owner/group to quickly see which have been recently closed to update those Conversations and which are awaiting triaging, in progress, etc.

Tiered:

Untriaged, Triaged, Closed sorted by Date

Similar to the Chaos method, this allows each member of the team to quickly find what’s most relevant to them.

Tiered + Product Centric:

By Part(s), Group by Status

Similar to the product centric method, it provides the information of the Tiered approach and the Product centric approach while keeping the Products/Parts separate

Coming Soon:

Custom Inboxes - Sort your conversations

Flows - Write all the automations you desire

Routing - Assign incoming conversations to your team based on their strengths

SLA - Keep your team informed of SLAs

CSAT - Gather feedback about your interactions with customers

Want a feature not listed? Use the PLuG widget on our site to send us a message or email us at support@devrev.ai