How Solo Helped Descript Respond to Customers 80% Faster on Issues that Previously Required an Engineer

Before committing to Solo, Descript looked at a few alternatives seriously.

Notion AI was on the list. For content that lived cleanly in Notion it performed well, but Descript's Notion instance carries years of project history—unfinished work, old feature specs, deprecated flows. The AI struggled to separate what's current from what was once true, and when they tried connecting Notion to Slack and GitHub to broaden its context, the conflation got worse, not better. The hallucination rate was higher than they could accept when agents are answering real customer questions that need to be factually correct.

They also took a hard look at building something internally. The capability was there—they had access to solid AI tooling and the relevant data sources. But the conversation kept landing in the same place.

"Sure, we can build this internally—but a company with a dedicated team of people is going to build the same tool better than one or two people [at Descript]. And then it always comes back to: who owns it? Who manages the upkeep? Who corrects the hallucinations?"

A few things made Solo the clear choice once they started comparing seriously.

The feature flag integration was a deciding factor. Descript uses feature flags heavily to control what's live for which users at any given time. A tool that could read the codebase but couldn't tell you what was actually turned on was only half useful.

"If we don't know about the feature flags, knowing what's in the codebase is almost useless."

The Slack integration mattered just as much. It meant agents didn't have to change how they worked—Solo met them in the channel they were already in. And Solo's answers came with citations, so agents could verify a response against the actual code or pull request before passing it along to a customer.

Also, the Solo team's willingness to engage with Descript's specific needs stood out. The feature flag integration, the Zendesk connection, the nuances of their help center—none of it got brushed aside as an edge case.

"There seems to be a genuine, real interest in making Solo better for Descript, even with what feels like very nuanced or narrow scenarios that might only apply to our organization. That openness to feedback has been fantastic."

The escalation chain that used to define customer support at Descript has largely flattened. When agents have a question now, they ask Solo directly in Slack. They get an answer with a source they can verify, and they move on. The ask-wait-ask-wait loop is gone for most questions.

Agents who aren't embedded in engineering channels can now self-serve technical context they never had access to before. Customers get faster answers, and the engineering team gets fewer interruptions from support.

Jason also uses Solo to write better Linear tickets when something does need engineering attention. Instead of writing a vague ticket and waiting for engineers to do the heavy lifting, he can ask Solo where the relevant code lives, get a precise pointer, and include that in the ticket.

"I'll ask Solo: where is this in the code? And then I can point engineers directly to where they need to look, instead of filing a vague ticket and having them do a ton of footwork."

The impact on engineering is real. With the full technical context already in the ticket, engineers can move from ticket to fix much faster—sometimes skipping the back-and-forth clarification stage entirely.

On the morning routine front: instead of working through a Slack backlog and building a to-do list of things to follow up on, Jason reads Solo's daily release notes. It gives him a clean, citable view of what changed—with links to the feature flag and the GitHub PR—and he can move on to actual work.

• 75% reduction in questions sent to engineers
• 80% faster responses to customers for issues that previously required an engineer