Why your first support hire won't save you
Every founder hits the same breaking point.
You've built a great product. Customers are signing up. And those customers have questions, lots of them. At first, you handle it yourself. Then one day, you find yourself thinking: "If I have to answer the same question I've already answered 3,000 times before one more time, I'm going to unplug the main server and set everything on fire."
So you hire someone to just answer the emails.
Problem solved, right?
Not quite.
Ines van Dijk has spent 15 years in customer support, as an individual contributor, team lead, QA specialist, and for the past six years, a consultant helping SaaS founders build their first support function. She's seen this pattern repeat so many times that she wrote the book on it. Literally. Her book, The Customer Support QA Playbook, just hit shelves.
In this episode of One CX, Ines unpacks why hiring someone to answer emails doesn't fix your support problem and what actually does.
Key Takeaways
1. Hiring someone to "just answer emails" doesn't solve the problem
The typical startup trajectory looks like this: founders answer all customer questions themselves, knowledge lives in their heads, volume increases, they hit a breaking point, and they hire someone to take over.
But here's what actually happens:
"You hire someone who doesn't have that knowledge. There's no knowledge base. The founders are still in the queues because all of the information is still up here, not on paper. By hiring someone, you haven't fixed the problem. You've just added headcount."
The result? A patchwork team that answers questions, but with no efficiency, persistent escalations, and no way to extract business intelligence from customer conversations.
2. Define what "good" looks like
Before you hire anyone, you need a firm definition of what good support looks like. But here's the catch: your definition might not match your customers' expectations.
Ines shared an example from a fintech client experiencing high churn:
"The stakeholders said they wanted agents to behave in a more formal way because they're a financial product. I looked at their customer base, all millennials, people who communicate in emojis. They don't want to be spoken to like a 1950s bank manager. They want to make friends."
The lesson: Talk to your entire company, marketing, sales, product, and your agents. Then validate it with your customers. That's where QA comes in.
3. Support is a business lever, not a cost center
Marketing and sales work hard to win customers. But if those customers land with an underpaid, undervalued, underestimated support team, they churn.
"Maintaining an existing customer is seven times cheaper than bringing them in. So the ROI on maintaining good relationships is much higher than actually acquiring new ones."
But retention is just the start. A strategic support function also:
- Discovers product intelligence (what features customers actually want)
- Reduces contact drivers (fixing recurring issues)
- Stays ahead of competition by listening to customers daily
Support talks to your customers more than any other team. It makes sense that strategic data flows from there.
4. QA is about trust, not control
When you implement QA, agents often push back. They feel like they're under a microscope—being graded like they're back in school.
Ines reframes it completely:
"Even Olympians have coaches. Even when they're at the absolute top of their field, they still have coaches. That is your job. You are a coach, not a teacher grading assignments."
The goal isn't to catch people doing things wrong. It's to find opportunities to help them skyrocket. When you build that trust, agents bring problems to you. They flag broken processes. They become partners in improving the function—not just ticket-closers.
5. CSAT is a vanity metric
Ines is "notorious" for her CSAT stance—and she doesn't hold back:
"A lot of companies say: 'CSAT has been stable at 93% over the past three months.' Okay, cool. But does that mean you're really good at giving people support—or are you just really good at apologizing for your product?"
One metric in a vacuum tells you nothing. And the customers who don't respond to your survey? They're often the ones already halfway out the door.
Context matters more than scores.
6. Don't make your first hire wear 10 hats
The biggest mistake Ines sees founders make: hiring one person and expecting them to do everything.
"We want you to provide technical insight. We want you to do process workflows. We need you to do people management. And also, we're not going to pay you much because you're just answering emails."
This sets everyone up for failure. Support isn't an entry-level admin task. If you treat it that way, you'll get entry-level results.
7. Start your QA process now, not "eventually"
As companies scale, QA gets filed under "I'll get to that eventually when I put out these other fires."
Ines has a question for those founders:
"Open your calendar and show me where 'eventually' is scheduled. Because it typically doesn't occur."
The longer you wait, the harder it becomes. An established team will resist adopting new processes. But if QA is there from the start, it's just how things work.
About Ines van Dijk
Ines van Dijk is the author of The Customer Support QA Playbook and a QA consultant who helps SaaS founders build their first strategic support function. With 15 years of experience across individual contributor, team lead, and consulting roles, she's seen every phase of support team development—and every mistake founders make along the way. Her book is available on Amazon in paperback and Kindle formats.
The Customer Support QA Playbook is available on Amazon.
One CX is a podcast by Knoccs featuring interviews with B2B SaaS founders and CX leaders sharing real-world tactics to craft better experiences, stronger relationships, and faster growth.
View More Episodes
.png)
“Accuracy over speed”: The playbook for building resilient customer support teams | Bruno Cruz

Why your first support hire won't save you | Ines van Dijk- Author of The Customer Support QA Playbook


.webp)