Plain

To build or to buy your AI support agent? Resend built. Working in Plain, their agents now resolve 1 in 3 tickets automatically – with no negative sentiment. Customer Success Engineer JP Valery shares how they decided, what their agents do, and what he'd tell you before you start. Live on Nov 11.

Every now and then I get asked: “So now with AI, do you see much churn from companies building their own version of your product?” It makes me irrationally angry. Not because I’m offended or because it's presuming something we don’t actually see at all in the numbers, but because the premise defies all basic logic. If AI enables your engineers to build a product you previously bought, what do you think the people building the product you're replacing are doing with the same technology? Writing code on scrolls and sending it by carrier pigeon? The speed increase available to you is available to them too. Except they’re spending 100% of their time on that problem, working through every permutation of problems you don't even know exist yet. So assuming equal (or slower) speed, what exactly are you gaining by building it yourself? Sometimes it's a false belief that "our use case is small". That belief typically has a short shelf life, because it assumes your needs are static (they are not). But usually, the answer is control over a handful of very specific things of outsized value. Nobody wakes up wanting to own email parsing, workflow routing, AI evals, reporting, permissions, or an on-call rota for yet another system. But those are the 95% you have to own if you want to control the final 5%. So what’s an AI-pilled company to do? Languishing on stale SaaS is not an option, but neither is building your own Zendesk over a weekend. Here’s my advice: 1. Do the math. Be very clear about the outcome you can only get by building yourself. The value of that outcome needs to comfortably exceed the engineering time and ongoing ownership you’re taking on. 2. Build the bit that’s well and truly yours. More software is becoming infrastructure: they give you the hard and boring stuff so you don't have to worry about it, with enough primitives on top for you to make it specific to your company (e.g. Plain already works this way), so just use software that works that way. 3. If you're going to buy, buy velocity. A vendor is not a static feature checklist. Pick teams whose rate of improvement you believe in. I’m extremely bullish on AI-pilling almost every line of code. I’m much less bullish on every company rebuilding every core system from scratch. The value and future for most companies is in owning the last mile, not building the whole road.

Vector search gives you similar text. In customer support, you often need how entities connect. For example, a similar past request is much more useful when you can also follow it to how it was resolved. I wrote a short intro to knowledge graphs for this, with the tradeoffs and a couple of resources I liked: https://lnkd.in/d3RiY8Mr

Some ideas are oddly full circle. When we first started, we built Plain as “Stripe for customer support”. Our belief was that support was eventually becoming an infrastructure problem: that companies would eventually not just buy support, but build some of it too. Build their internal tooling, their own processes, and so on. So we built Plain API-first; where everything the UI could do, the API could do - where machine users were a first class concept next to human users. But in 2022, the only companies building support tooling in-house were very large companies with very large engineering teams who wouldn’t buy from a 7-person startup. And even for them, building things for support was expensive. Fast forward a couple of years, and the equation has completely changed. AI agents are becoming the primary users of software systems. But asking AI agents to work through a limited API is like tying one hand behind their back. You have the intelligence, but not the tools. Equally, it's now cheap to build things. If you're in support and you have access to Claude, Cursor or ChatGPT, you can just point it at the problems in front of you and have it build you tooling. But what do you build them on? A point-and-click UI? Our infrastructure thesis is being validated by the market in real time. Every week, more and more companies switch from a UI-first vendor to Plain. Sometimes you're not wrong, just very early! The below is a picture from an Airbnb Matt Vagni and I rented for a few days to outline the initial vision for Plain - a picture I know he'll hate me for sharing 👇

Every AI support company is racing to automate answers. I don't see many putting the same effort into stopping those questions from happening in the first place. When an AI agent solves the same question 500 times in a day, people celebrate it as a win. 500 deflections. Or maybe 500 customers just hit the same confusing flow or broken feature, and the AI handled it so smoothly that nobody in product ever noticed. One thing I've learned is that repetitive support work is product feedback. Before AI, answering the same question over and over created pressure. Someone got tired of it, filed the bug, improved the documentation, or escalated the problem. The repetition was telling us where the product was falling short. If AI quietly handles every repeat question, it's easy to lose that signal. Your support metrics look great. Customers get answers faster. Meanwhile the same product issue keeps generating the same conversations because nobody is connecting the dots. The teams I think are getting AI right are using it for that too. They're clustering similar conversations, spotting patterns, and giving product teams a much clearer picture of what customers are actually struggling with. That's a much more interesting future than an AI that just closes tickets faster.

We analyzed 1,224 technical support job postings. 46% now expect the person to fix the problem, not escalate it.