Four of us, every customer: what joining WunderGraph's CS team is like

We joined WunderGraph this spring. That made the Customer Success team four people: Viola, who leads it, Ale, who had been doing CS here for over a year, and the two of us.

Those four people support every customer on Cosmo and Hub. That includes eBay and SoundCloud, whose engineers run Cosmo at huge scale and spend their days inside it.

People ask us how that math works. Here's our answer five months in, and what we'd tell whoever joins next.

On a big support team, you might own one slice of one product. Here there's no slice. We work on every part of Cosmo and Hub, and we talk with engineering, sales, and marketing most weeks. You get to wear hats a bigger team would never hand you.

It reaches past the company, too. On our recent trip to San Francisco we met customers in person for the first time. Dylan drove a very large Jeep out of a garage four floors underground, then up the cliffside road to Muir Woods with a SoundCloud engineer in the back seat. The engineer said "good driving." Dylan hasn't let it go.

We also spent time on site with eBay. Soon after, eBay told us how much our support, and our showing up in person, had counted. For a team of four, that's a big deal.

Customers notice the size of the team, and they like it. Tim Caplis, Principal Software Engineer at SoundCloud, put it this way in SoundCloud's case study: "What surprised me most is that WunderGraph is a small team that can do big things. It feels like working with another team inside SoundCloud, not a vendor."

For a long time, support here came straight from engineers. Customers still get that closeness. Viola is now building CS around it as its own function, and we joined as that work took off. So we're learning the product and building the process at the same time.

For his first year, Ale carried most of the customer work himself and built the relationships we now share. With four of us, we can plan ahead instead of only reacting: set up processes that last as the team grows, and agree on them together. Viola wrote about the thinking behind this in Customer Success as federation, and it's working. Since the restructure, tickets escalated to other teams have dropped by 96 percent.

A small team also means fast feedback. On past teams, some large and some outsourced, we struggled to get any. Here it comes every day. And when one of us is out, the rest cover. We lean on each other a lot.

Before WunderGraph, I supported software for business users: product managers, project managers, people running an operation.

Here, the customer is an engineer, and often an expert in the part of Cosmo they use most. On one account I took over, the lead engineer works with subscriptions every day, with custom modules and a setup built for his team. Supporting someone like that means showing up prepared. He should never have to repeat his history to a new face.

A handover doc is a good start. It lists open tickets, feature requests, and priorities. But a written priority is flat. Hearing a customer explain what matters to them, in their own words, tells you far more.

So when I took over the account, I watched eight or nine of his recorded calls. It took a while, and it was worth every minute. Three things came out of it that no doc gave me:

• What matters most to him. The topics he returns to are the ones to get right first.
• What's most urgent. You can hear which requests are nice-to-haves and which he needs soon, so I know where to focus.
• Why his setup looks the way it does. Custom modules and choices he made months ago make sense once you've heard him explain them.

Dylan and I also test all the time. We stand up a component on our own machines, break it, and fix it. That teaches you the feature and the calls teach you the customer's version of it. You need both.

My rule for the next hire: before your first call on an account you inherit, watch the last handful of recordings and write down what the customer brings up. That list is your real handover doc. Then ask your teammates every question you have. Ale gets a lot of mine.

Every bug ticket ends with the question: is my fix out yet?

A fix goes through a lot of steps. The customer reports it, we reproduce it, we open a GitHub issue, someone writes a PR, and it gets reviewed and merged. Then a release has to pick it up before the customer can run it. GitHub shows a big purple "Merged" badge that looks like the finish line, but it isn't. The customer only cares about the release.

Checking that by hand meant opening GitHub, finding the PR, confirming the merge, then working out which release, if any, had picked it up. That's about five minutes a ticket. Across a queue where every ticket is at a different stage, it adds up fast.

So I built a browser extension that lets you pick the repo and type in the PR number, and then it tells you whether the PR is merged and, if it is, which release includes it. One lookup instead of three tabs.

Mohamed calls himself its power user. Alberto uses it too, and he talked me into a show-and-tell.

That's part of the job here: figuring out a better way to do things. When something takes longer than it should, you're trusted to fix it, whether that's a process, a doc, or a small tool like this one. It's a great way to be creative and grow your skills. And I like simple things that help.

For customers, this means that when they ask "is it out yet," we can quickly look it up and tell you the version.

I'm also building a starter kit for whoever joins next: a cheat sheet on what each part of the product does and how customers use it, plus demo videos and a hands-on walkthrough you run in your own terminal.

Our goal is for CS to handle more on its own. Fix small bugs ourselves. Know how to look into a problem instead of opening a triage ticket. Know right away whether something is a new feature request or an existing feature, so we can say "here's how it works."

When all four of us can do that, we all win. Every ticket we close ourselves is time engineering spends building the product.

Get comfortable with ambiguity. Be kind to yourself while you learn. Jump in, and ask every question you have.

There's no one right way to ramp up. Dylan jumps into the pile and splashes around; if he splashes someone he shouldn't, they'll tell him. Mohamed prepares more before he speaks. Both work.

Expect to be trusted early. That's what makes the job worth it.

And expect to know your customers. At Dylan's past jobs, customers didn't even know his last name. Sometimes they got a fake first name. Here, they know who we are. As the team grows, we want to keep it that way. Viola explains why in Why Customer Success can't be automated.

Frequently Asked Questions (FAQ)