Do You Actually Need Service Cloud?

Every few months someone asks us to quote for a Salesforce licence upgrade they do not need. We say so, and the engagement gets smaller. This is an article about why we keep doing that.

The specific version that comes up most often is Service Cloud. A company has been running Sales Cloud for a year or two, a support requirement appears, and the obvious next step looks like buying the product with "Service" in the name. It is a reasonable assumption. It is often wrong, and it is expensive to be wrong about, because a licence is not a one-off purchase; it is a line in the budget for as long as you keep it.

Four rungs, in order

We work down a ladder, and only move to the next rung when the one above genuinely cannot carry the requirement.

1. Configuration. Settings, objects, fields, page layouts, permissions. Things Salesforce already does, switched on.
2. No-code. Assignment rules, auto-response rules, validation, approval processes, report types.
3. Low-code. Flow. Real logic, built in a supported tool, visible to anyone who opens it.
4. Code. Apex, Lightning Web Components, custom integration.

Nothing about this is original; it is close to what Salesforce itself recommends. What is less common is treating it as a rule you have to argue your way past, rather than a preference you abandon the moment something is slightly awkward.

What each rung down actually costs

The reason to stay high on the ladder is not that configuration is quicker to build. Sometimes it is not. The reason is what each rung costs you for the rest of the system's life.

Who can change it. A field and an assignment rule can be changed by an administrator on a Tuesday afternoon. A Flow can be changed by an administrator who is confident with Flow. Apex needs a developer, a sandbox, tests, and a deployment. The higher the rung, the more people in your own organisation can maintain it, which is another way of saying the less dependent you are on whoever built it.

What happens at release time. Salesforce upgrades three times a year whether you are ready or not. Configuration and no-code move with the platform. Code is yours to keep working. Every custom class is a small standing obligation you have taken on, and the bill arrives on someone else's schedule.

What it takes to prove it still works. Standard features are tested by Salesforce. Your Apex is tested by your test classes, which someone has to write, maintain, and actually make meaningful rather than merely passing.

What it looks like to the next person. This is the one that decides whether an org is still workable in five years. A Flow has a diagram. A trigger has whatever the author remembered to write in a comment. We have spent entire assessments reconstructing what a previous partner's code was for, and the honest finding is usually that a Flow would have done the same job and explained itself.

None of these show up in an implementation estimate. All of them show up later.

A support desk without a support licence

A recent example, with the client's details left out.

They had been on Salesforce Enterprise Edition for about a year, sales only, with accounts, contacts, opportunities and quoting. They were launching a new self-service product, which meant that for the first time their customers would need somewhere to send problems. Nothing existed for it. The assumption in the room was that this meant buying Service Cloud.

We looked at what they actually needed: an address customers could email, tickets landing in a queue, an owner responsible for each one, an acknowledgement to the customer, a way to see what was open and how long it had been open, and visibility of it all from the account.

Every one of those is in Enterprise Edition already. Cases are a standard object. Email-to-Case, case assignment rules and auto-response rules come with Sales Cloud; they are not gated behind a Service Cloud licence, which is not widely known and is worth checking against your own org before anyone signs anything.

So the build was: switch on Email-to-Case, have their IT forward one address to it, one assignment rule routing to a support owner, one auto-response template, one new lookup field on the account for that owner, one Flow to move a case between four stages as the customer and the agent replied, and a home page showing what was open and how long it had been sitting there.

One custom field. One Flow. No new licence, and no code.

We should be straightforward about what that cost us. A licence upgrade with a Service Cloud implementation behind it is a considerably larger engagement than a few days of configuration. Recommending the smaller thing is not generosity; it is that we would rather be the firm you call in three years than the one you found expensive in year one.

What Service Cloud genuinely adds

It would be dishonest to write the above without the other half, because there are real reasons to buy it, and a consultant who tells you that you never need the upgrade is as unreliable as one who always does.

Service Cloud adds things Sales Cloud does not have at all: entitlements and milestones, when you owe customers a contractually defined response time and have to evidence it; service contracts and work orders; Omni-Channel, when work has to be distributed across a pool of agents by capacity rather than assigned by rule; Knowledge, as a managed article lifecycle rather than a folder of documents; the service console, when an agent handles enough cases per day that layout efficiency is a genuine cost; telephony integration; and the bots and messaging channels layered on top.

Read that list against your actual situation. If you are running a contact centre, several of those are not optional and the ladder argument does not apply: start at the right rung. If you are a company whose customers occasionally email with a problem, none of them are load-bearing yet.

How to tell you have actually hit the limit

Three questions, in this order.

Is this requirement real, or is it a preference stated confidently? A surprising number of things that appear to need code turn out to be things one person wants arranged differently. The ladder is not the enemy here; unexamined requirements are.

Have we tried the rung above properly, or just quickly? "Flow can't do that" is true far less often than it is said. It is worth an hour of someone who knows Flow well before it is worth a week of someone writing Apex.

If we go down a rung, who maintains it, and what happens when they leave? If there is no answer to the second half of that question, the requirement is not yet ready to be built, whatever it is built in.

The point is not to be cheap

Staying high on the ladder is not about spending less. It is about how much of your system remains changeable by your own people, without a release, a developer, or a phone call to us.

That is also the honest reason we argue for it against our own commercial interest. The orgs we are called in to rescue are almost never the ones where somebody chose the simple option. They are the ones where every requirement, for years, was met one rung lower than it needed to be, and each of those decisions was completely reasonable on the day it was taken.