I have lost count of the Service Cloud projects I have walked into mid-flight where the build was technically fine and the project was still in trouble. The org had cases, queues, an assignment rule or two, even a console layout. But the license count was 30% short, the status picklist had eleven values nobody could explain, and someone had built a custom Ticket__c object that quietly threw away Email-to-Case, Entitlements, and Omni-Channel routing. None of that is a coding mistake. Every one of those problems was set in motion during discovery, before anyone touched Setup.
That is the uncomfortable truth about Service Cloud: the expensive decisions are made early, in conversations, on whiteboards, and in a sizing spreadsheet. By the time you are clicking through field creation, the hard part is supposed to be over. So this piece is about the two things I treat as the foundation of any service implementation: running discovery that is actually service-specific, and translating what you learn into a process design and a case data model that will survive contact with real volume.
A recurring example throughout is a telco support org I will keep generic. It runs three shifts, supports internet, IPTV, cloud, and billing, has roughly fifty agents on the floor at peak, and handles several thousand cases a day across phone, email, and chat. It is a useful shape because it forces every decision discovery is supposed to surface.
Service discovery is not sales discovery wearing a different hat
The most common mistake I see from consultants crossing over from Sales Cloud is reaching for the same discovery template. It does not transfer. Sales discovery is about pipeline, opportunity stages, and forecast accuracy, and you mostly learn what you need from reps and sales managers in a couple of weeks. Service discovery is about case volume, channel mix, agent capacity, and SLAs, and you cannot get the real numbers from a manager's slide deck.
You have to interview a wider cast: the customer service manager who owns the business outcome, the team leads who actually know how escalation works day to day, three to five agents across different tiers, and, critically, the IT and telephony people who can tell you what CTI and integrations exist. Plan on four to eight weeks, not two to four. The single most valuable session is none of the interviews. It is sitting next to an agent for half a day watching them work, because agents almost never articulate their real pain in an interview. They will tell you the process is fine, then spend ninety seconds alt-tabbing between four systems to answer one question, and that is the thing you came to find.
The other half of discovery that gets skipped is measuring the current state independently. Do not trust declared volume. I have watched a client confidently state their daily case count and then discovered, from the CTI logs and a supervisor's manual export, that real volume was nearly double. If you size licenses off the optimistic number, you are buying short, and topping up mid-contract costs 10 to 15% more per seat. So you collect the boring numbers yourself: cases per day at peak, average, and off-peak; the split by channel and by product; growth over the last year; and the agent-side reality of shift patterns, shrinkage, and turnover.
Sizing is where discovery becomes money
Sizing is the deliverable that turns all that measurement into a license plan, and getting it wrong swings a budget by 20 to 40% in either direction. For the telco, the user math runs: roughly fifty concurrent agents at peak, plus supervisors, managers, and admins at another 10 to 20% on top, plus a 10 to 15% buffer for turnover and ramp-up. That buffer is not padding. It is the difference between onboarding a new hire next week and filing a mid-contract purchase order. Round up and buy the next sensible number of Service Cloud Enterprise seats.
Edition follows from need rather than headcount alone. Professional cannot carry the workflow and custom-app weight most real support orgs need, so for anything in the fifty-to-five-hundred-agent range Enterprise is the default; Unlimited earns its keep only above that or when you genuinely need the extra sandboxes. Then you walk the add-on list deliberately: Service Cloud Voice or a partner CTI if telephony lives in Salesforce, Digital Engagement for chat and messaging, Field Service if anyone goes onsite, and a data storage add-on once you do the retention math, because at several thousand cases a day kept for years you blow past the base allocation fast.
The pitfall I have personally been burned by is compliance. On a banking project I scoped the whole license plan, and only later did the compliance team mention they needed field history retained well beyond eighteen months, which meant Shield. That is a budget line you do not want to discover halfway through delivery. The lesson is permanent: talk to compliance in week one, not week six, and ask explicitly what they require for audit logging and retention.
Design the process as a swimlane, with the unhappy path included
Once I have the numbers, the first real design artifact is a swimlane diagram, one lane per actor: customer, tier 1 agent, tier 2 agent, supervisor, system, and field technician if relevant. Each step says who does what, and each arrow between lanes is a handoff. The reason this matters is that every one of those handoff arrows is a configuration decision in disguise. For the telco's "internet is down" flow, drawing it out immediately exposes the four things the build team has to wire up: the IVR-to-case integration, Omni-Channel routing, the Knowledge linkage on the case page, and the trigger that spins up a Field Service Work Order when remote troubleshooting fails.
Three antipatterns ruin these diagrams. The first is the spaghetti process, where arrows cross so densely no agent can follow it; if a flow runs past seven to nine steps, break it into sub-processes. The second is the system-centric view that reads "Case created, Status changed, Flow fired" with no human in sight, which tells you nothing about whether the experience is any good. The third, and most damaging after go-live, is mapping only the happy path. Exceptions are routinely a third of real case traffic, and if you have not designed for them you will be improvising support process live, in production. Always draw at least two paths.
The same discipline applies to case status, which is the spine of the whole process. Keep it to seven or eight values at most, because every status is one more picklist value an agent has to pick correctly, and a sprawling list just produces wrong selections and unreadable reports. Name statuses for the state of the case, never for the department holding it. "Status = Risk Team" looks tidy until the org renames that department and your picklist no longer matches reality; let the case Owner show who is working it. And reserve a "Waiting on Customer" status specifically so you can pause the SLA clock. Without it, an agent emails a customer, waits three days for a reply, and the SLA timer keeps ticking against a case nobody could have moved. Pair the statuses with a Path component so agents get a stepper with minimal required fields, and you will usually shave a minute or two off handle time just because nobody is hunting for the field they need to fill.
The data-model calls you cannot easily take back
Underneath the process sits the data model, and a few decisions here are genuinely hard to reverse. The core is the relationship between Account, Contact, and Case, with Case carrying lookups to both so that creating a case from a contact auto-populates the account. In a B2B shape the account is the customer company and contacts are its people. In B2C you are usually weighing Person Accounts, which fuse account and contact into one record.
That Person Account decision deserves real caution because once you enable it you cannot turn it off without a Salesforce Support request that is slow and may simply fail. So resolve the B2B-versus-B2C question before you flip the switch. A hospital network where every patient is an individual with no parent legal entity is a clean Person Account case. The telco is the instructive counterexample: even though it is mostly consumer, it also serves enterprise customers on the same org, and those need the standard Account-Contact separation, so the right call is to keep Person Accounts off and model individuals as an "Individual" account type with a contact.
Asset and Entitlement are the next two judgment calls. Use Asset when customers own something worth tracking by serial or contract, like the telco's modems and set-top boxes, so an agent can search by serial number and see that device's entire case history. Use an Entitlement Process when you have tiered SLAs to enforce, so a Gold customer's case automatically picks up the right first-response and resolution milestones and a supervisor can watch for breaches on a dashboard. Both are standard machinery you get for free, and rebuilding either by hand is wasted effort.
Which brings me to the most consequential restraint in the whole model: do not replace Case with a custom object. I have seen teams build Support_Ticket__c to feel in control, and in doing so throw away Email-to-Case, Web-to-Case, Omni-Channel, Entitlements, Path, and Milestones in one stroke. If you need to distinguish service types, that is exactly what record types are for. Custom objects earn their place when there is genuinely no standard equivalent, like a network "Outage" object that many cases can point back to, or a structured "Dispute Evidence" record on a banking case. They do not earn their place as a parallel universe for tickets.
The thread running through all of this is that the cheap moment to be right is the early one. Measuring volume yourself instead of trusting a number, drawing the exception path before it bites you, capping your statuses, and thinking twice before Person Accounts or a custom ticket object cost you days in discovery and save you months after go-live. Build is recoverable. These foundations, mostly, are not, so spend your scrutiny here.
Implementing or optimizing Service Cloud? Our Salesforce team runs discovery, designs the case process, and configures Service Cloud, Omni-Channel, and Knowledge on production engagements. Get in touch ->
See our full platform services for the stack we cover.
