A massive distraction (or: why we are building Plain)

Customer service is undergoing a fundamental change, driven by two shifts.

Customer service is moving from the being on the periphery of companies to being central to them. Entire companies are being built around great customer service in industries that have traditionally lacked it - from banking and broadband to ecommerce and last-mile logistics.

At the same time, nearly every company in nearly every vertical is becoming more engineering-centric. Things that were not considered traditional engineering problems a few years ago now fill the roadmaps of entire teams over multiple quarters. Foundational concerns such as infrastructure or payments have become an order of magnitude easier to manage, so engineering teams can now focus on things specific to their businesses.

These are two circles of a venn diagram converging. The intersection is creating a new market that is both underserved and getting bigger: modern customer service infrastructure for engineering-centric companies.

We believe this because we've seen it up close, in one of Europe's fastest-growing and category-defining companies.

Matt and I had gotten to know each other at Deliveroo. The company had been going through incredible growth, growing to around 2,000 employees in a dozen countries during our time there. That growth came at a cost. Our operational tooling was brittle, with the majority of our attention going towards our customer, restaurant and rider facing apps.

Nearly every process - from checking up on an order to issuing a refund - involved a myriad of spreadsheets and hacks. For every task, advisors were switching between several tools, pasting order IDs between tabs and manually calculating refunds. Processes that could have taken two clicks required twelve, what could have been done in one browser window required six.

For an operationally intensive company, our operational tooling was in a dire state. It hadn't been an issue in the very early days, but had become a huge source of inefficiency and cost with hundreds of orders in flight at any moment and countless customer service advisors dotted around the world.

We decided to spin up a product team to look at our internal customer service tooling, who quickly came to the conclusion that we needed to build tooling that was specific to us, our use cases and our business.

But all of the options to do this in front of us were just as dire as our situation:

1. We could further embrace the ecosystem of our 3rd party customer service platform by building apps and integrations. But this brought a whole host of challenges: We'd have to condense complex workflows into a tiny sidebar rather than being able to make them the central thing. We'd have to simplify and sync customer data every time it changed, creating a separate source of truth that we didn't want. We'd end up maintaining more integrations, not less.

2. We could build everything ourselves - our own ticket management system, assignment and routing logic, reporting, and so forth - but this meant investing quarters into just building the table stakes before we'd get to any of the "good" stuff.

We went for a middle ground between the two, building our own UI in our own tools for the most part, but interfacing with our 3rd party customer service platform for the things we didn't want to build ourselves, like ticket management.

What it saved us in time to start with, it began costing us soon after. Our third-party platform was quickly becoming an expensive, slow, external database with a data model we didn't want and features we didn't need. For all the improvements we'd made, our maintenance burden remained high, our data messy and incomplete, and our advisor experience somewhat fractured.

Behind the pain hid an opportunity we didn't recognise until some time after. I had left Deliveroo for the world of venture capital, and Matt to help build Echo, one of the UK's largest digital pharmacies. We both knew we wanted to start something together, but we weren't sure what just yet, and were casually exploring some ideas.

In the early days of the Covid-19 pandemic, Echo had gone through the exact same journey with their customer service tooling that Deliveroo had been on. One afternoon, in the middle of a discussion about the size of the payroll software market, Matt bemoaned the state of customer service tooling.

And there it was - contained in a couple of messages, a seed of an idea that stuck.

Over the course of many conversations with companies big and small, what had been just our experience became a pattern, and what had been a distraction grew into a conviction that something like this needed to exist - a customer service platform that was made to be built with. And that if we didn't build it, someone else would.

With Plain, we want to give modern companies an opinionated, modern customer service infrastructure. We are are building a lightning-fast, productivity-focused customer service tool, backed by powerful GraphQL APIs you can use without any restrictions to build your own - giving you everything from issue management to assignment logic and reporting. Our goal is to enable every company to make customer service work for them and their customers — without needing to build everything from scratch themselves, fighting legacy platforms, or writing hacky integrations and apps. Plain is CS without the BS.

Since starting out in late 2020, we've assembled an incredibly talented and proudly small team of designers and engineers, written a boatload of TypeScript and built the building blocks for everything that is to come.

We're at the beginning of an exciting journey to build both a durable product and company. We think that customer service is going to be one of the largest B2B software markets in the world. Every company that has customers, has customer service, and we're building the infrastructure for them.

We're building the product we wish we'd had years ago, for the companies of the next decade.