Service Cloud vs. Custom Ticketing: The Question Most Companies Answer Backwards

Every few months I get pulled into a conversation that starts the same way. A company has outgrown whatever they were using to handle customer issues — maybe it was a shared inbox, maybe it was a homegrown ticketing tool one of their engineers built over a long weekend three years ago — and someone in leadership has decided it’s time to “get serious about support.” Usually that phrase gets translated almost immediately into a single question: Service Cloud or build something custom?

I understand why that’s the first question people ask. It feels like the big, expensive, strategic decision, and in a sense it is. But in fifteen years of sitting in these conversations, I’ve come to think it’s almost always the wrong first question, or at least the wrong second question, because it gets asked before anyone has actually answered the question underneath it: what does this business need its support process to do that it isn’t doing today?

Skip that step, and you end up picking a platform to solve a problem you haven’t defined yet. I’ve watched that go badly in both directions — companies who bought Service Cloud and used maybe fifteen percent of what they paid for, and companies who built custom tools that quietly turned into unmaintainable liabilities within two years. Neither failure was really about the platform. It was about the order of operations.

The process question comes first, and almost nobody asks it seriously

When I start a Service Cloud discovery engagement, the temptation on both sides is to jump straight to features. Omnichannel routing, Einstein case classification, entitlements and milestones, the console layout. All of that matters eventually. But I’ve learned to hold off on any of it until I’ve mapped, in detail, what actually happens between the moment a customer has a problem and the moment it’s resolved.

That sounds obvious, but most organizations have never written this down in a way that reflects reality rather than policy. There’s the process on paper — tickets come in, get triaged, get assigned, get resolved within SLA — and then there’s what I call the process in practice, which usually has three or four exception paths that consume a disproportionate amount of actual staff time. A refund that needs manager sign-off. An issue that has to loop between support and engineering before anyone can answer the customer. A VIP account whose tickets get quietly handled outside the normal queue because the account manager has a personal relationship with the client and doesn’t trust the standard process to move fast enough.

None of those exception paths show up if you start the conversation by talking about platforms. They show up when you sit with the people actually closing tickets and ask them to walk you through the last five difficult cases they handled, step by step, including the parts they’d be a little embarrassed to admit happen.

Why “we need more flexibility” usually means something narrower

Custom-build advocates almost always lead with the flexibility argument, and I don’t think they’re wrong to value flexibility. I just think the argument is usually aimed at the wrong target. When I dig into what “flexibility” actually means to the people asking for it, it’s rarely a genuine need for arbitrary, unbounded customization. It’s a specific, nameable gap — a scoring model for prioritizing tickets that doesn’t map cleanly onto Service Cloud’s case fields, or an integration with a proprietary internal system that predates the CRM entirely, or a workflow around a niche product line that behaves nothing like the rest of the business.

Those are real gaps. But they’re usually two or three specific gaps, not a wholesale argument for building an entire ticketing system from the ground up. I worked with a healthcare technology company a while back that had convinced themselves they needed a fully custom support tool because their equipment-return workflow was, in their words, “too weird for any off-the-shelf product.” When we actually mapped it, the weirdness came down to one thing: a multi-step approval chain tied to equipment serial numbers and warranty status that needed to trigger different case paths depending on the outcome. That’s a Flow. That’s not a six-month custom build. What they needed wasn’t a different platform. It was someone willing to sit with the actual exception case long enough to model it properly instead of declaring it unmodelable.

The maintenance cost that never makes it into the initial pitch

Here’s the part of the custom-build argument that I think gets consistently underweighted: someone has to own that system indefinitely, and the person who builds it is rarely the person still there three years later to maintain it. I’ve inherited more than one client relationship where the original custom ticketing tool was built by a developer who has since left the company, documentation was thin or nonexistent, and the current team is afraid to touch the code because nobody fully understands what will break if they do. At that point, the “flexibility” the custom build promised has become a form of technical debt that actively prevents the business from changing its own process, which is the exact opposite of what flexibility was supposed to deliver.

Service Cloud has real limits, and I’m not going to pretend it’s the right answer for every business. But it comes with a maintenance model that doesn’t depend on one person’s tribal knowledge, an ecosystem of admins who can pick up where a predecessor left off, and an upgrade path that’s handled by Salesforce rather than by whoever’s available on your team that quarter. That’s not a minor consideration. For a lot of mid-sized companies, it’s the actual deciding factor, even if it never gets stated as one in the initial platform comparison.

What I actually look for before recommending either path

When I’m brought into this decision, I try to get clear answers to a few things before I’ll commit to a recommendation:

• How many genuinely distinct exception workflows exist, not how many feels like a lot in conversation, but how many actually show up with enough frequency to matter. Two or three well-defined exceptions can usually be modeled inside Service Cloud. Eight or nine, especially if they interact with each other, start to be a real signal that the business’s support process is unusual enough to need more room than a standard platform gives.
• Who owns this system in three years, and whether that person or team has the bandwidth and authority to maintain it properly, regardless of which direction the decision goes.
• What existing systems does support need to talk to, and how mature are the integration points on those systems. A custom build often looks more appealing when the surrounding systems are themselves fragile or undocumented, because at least a custom tool can be built to work around their quirks directly — but that’s usually treating a symptom rather than fixing the actual underlying problem.
• What does the business actually track today, even informally, about support performance. If nobody can tell me current average resolution time or ticket volume by category, that’s usually a sign the organization isn’t ready to have a serious platform conversation yet, because they won’t be able to tell in six months whether the new system improved anything.

The order matters more than the answer

I’ve come to believe that companies who ask “what does our process actually need to do” before they ask “which platform should we buy” tend to make good decisions almost regardless of which platform they land on. Companies who skip that step and go straight to comparing Service Cloud against a proposed custom build tend to make expensive decisions in either direction, because they’re optimizing for a feature list instead of a business reality they haven’t actually mapped yet.

If you’re standing at this decision point right now, my honest advice is to resist the pull toward the platform conversation for another two or three weeks. Sit with your support team. Ask them about the cases that made them want to escalate, the workarounds they’ve built that nobody officially sanctioned, and the moments the current process genuinely let a customer down. That conversation will tell you more about which direction to go than any vendor comparison sheet will, and it’ll make whichever platform you eventually choose actually fit the business instead of the other way around.