The first 90 days of a founding CX hire.

An honest account of what good actually looks like when you're the first support person hired into a scaling company. Not a 30-60-90 template. A walkthrough of where the leverage really is, what to avoid building too early, and how to earn trust in a function nobody has had to think about yet.

Most 30-60-90 plans get this role wrong

Search "first 90 days as support lead" and you'll find dozens of frameworks. Days 1-30: learn the product. Days 31-60: meet the team. Days 61-90: implement quick wins. They look professional and they tick all the right boxes.

They also miss the point.

When you're a founding support hire, the company has been operating without dedicated support up to the point you arrive. The product team has been answering tickets. The CEO has been answering tickets. Customer Success has been answering tickets. By the time someone is hired into the role, support is already happening, just badly and at huge opportunity cost to the people doing it.

Your job in the first 90 days isn't to build a support function. It's to relieve the people who are currently absorbing support in a way that doesn't break customer trust, and to do it quickly enough that the business feels the difference within a quarter.

That's a fundamentally different brief than "set up Zendesk and write some macros."

The first 30 days: stop the bleeding

Before you build anything, you need to understand what's currently broken and why. The first month is investigative, not constructive.

Sit in the queue, on day one

Whatever ticket queue currently exists, however ugly, get into it. Read every ticket from the last 60 days. Not summaries. The actual conversations. Make a private list of:

• The most common reasons customers reach out
• The most common ways those reasons get answered (correctly or otherwise)
• The product issues showing up repeatedly that nobody has flagged
• The customers who get treated differently because they're loud, big, or both

You are not looking to fix anything yet. You are looking for the texture of the function. This is the only chance you'll have to come at it as an outsider with fresh eyes.

Find out who's secretly been doing your job

In every founding hire situation, there is at least one person who has been quietly absorbing support work alongside their actual role. It might be a Customer Success Manager, an engineer who's good with customers, or the founder themselves. Find that person. Talk to them honestly. Ask them what they think is broken and what they want to stop doing.

This person will be your most important early ally and your sharpest source of context. They've been operating with full responsibility but no authority. Your arrival should be a relief, not a threat.

Don't promise anything for 30 days

Resist every urge to commit to outcomes in week one. You don't yet know enough to know what's hard, what's easy, and what's a trap. Set the expectation up front: "I'll spend the first month understanding what's actually happening, then I'll come back with a plan."

Anyone who pushes against this is the person you most need to push back on. Founding hires that commit to specific outcomes in week one usually deliver the wrong outcomes by week four.

The next 30 days: pick the one thing that matters most

By day 30, you should have a clear, evidence-backed view of what's hurting most. Now you choose. The mistake at this point is trying to fix everything. The right move is to identify the single highest-leverage problem and resolve it definitively.

What "highest leverage" actually means

The highest-leverage problem is rarely the noisiest one. It's the one where, if solved, multiple downstream issues disappear. For example:

• If 40% of tickets are about the same product behaviour, fixing the product or the help article disposes of 40% of your queue
• If response times are slow because tickets are routed badly, fixing routing improves perceived quality across every conversation
• If the team currently absorbing support has no clear handover process to you, building that handover unblocks everyone

Pick the one that, when resolved, will do the most for the people currently absorbing the work. Their relief is your most important early signal of value.

Build it well, but not perfectly

Whatever you choose, build it solid enough that it lasts a year, not solid enough that it lasts five. Founding-stage tooling and processes are meant to be replaced as the company grows. Building for the version of the company you currently work for, not the one you imagine in three years, is a discipline most operators struggle with.

Document everything as you go

Every decision, every workflow, every tooling choice should be written down somewhere central. Not because anyone will read it now, but because in nine months when you have to explain why a thing exists, you'll be glad you wrote it down. Founding hires who don't document their own decisions become the only person who can answer their own questions, which is a slow trap.

The final 30 days: prove you've earned the next ask

By day 60, you've stopped one specific bleed. By day 90, your job is to demonstrate that what you've done is structurally different from what was being done before, and to earn the right to ask for the next thing.

Make the impact visible without overclaiming

Whatever you've fixed, quantify it honestly. If response times dropped, by how much. If a category of tickets is no longer reaching the team, by what proportion. If a particular person was spending five hours a week on support and is now spending one, name them and the time saved. Concrete, attributable wins build credibility faster than aggregate metrics.

Surface what you found that nobody knew

The most underrated value of a founding support hire isn't the support work. It's the visibility into the customer that the function gives you. By day 90 you should have at least one observation that surprises the leadership team. Maybe a recurring product issue nobody flagged. Maybe a sales misalignment that's costing renewals. Maybe a customer segment that's quietly under-served.

This is where the role moves from helpful to strategic. The first time you tell the CEO something about their product they didn't know is the moment your seat at the table stops being conditional.

Make your case for what comes next

Founding hires often spend the first 90 days proving they can do the work, then make the rookie mistake of waiting to be asked what's next. Don't wait. By day 90 you should have a clear, costed view of the next quarter. What you'll build. Why. What it will cost. What it will return. Bring it to leadership unprompted.

This is also the moment to start the conversation about what support is allowed to become. A retention mechanism? A source of product intelligence? A commercial function with its own P&L over time? The answer depends on the company, but the question only gets harder to ask the longer you leave it.

Three things to avoid building too early

The pressure to build infrastructure in the first 90 days is real and almost always misplaced. There are three specific things I'd avoid:

A complex tooling stack

You don't need it yet. A single inbox, a help article platform, and a clear escalation path is enough for the first 90 days. Stack complexity should follow team size and ticket volume, not precede them.

A formal QA or scoring framework

Quality frameworks need a baseline of consistent behaviour to score against. In the first 90 days you don't have that. Building a rubric before you have a team or a stable response pattern just creates an artefact nobody uses. Wait until there are at least two people doing the work consistently.

A long-term roadmap

You don't know enough yet. Anything beyond the next quarter is fiction. A clear next-quarter plan signals confidence. A 12-month roadmap built in month three signals overreach.

The principle that matters most

If there's one principle worth carrying through these 90 days, it's this: founding CX is not a junior version of senior CX. It's a different role entirely.

Senior CX leaders manage existing functions. Founding CX hires create the conditions for one to exist. The skills are different. The leverage points are different. The political situation is different. Treat it as a distinct role and the work gets clearer.

The companies that get this right hire founding CX people with the explicit understanding that they are building infrastructure, not running it. The companies that get this wrong hire someone to "look after support" and watch them quietly burn out trying to do both at once.

If you're hiring for one of these roles and you've read this far, the test is simple: can your founding CX hire still credibly answer tickets in 18 months, or will they have built systems that mean they don't have to? The answer should be the second one. If it's the first, the role was scoped wrong from day one.