Fifteen customer case studies: Lumos, Ethoca-Mastercard, Clearwater, FlexTrade, StarzPlay

In a little over a year at Gotransverse I authored fifteen enterprise case studies. Named logos, real deployments, quotable customers: Lumos, Ethoca-Mastercard, Clearwater Analytics, FlexTrade, StarzPlay, Ziply Fiber, and others. People assume the hard part of a case study is the writing. It isn’t. I can write. The hard part is getting a busy enterprise customer to say the one specific, concrete sentence that makes the whole piece land — and then getting their legal and comms teams to let you keep it.

This is what I actually learned making fifteen of them.

Why fifteen and not three

When I arrived, we had almost no customer proof. For a company selling a complex, expensive, technically demanding platform to enterprise finance buyers, that’s a serious gap. Enterprise buyers don’t take your word for anything. They want to see someone like them — same industry, same scale, same problem — who bought this and survived. Proof is the currency of enterprise sales, and we were broke.

So the goal wasn’t “write a nice case study.” It was to build a proof library deep enough that whatever a prospect’s objection was, I had a customer story that answered it. Worried about usage-based billing at scale? Here’s StarzPlay. Worried about financial-services rigor? Clearwater, FlexTrade. Worried about telecom complexity? Ziply Fiber. Worried about payments and card networks? Ethoca-Mastercard. The library had to cover the objection map, which meant volume — and volume meant building a repeatable process, not artisanal one-offs.

The part nobody warns you about: the sentence

Every case study lives or dies on one thing — a specific, quantified, human sentence from the actual customer. Not “Gotransverse has been a great partner.” That sentence is worthless; it’s what customers offer you by default because it’s safe and says nothing. The sentence you need sounds like “we cut our close cycle from eleven days to four,” or “we stopped writing custom middleware for every new usage source.” Concrete. Costly to fake. Impossible to say about a product that didn’t actually do the thing.

Getting that sentence is the whole job. And it’s hard, because:

The customer is busy and this is not their priority. You’re asking a finance or ops leader to spend an hour helping your marketing, on top of their actual job. If the process is painful, they ghost you, and the case study dies half-written. I learned to make it absurdly easy for them — I did the drafting, I proposed the quotes based on what they’d already told me in interviews, and I let them edit rather than compose. People will fix a sentence they won’t write from scratch.

The good quotes are the ones legal wants to cut. The more specific and quantified the sentence — the better it is for me — the more likely someone in the customer’s org gets nervous about it. “Are we comfortable putting a real number on that?” I learned to have the numbers pre-approved conversationally before they ever hit a draft, so the quantified claim wasn’t a surprise landing on a legal reviewer’s desk.

The process I built

Fifteen in a year only works with a system. Mine had a shape.

Interview for stories, not quotes. I stopped asking customers “can I get a quote about ROI?” and started asking “walk me through what your month-end close looked like before, and what it looks like now.” People can’t recite marketing copy, but they can tell you what their Tuesday used to be like. The quotable sentences fall out of the story naturally, and they’re better because they’re real.

Draft the whole thing, then let them react. I’d write the full case study — problem, solution, outcome, quotes and all — from the interview, then send it as “here’s a draft, please correct anything wrong.” Correcting is a ten-minute task. Composing is a task they’ll postpone forever. This one shift probably doubled my completion rate.

Standardize the skeleton, vary the substance. Every case study followed the same bones — the situation, the specific problem, what we did, the measurable result — so I wasn’t reinventing structure fifteen times. The discipline was in the specifics: real numbers, real workflows, industry-accurate language. A template for the frame, never for the content.

Get the approval path mapped before writing. The thing that kills enterprise case studies isn’t the draft — it’s the six-week silence while it sits in the customer’s legal and comms review. I learned to ask early: who has to approve this, and what will they object to? Then I wrote to survive that review the first time.

What these did beyond marketing

The case studies were built for sales proof, but they earned their keep in places I didn’t expect.

Analysts used them. When I briefed Gartner, Forrester, IDC, MGI, and ISG, the case studies were the evidence behind the claims. An analyst discounts your positioning and believes your customers. A named customer with a real number moves an analyst’s perception faster than any amount of well-argued messaging.

Sales stopped waiting on me. Once the library was deep enough, AEs could pull the right proof point for a given objection without asking marketing to produce something bespoke. The whole point of a library is that it’s self-serve.

Product heard the truth. Interviewing fifteen customers about what actually changed for them is, incidentally, the best product feedback loop in the company. I brought things back to product and engineering that they hadn’t heard through support channels, because customers say different things to marketing than they say to a ticket queue.

What did not work

The honest ledger.

Some of the best stories never became case studies, because the customer wouldn’t go on record. A few of our most impressive deployments involved customers whose policy simply forbids public endorsement — financial institutions, mostly. I have incredible proof I can never show anyone. That’s just the cost of selling to conservative industries, and no amount of relationship-building changes a bank’s PR policy.

A few case studies aged badly. A quantified claim from eighteen months ago — “cut close time by 60%” — becomes a liability if the customer’s situation changed and someone checks. I didn’t build a good enough refresh cadence, and a couple of pieces are now older than I’d like. A proof library needs maintenance, not just production, and I under-invested in the maintenance.

And volume created sameness. When you’re making fifteen of something on a system, they start to sound like each other. The best case studies have texture — a specific detail that only that customer would say. Under deadline pressure I sometimes let a piece hit the template and stop there, and those are the ones nobody remembers. The system that let me make fifteen also tempted me to make them interchangeable.

What I would do differently

Build the refresh cadence on day one. Every case study should have a review date attached — a calendar reminder to check whether the numbers still hold and the customer’s still happy. Production without maintenance is how a proof library slowly turns into a liability.

Chase the one weird detail in every interview. The line that makes a case study memorable is never the ROI number — it’s the specific, slightly odd human detail. The team that named their old process something unprintable. The controller who cried at the first clean close. I should have protected time to find that detail in every single one, not just the ones where it fell in my lap.

Get more non-finance voices. Almost all my quotes came from finance and ops leaders, because that’s our buyer. But the engineers and admins who actually use the platform daily have a different, often more credible story — and I mostly didn’t capture it.

Fifteen case studies, one repeatable system, and a proof library that finally let our sales team stop taking my word for things and start showing customers instead. If you’re building customer advocacy from zero at a company that badly needs proof, send me a note — I have a lot of opinions about getting the quote.