From no support function to a documented, tooled, trained operation in four weeks

The problem

The company was growing. Their product, a B2B SaaS identity security platform, was adding customers. Support was running the way it runs at many early-stage companies: engineers handled tickets on the side of their onboarding and integration work.

But the cracks were showing in a way that couldn't be ignored. Customers were escalating directly to the CEO. Support problems were landing on the founder's desk, pulling them into firefighting instead of building the company.

The real support work wasn't happening in Jira. It was happening in Slack. Engineers were resolving issues, making promises, and closing loops entirely in scrollback, invisible to any system. Jira Service Desk had tickets, but the tickets didn't reflect reality. What was actually open, what had been promised, what had been resolved, none of that was in the record. Institutional knowledge lived in conversation history that nobody could search, report on, or hand off.

The contract SLA included a commitment to unlimited telephone support. It had never been operationalized, and given current staffing, it wasn't realistic. No defined support channels, no customer portal, no knowledge base strategy, no documentation of how any of it was supposed to work. The two engineers carrying the load had no path to hand it off. Nothing was measurable. Nothing was visible.

Leadership had already made the decision to move to Zendesk. What nobody had was a way to operationalize that change: the workflow it should run, who owned what, how to migrate, how to train the team, how to go live without dropping customers in the middle. The tool was chosen. The readiness to use it wasn't there.

The action

The engagement ran four weeks, starting with discovery.

In the first week, I interviewed the support engineers, customer success, and the co-founder. I sat in on standups, mapped current support flows in Figma, and reviewed the Jira implementation alongside the contracts. The first recommendations went to the team on day two.

The approach centered on people, process, and tools. Zendesk with clarity on the underlying process would make support measurable and give the engineers a real path to hand off the work so they could focus on onboarding and integrations, what they were actually hired to do.

Week two was design. We defined a ticket status flow, priority levels, and question types. We built a product-area taxonomy. I wrote an SSO spec so customers logged into the product could reach the support portal in a single click without a second login. We outlined differentiated support tiers and reviewed the first Zendesk design with leadership.

Week three was build and train. I QA-tested the Zendesk configuration, trained the team, built the migration plan, and set a go-live date. I reviewed the contract SLA and submitted comments. The unused telephone support commitment was repositioned as a possible premium tier option rather than a baseline obligation that couldn't be met.

Week four was operationalize. I wrote a full support procedures playbook formatted as a multi-tab RACI, consolidating every flow into one model. I built a custom Jira query to identify exactly which tickets to migrate. We ran ticket cleanup with the team and did a final walkthrough.

A few recommendations that shaped the work:

• Every support request lives in a ticket, no exceptions. No more Slack as the system of record.
• Don't offer inbound phone yet. It requires more staffing than is available. Launch with email first, then recruit friendly customers as portal early adopters.
• Move only active open tickets to Zendesk. Don't try to move history over. Speed to value matters more than completeness.
• Keep feature requests linked in Jira from day one.
• Support tiers should move beyond just faster SLA response times and reflect real value drivers.

We hit the go-live date.

The result

Before this engagement, the CEO was the escalation path. Support decisions were invisible, undocumented, and unmeasurable. Engineers were spending time in support conversations with no record of what was said, no way to triage, and no path to hand any of it off.

At close, the company had:

• A configured and QA-tested Zendesk instance
• A trained team
• A full support procedures playbook (RACI format)
• A reporting baseline, support was now measurable for the first time
• A defined escalation path, so customer issues had somewhere to go that wasn't the founder's inbox
• A roadmap for tiered and premium support
• An SSO spec handed to engineering for portal access without a second login
• A clear path for the engineers to hand off support work and refocus on onboarding and integrations

My engagement closed at go-live. I don't have post-launch metrics to share and won't invent them. What I can say is that all of this was in place on the date it was supposed to be.

Why this matters for AI readiness

This was not an AI project. The technology at the center of it was a ticketing platform.

But the work itself, defining what "open" means, building triage logic, establishing priority levels, creating documentation people can actually use, training the team before going live, is exactly the work that determines whether any technology investment delivers value. AI included.

The pattern I see repeatedly in organizations trying to get AI to work in support: they buy the tool before they've answered the questions this engagement forced. What does a ticket mean? Who owns triage? How do we define priority? How do we measure what's working? What happens when a customer doesn't respond? Where does an escalation go if the CEO is no longer the answer?

AI can't answer those questions for you. It inherits whatever process you give it. If support is happening in Slack scrollback with no record of what was promised or resolved, AI makes it faster to operate that way at scale.

That's Dyad CX's core thesis: readiness work, aligning people, process, and tools, is what makes any implementation pay off. Not the tool selection. This company had already made that call, and it was a good one. Not the deployment. The readiness. This engagement is a clean example of that thesis without the AI layer, which makes the lesson easier to see.