Case study · Service Cloud for an insurance agency
From one Salesforce user to 35 in a year.
Every client email a case, nothing lost in an inbox.
A commercial trucking insurance agency in South Carolina ran client service from shared inboxes. I built Service Cloud around how the agency actually works: every email a case, the request type read from the message, one owner per case, policy changes that cannot skip a step. Applied Epic stayed the policy system.
This is for you if your agency answers certificate requests, endorsements and quotes by email and nobody can say who answered what.
February 2024 to January 2025, remote. The agency is not named and its case volumes are not published: a client’s data stays the client’s. Reviewed 27 October 2026.
What changed
What changed for the agency?
Before, a request belonged to whoever opened the email first. After, every request had an owner, a type and a clock, and a manager could see who was on what without asking. The same desk carried the agency from one user to 35 without a second rebuild.
1 → 35
active users in twelve months, every one of them working from the same queues
Every email
to the service addresses becomes a case the whole team can see, instead of waiting in a personal inbox
1 owner
per request, so a client gets one answer instead of two or none
Every request
timed in working hours, so staffing could be judged from measured time rather than impressions
Where it started
What was going wrong before?
Requests sat in an inbox until somebody saw them, and nobody could tell who had already answered. Each certificate was retyped by hand. A policy change had a dozen steps that lived in people's heads, and nothing stopped one from being skipped. Nobody could say how long anything took, so nobody could say whether the team needed another person.
What was built
Six changes, each one replacing a habit.
Every service email becomes a case in a queue
Mail to the service addresses lands as a case in a team queue. Spam is closed in one click and stays recoverable.
The request type is read from the email itself
Certificate of insurance, additional insured, loss payee or a combination, set from the sender and the wording, by rules stored as records.
One person takes a case, and only then can reply
An agent takes a case from a queue they belong to. Nobody outside the queue can grab it.
Time is counted in the agency's working hours
Four clocks per case, one of which stops while the case waits for the client.
A policy change cannot skip a step
Eleven stages from the request and down payment to the carrier's confirmation, premium finance and the notice to accounting. Each stage creates its tasks and cannot move while one is open.
Quotes compared across twelve coverage types
Auto liability, motor truck cargo, physical damage, general liability, bonds, cyber and six more, per carrier. The cheapest complete package is marked automatically.
The decisions that mattered
Which decisions are usually made the other way?
Three choices that are often made the other way, and what goes wrong when they are.
Taking a case instead of assigning it
The usual build assigns each email to a named person on arrival. It looks tidy and quietly loses work: the person is on leave, the request waits, and the client calls twice. Here nobody owns a case until they take it from the queue, and nobody can reply until they own it. At the volume an agency reaches, that rule is the difference between one answer and two.
Rules as records, not code
Carriers, brokers and the phrasing of requests change every month. If the classification lives in code, every new phrase waits for a developer and a deployment. Kept as records, the agency's administrator adds a row and the next email is sorted correctly.
Spam closed, never deleted
When a large share of the mail is spam, a filter will sooner or later catch a real client. Deleted, that request is gone and nobody knows. Closed as spam, it is one search away and can be reopened with its history intact.
The honest part
What would I do differently next time?
Looking back at the build, three things were missed. They are now the first week of every agency project.
Match brokers, banks and carriers from day one
Much of the service email came from brokers, lienholders and carriers, not from the insured. They were not in the system as contacts, so many requests landed on one catch-all account and client level reports stayed thin. Now I import the counterparties and their domains before the first email arrives.
A reply to a closed case keeps its client
When a client answered a closed request, a new case opened with the subject and the history but without the contact and the account. One more field mapping in the build would have closed it.
Do not store signature images
Email to case saves every inline image, so many stored files turned out to be logos and signature images. A filter on inline images from the first week keeps storage for documents that matter.
What agencies ask first
Three questions before you start
Do we have to replace or integrate Applied Epic?
No. Epic stayed the policy system throughout and there was no integration. Where a step needs Epic, the task tells the agent exactly what to enter there. An integration can come later, once the service desk works; it is not the first thing to build.
Can one person build this for a team of 35?
The build, from an empty org to production, was mine; the agency's staff ran the service. One builder works because everything that changes weekly, rules, queues and task lists, lives in records an administrator can edit, so the agency is not waiting on me for routine changes.
What happens when you are gone?
The same thing: the classification rules, queues and stage task lists are data, documented and editable by the agency's own administrator. What needs a developer is the logic that does not change month to month, and that is covered by tests.
For your agency
Which parts carry over to any P&C agency?
Four of the six: email to case with spam handled from the first day, the request type read from the message, one owner per case, and time measured in working hours. Certificates, endorsements, renewals and cancellations look the same in every commercial lines agency. The coverage list and the endorsement stages change with the book.
A quick test before anything else: take the last 100 emails in your service inbox and count the spam, the certificate requests, and the ones answered twice or not at all. Those three counts are the work that routing by hand costs you today.
“When we started, we had just one user in Salesforce. By the end of the year, that number had grown to 35 active users.” Head of Personnel Division, the agency.
The same service side for your agency is priced stage by stage on the insurance agency page: eleven stages, 770 to 1,025 hours, €50,050 to €66,625 for the year, starting with email to cases at 80 to 110 hours, €5,200 to €7,150.
Serhii Skrypnyk · Senior Salesforce Administrator · 7 Salesforce certifications · on the platform since 2018. Reviewed 27 October 2026.
Read next
The question that usually comes after this one.
Service Cloud Implementation Roadmap
Seven phases of a Service Cloud build in the order that keeps the cost down, and what each phase has to produce before the next one starts.
What Service Cloud Actually Costs a Year
Salesforce lists Service Cloud from €25 to €550 per user a month. Six things the list does not show decide what a year costs, and four of them can be changed.
Case: Community charity, United Kingdom
Three colour coded spreadsheets became one fundraising system, with every payment split across programmes and committee scoring inside Salesforce.