At Plain, great customer support has, and will continue to be, the cornerstone of our approach to building the best support platform out there. We started the company with the firm belief that our own support had to be amazing.

As we’ve grown, we’ve gone through a few iterations of what support looks like at Plain. In this post, we’re going to share our journey of building support at Plain, and some of the things we’ve learned along the way. 

Stage 1: Just do it 

When we first launched Plain and onboarded our early customers, our support strategy was simple: everyone in the company took ownership of support. This unstructured, whole-company support model allowed us to stay incredibly close to our customers – giving the entire team direct insight into their needs, pain points, and areas for improvement.

As we grew beyond having a small number of customers, unstructured support turned into a mess. It wasn’t clear who was looking after what, and took more of the team away from core product work. 

We still believe in the power of whole-company support. There’s literally no better way for us to learn about our customers and improve our product than by using our product as our customers do – but at this stage, more structure was needed to improve the efficiency of how we did support. 

Stage 2: Nominated support rota in addition to day job

Our first step towards improving how we approach whole-company support was to introduce a support rota. Every Monday at our planning meetings, two team members would volunteer to take on support duties for the week. This ensured that we always had a team in place to handle customer issues, report bugs, and add feature requests to our roadmap. 

We made a point to always include at least one technical team member on the rota each week to speed up our time to resolution. We also decided that new team members would spend their second week at Plain on the support rota. This has proven to be the best way to get new hires up to speed with our customers, and familiarize them with how our own customers use Plain. 

As we continued to grow, we realized that even this structured approach wasn’t enough. The demands on our team were increasing, we were taking on more enterprise customers, adding more channels and features, and we had tighter SLAs in place. We held our first ever support retro when it became clear that we needed to make improvements to how we do support at Plain. 

Our first support retro 

Every month, we hold a team retro to review what’s working and what needs improvement. These retros typically cover everything from how we worked together as a team to ship a new feature, to onboarding new teammates and refining how we work. We knew we needed to change our approach to support when we spent a significant amount of time discussing the impact that our support rota has on how we work in our monthly retro. It became apparent that we needed to dedicate an entire retro to support alone to identify specific areas for improvement.

Great support is integral to us at Plain – it’s something that we never intend to let slip. So, we held our first ever support retro, identified the issues with our current set up, and ways we can improve it as a team. 

What wasn’t working? 

Support was turning into a full-time job 

One of the most significant pieces of feedback from our support retro was that being on the support retro felt more and more like a full-time job. However, we weren’t making any concessions in the expectations for other work from those on the support rota. It increasingly became the case that as an engineer on support you could basically consider any project you were working on as 'paused' for that week. 

Small paper cuts took longer than they should to fix 

Ideally, the team on support rota should be able to fix small issues for customers immediately. This was really easy when we had a smaller support volume and was a great source of delight for our customers to have feature suggestions shipped on the same day. As our volume has grown, this just wasn’t possible alongside answering all support requests. Other engineers not on rota should also be protected from support requests so just passing that buck on didn’t feel right either. 

Lack of ownership 

As a team of people who work on building our support platform, we actually get… support FOMO, and regularly had people jumping in to help despite not being on support. Although lovely, with multiple people touching the same thread, it wasn’t always clear who was responsible for carrying the request through to resolution. A classic example of this is when someone would ask a follow-up question or suggest something in a customer Slack channel but then was on calls or heads down coding for the rest of the day.

We had more enterprise customers and tighter SLAs 

As we onboarded more enterprise customers, the number of SLAs we introduced naturally increased. This meant we’ve got to get tighter on response times for these groups – often resulting in a backlog each morning that took a significant amount of time to triage. 

When new starters join, it was hard for them to be independent on support 

Finally, we noticed that new team members were struggling to be independent on support. Most of the knowledge they needed was locked in the heads of other teammates, making it difficult for them to contribute effectively right away.

Every problem we experienced over this period of growth is a great problem to have – we’re growing our customer base and our team. Sound familiar? If your team has felt stretched thin like ours, you know how vital it is to reassess. Here’s what we did next to make sure support scales with us. 

Stage 3 – current: One person fully on rota, one person on backup

The great thing about the team at Plain is that we’re pretty much always on the same page about how and where we need to improve. The support retro allowed us to find a few key ways to improve how we do support – and make sure it can scale with us as we continue with our unprecedented levels of growth. We decided on: 

Making support a full-time job (for a week)

We’ve introduced a new system where one support lead and one support assistant are responsible for all support duties each week. The support lead owns the queue and drives things through to completion. Inbox zero is their goal. This way, it’s clear who owns each customer request, and the rest of the team can focus on their projects without interruptions. We’re also setting clear expectations internally in planning that other projects may slow down as a result of the team members being on support duty.

Creating snippets and playbooks

Support leads will now take full ownership of creating snippets and playbooks for common support requests. We already have a host of playbooks for operation issues and now we’re adding to those for common support requests and flows. In the long run, this will allow us to speed up our time to resolution, and get more consistent in the responses we send to customers. 

Tackling paper cuts faster 

This new and improved support rota will let us tackle small paper cuts more regularly, with faster time to resolution for our customers. By having a support lead in charge of triaging incoming requests, responding to customers, and adding issues to our Linear projects – the back-up support person can be more focused on smaller improvements and quick wins we can do for our customers in minutes or hours. These small incremental updates make a huge difference in building trust with our customers, and we want to make sure we don’t risk leaving them too long to be impactful. 

Utilize our collaboration with more diligence

We’ve got features that are purely aimed at boosting collaboration and improving visibility, but we need to get into the flow of more diligently using each one for them to be most effective. If we need to talk about a customer request with the team – we’ll only use Discussions in a public Slack channel. This should allow the entire team to feel like everyone’s contributing to support while the leads handle the actual customer conversations. We also decided to be more diligent with notes so that if a support request has to be picked up by someone else all the context is there. This will help maintain continuity even if someone needs to step away.

Review our SLAs and Tier usage

As our customer base grows, we’re reviewing our SLAs and Tier usage to better align with our customers’ pricing tiers. This will help us set clearer expectations for response times and ensure that we’re always meeting our customers’ needs, no matter what plan they’re on. Of course, if any issues come up that block our customers from working in Plain, we’ll handle it immediately. No matter what time or day it is. 

Ignore the FOMO 

We’re all going to work harder to ignore the support FOMO. We need to get comfortable with the fact that less cooks in the support kitchen will actually allow us to support our customers better, and make progress on product updates faster. It also gives the support lead a more realistic sense of what it’s like to do full-time support in Plain. We can all follow along with support threads and be involved in thread discussions – but the responding and resolution must be left to the support lead for the week if we’re to improve how we do support. 

The support rota is an integral part of how we function as a team at Plain. Given how vital support is to our way of working and product, we still see it as a whole team problem. But one that we're always looking to be better with and faster with. It’s the best way for us to understand the core issues of our customers, and build the best support platform we possibly can.

Stage 4 – our future state: full-time hire, but still a team sport 

Will we be able to manage support at Plain with a support rota forever? Probably not – and we’ve got to start planning for that eventuality. We’ll absolutely hire a support person when the time comes, but we need to do it mindfully. 

We’ll bring in a support person, but continue making visibility into support issues a priority across product, sales, and marketing. We’re building a system where support will always be integrated into our processes, driving improvements and keeping us close to our customers.

The rest is to be continued: we’ll come back to this post in the future when we’re ready for stage 4 (and 5, and 6).

To sum it up: 

Our approach to support at Plain has always been – and will continue to be – one of constant iteration. What worked for us as a small team doesn’t scale forever, and that’s okay. We’re committed to revisiting our processes, retro-ing regularly, and making thoughtful changes that reflect our growth.

If you’re also trying to scale support while staying connected to your customers, our biggest lesson is this: don’t be afraid to pivot, iterate, and refine as you grow. Your support team – and your customers – will thank you.