Making Your First Support Hire

You’re doing support yourself. Maybe you and your cofounder split it, maybe it’s squeezed between product work, maybe it’s eating into evenings. At some point, the math stops working. Here’s how to think about that transition.

When to Hire

The right time isn’t a ticket count—it’s a cost calculation.

Your time has a shadow cost. If you’re billing $200/hour for consulting, or your engineering output is worth $150/hour in product velocity, every hour on support has a cost. A support person at $50k/year ($25/hour loaded) is cheaper once support exceeds 3-4 hours daily.

Quality is suffering. Rushed responses, longer resolution times, customers following up because their issue wasn’t handled. These have costs too—churn, bad reviews, lost referrals.

You’re avoiding support. When you start dreading the inbox, you’re probably not giving customers your best. That’s a sign you need someone who wants to be there.

You’re missing patterns. Dedicated support people catch things: repeated questions (documentation gaps), confusion patterns (UX issues), feature requests (product opportunities). When you’re context-switching, you miss these.

Quick math: If support takes 15 hours/week and your time is worth $100/hour, you’re spending $78,000/year on support. A full-time hire is probably cheaper—and will probably be better at it.

What to Look For

First support hire is different from adding to an existing team. You need a particular profile.

Must-Haves

Writing ability. Support is written communication. Someone who can write clearly, empathetically, and efficiently will handle 2x the volume of a poor writer. Ask for writing samples. Have candidates respond to a sample ticket.

Customer empathy. They need to genuinely care about helping people, not just closing tickets. Ask about times they went above and beyond. Listen for enthusiasm, not obligation.

Learning speed. Early-stage products change fast. They’ll need to absorb new features, changed behavior, and evolving processes. First hire can’t be someone who needs everything documented before acting.

Independence. You won’t have time to manage closely. They need to make judgment calls, escalate appropriately, and not freeze when uncertain. Ask about ambiguous situations they’ve navigated.

Nice-to-Haves

Product intuition. Someone who can identify when a “support issue” is really a bug or UX problem. Technical background helps but isn’t required.

Previous support experience. Cuts ramp time, brings best practices. But someone with the right disposition and no experience can outperform experienced people who are burned out.

Writing in your voice. Brand consistency matters. Someone who naturally writes like your company is gold.

Red Flags

“I’m a people person.” Support is 80% written. Loving phone conversations doesn’t translate.

No questions about the product. If they didn’t research what you do before the interview, they won’t research edge cases on the job.

Complaining about previous customers. Everyone has war stories, but attitude toward difficult customers matters.

Overemphasis on metrics. First hire needs to build the foundation, not optimize throughput. Metric obsession too early creates the wrong incentives.

Where to Find Them

Customer-facing roles at similar companies. Customer success, community managers, support at early-stage startups. They understand the environment.

Hospitality refugees. People leaving restaurants, hotels, retail—often great temperament, underestimated by tech companies, grateful for normal hours.

Your own customers. Someone who already knows and loves the product. Reach out to your most engaged users. Seriously.

Support communities. Support Driven, Elevate CX, Help Scout’s blog comments. People actively learning about support.

Don’t: Hire your friend who needs a job. Don’t hire for potential. Don’t hire the first person who applies. This role matters too much.

The Interview Process

Step 1: Written Exercise

Send a sample support ticket (something realistic but slightly complex). Ask them to respond. Time them—they should be thorough but not take forever.

Evaluate: Writing quality, empathy, clarity, appropriate next steps.

Step 2: Video Interview

Focus on scenarios and philosophy:

• Tell me about a time a customer was wrong but upset. How did you handle it?
• What would you do if you didn’t know the answer and couldn’t find it documented?
• How do you decide when to say yes vs when to push back?
• What’s the difference between a good and great support experience?

Listen for thoughtfulness, not rehearsed answers.

Step 3: Product Deep-Dive

Have them use your product and identify three things: something confusing, something they’d improve, something they’d praise to customers. This shows product intuition.

Step 4: References

Call references. Ask specifically: How did they handle upset customers? How quickly did they learn the product? Did they work independently?

Setting Them Up for Success

First hire in any function is hard. Support has specific challenges.

Documentation

Write down everything you know:

• Common questions and answers
• Edge cases and how to handle them
• Escalation paths (who handles what)
• Brand voice guidelines
• Tool access and workflows

You’ll realize how much is in your head. That’s the point.

Shadowing Period

Have them watch you do support for a week. Then swap—you watch them. Corrections in real-time are more effective than reviews after the fact.

Clear Escalation Paths

When should they ping you? When should they just handle it? Make this explicit. “Bug reports go to engineering Slack. Refund requests over $100 come to me. Everything else, use your judgment.”

Feedback Cadence

Weekly 1:1s for the first three months. Daily check-ins for the first two weeks. They need to know they’re not alone, especially early.

Authority to Act

Give them real power. Can they issue refunds up to $X? Can they offer discounts? Nothing kills morale faster than needing approval for everything.

Common Mistakes

Hiring too early. You lose customer signal before you understand what customers need. Founders should do support until it’s genuinely painful.

Hiring too late. You’re burned out, quality has suffered, and you onboard someone while exhausted. They inherit problems instead of building systems.

Wrong title. “Customer Support Specialist” is fine. “Customer Happiness Ninja” makes good people not apply.

No clear metrics. What does success look like? Response time? Resolution rate? Customer satisfaction? Define it before they start.

Assuming they’ll figure it out. Support systems don’t emerge naturally. You need to build them together, then hand them off.

Tools for First Hire

Keep it simple. Your first hire doesn’t need enterprise software.

• Dispatch Tickets: Per-ticket pricing means you don’t pay extra for their seat. They can focus on customers, not navigating complex tools.
• Shared documentation: Notion, Coda, or Google Docs. Somewhere for institutional knowledge.
• Communication: Slack channel for support-related discussion with you.

Don’t buy Zendesk for one person. Don’t build custom tooling yet. Simple tools that work beat complex tools that don’t.

The Transition

Handing off support feels uncomfortable. You’ll want to check everything. You’ll see mistakes and want to jump in.

Resist. Let them make small mistakes and learn. Jump in only for serious issues. Your job now is to help them improve, not to do it yourself.

The goal: within 3 months, you should be able to ignore support for days without worry. If you can’t, something’s wrong—either the hire, the systems, or your willingness to let go.

Related

• Should Founders Do Customer Support?
• Scaling Customer Support
• Support Software ROI Business Case