How do you scale really complex, time-sensitive support? My interest in this, and the reason that I ultimately started Plain, started from an unexpected place: cold pizza.

Before Plain, I was working for Deliveroo, a publicly-traded online food delivery company active in around a dozen markets. I joined as the first designer when the company was around 10 people. Over the 5 years that followed, I witnessed the company's growth to 2,000 employees, leading a talented team of 40 designers, researchers and content designers.

During that time, I saw our support team scale from a couple people helping out during peak times to an organisation with more than a thousand members.

As our order volume started to grow, so did our customer support volume. Questions flooded in as pizzas turned up cold, rider motorbikes broke down on the way to customers, and restaurants were missing an ingredient to make an order.

To keep up with this growth, we invested product, engineering and design effort into two areas: Building internal tooling to make us faster, and creating structure around how customers contacted us to help us triage and resolve their queries faster.

I want to spend this post exploring some of the things we learned in creating structure, and why that structure is so essential not just in the world of food delivery, but particularly also in B2B SaaS.

Structure is essential in collecting complete information from customers, especially in environments where you’re confronted with high growth in support volume, complexity and urgency. Without structure, you receive messages like “The app is broken, please fix” – when the information you actually need is that it’s a medium priority bug report about the widget functionality in release v2.1.8 of your product, with steps to reproduce and complete information on who the customer is.

Given the dynamics of B2B, support can be particularly complex and sensitive. Each issue is not just felt by a person, but by a whole company. Support is often not just a service offered, but a central part of the product and brand. Getting the right information from customers is doubly important.

So, how do you create structure to handle scaling support volume?

Enter the humble contact form

Contact forms have a reputation as old-fashioned, boring and stale.

But contact forms can actually be incredibly powerful. When designed thoughtfully, they can speed up the entire support experience, ensuring you receive the necessary information right from the start. This efficiency is crucial in environments where support complexity and sensitivity is high, like technical support.

So, how do you design a contact form that doesn't just collect information but enhances the entire support experience?

Most companies just stick a static form on their site and move on. It typically looks a bit like this:

That’s fine for basic use cases, but quickly starts to break at higher support volumes.

There is a better way, and it starts with making your form a part of your product, not just a page to direct people to. It means approaching your form as a design and engineering problem, rather than relying on one-size-fits-all templates.

Below, I share some tried and tested principles that will help you turn a static, poorly structured form into a fast, highly structured and modern channel for your customers to contact you on.

Principle 1: Embedded into your app

Your form should not be a single page, but distributed throughout your application.

Traditional "Contact Us" pages require users to stop what they were doing, leave your product, and contact your support team from outside the context they were in. This causes friction and gives the impression that you are "shipping your org chart".

Rather than pointing people to a page, instead use these surface areas:

1. A floating widget, made popular by Intercom. It’s a great format and users typically know where to find it. It works best for quick, transactional support – you’re unlikely to have a great experience pasting a full bug report with code snippets into a 300x200x textarea.

2. Embedded into your app’s navigation. This is a great option for making it front and center in your product, and easy to find. It also allows you more real estate, which is useful especially for settings where queries are longer, and longer-running.

3. Points of friction. There might be moments in your app where you want to make it very easy for people to contact you, say when someone runs into a billing problem, receives a system error, or is trying to upgrade their account.

Principle 2: Focuses on the task

Your form should not be a single, static form – but instead gradually guide users through the job they're trying to do.

When people contact support, they typically have a task they need to accomplish, or a job to do. This job is rarely “contact support”. Contacting support is a means to an end, and that’s typically something like filing a bug, resolving a billing issue, or upgrading their plan.

To make it easier and faster for users to get that job done, frame the support form in the same language to guide users down the path of completing that job step by step.

You can do this by splitting a single, long contact form into smaller ones centered around the relevant use case.

Doing this accomplishes two things: it front loads a choice that users will have to make anyways (with less cognitive overhead) and simplifies the form’s presentation.

Principle 3: Recognises the user

Your form should use all the information you already have, and represent that information back to the user.

Most forms will present you with a name and email field. For obvious reasons: To help a customer, you first need to know who they are.

Asking for this information is fine if the form needs to be accessible to the public. But in the context of a modern SaaS app, customers are almost always authenticated. You already know who they are, which team/project/workspace they belong to, and potentially even which pricing plan they are on. Asking them for any of this information causes friction at best, and confusion at worst if any of the information is incorrect.

Leverage the information that you already have and build it into the form. This can be as simple as their name and email address, but can go as far as showing the customer their pricing plan and the support they can expect.

Principle 4: Uses your product taxonomy

Your form should use and leverage the taxonomy of your product.

There’s nothing more frustrating than an incomplete bug report. Yet oftentimes, what makes a bug report incomplete is not basic information like the steps needed to reproduce, but information specific to your product: Which component/area is affected? How exactly is it broken? In which version of the product?

Getting users to consistently provide this information is hard, because it requires them to understand the taxonomy of your product. The easiest way around this is to structure your form using that same structure.

The information previously collected through a single “Message” textarea is now gathered through a series of steps, such as “What product area is this affecting?” followed by a list of choices relevant to your product.

Principle 5: Deflects intelligently

Your form should deflect queries in a tailored, contextual and nuanced way.

The best support query is one that a user is able to resolve for themselves. Unfortunately, most products do this by throwing an avalanche of chatbots at every incoming request. Most of the time, they’re neither smart nor particularly effective.

The best way to deflect a query is with nudges that help users understand what might be going on.

For example, say someone’s reporting an incident. If there’s an incident ongoing, the last thing you need is another report telling you there’s an incident. You can gently deflect here by flagging that the product area your user has selected is currently affected by an incident.

Similarly, if someone’s getting in touch about an issue with the app, you might check if they’re using the latest version and get them to update.

Principle 6: Matches the user's mental model

Your form should frame non-product related information using the mental model of the user, not the company.

Say you’re asking customers to tell you about the priority level of a bug report. Your customers might have a different interpretation of “Urgent”, “High” or “Medium” to your team. In fact, given that your support team is likely to be looking at a queue of a few hundred “Urgent” tickets, they almost certainly do. It’s better to frame information through the lens of your customer and the impact something is having on them.

For example, “Priority level” can become a simple checkbox saying “This bug is preventing me from using this product”.

The former is open to interpretation, the latter is clear and factual.

Principle 7: Sets clear expectations

Your form should set clear expectations about what happens after users submit it.

You’re probably familiar with the feeling – you hit “Submit” and get a generic “Thank you!” message. You might hear back in an hour, a day or a week – you don’t know.

That’s why every form should tell users when they can expect to hear back. This information should be as specific to the user as possible – if they’re on a Pro plan and have paid for a 1h response time SLA, that’s where you tell them.

From incomplete to actionable

Taken together, these principles help you go from a static form that gives you unclear information, to a form that responds to each of the user's inputs and enables them to build a fully formed and actionable support query on your behalf.

The information that you’ve gathered in the latter will make it much easier to quickly understand the urgency of the customer’s question and triage accordingly.

It will also make the customer feel like they’ve provided enough information to expect a high quality response, giving them a better impression of the support experience and product overall.

Now, it’s your turn

Now that you’ve seen all these principles, how do you get started?

A good place to start is to break down the jobs your own form is currently trying to do. We've used the examples of general questions, bug reports, and feature requests in this post, but you might have domain- and product-specific use cases in addition to these. From there, you can pick a first job to build a form around, and gradually replace your old form.

Here are some companies and products who I think do a great job at using the very best contact forms have to offer, to provide you with some more inspiration and practical examples.

Arc Browser

Linear

Vercel