How connected-device teams cut support cases by 93 percent on Salesforce

Short answer: connected-device teams do not cut case volume by staffing support harder. They cut it by letting the device report its own fault, resolving most of those reports automatically, and reserving a Salesforce case for the exception that genuinely needs a person. On a programme we delivered for ASSA ABLOY (FocusCura and Phoniro), that model took weekly support cases from roughly 3,000 to 350, a 93 percent reduction, across 11,000 connected devices and up to 2.5 million events per week in three markets, with no added support staff.

What is telemetry-driven service?

Telemetry-driven service is a model where the asset opens the conversation instead of the customer. Device events flow into the CRM continuously, get matched to an asset and an entitlement, and trigger a resolution path before anyone picks up a phone.

Three levels are worth separating, because most teams collapse them into one word:

• Reactive. The customer notices the fault and calls. Every incident costs an agent.
• Proactive. The platform notices first and warns someone. Better for the customer, but a human still handles it.
• Autonomous triage. The platform notices, classifies and remediates. A case exists only when the remediation fails.

Almost all of the 93 percent lives in the jump from proactive to autonomous. Proactive alerting on its own tends to increase workload, because you have added a queue without removing the old one.

How does a device event become a resolved incident without a case?

1. Ingest at event rate, not at case rate. Millions of weekly events belong in a data layer built for volume. Salesforce now calls that layer Data 360, the renamed Data Cloud that sits under Agentforce 360.
2. Resolve identity before anything else. Every event is matched to an asset record, its location, its customer and its entitlement. An event that cannot be attributed is an integration defect, not an incident.
3. Classify against a rule set. Signature patterns map to known fault classes with a known remedy: reboot, re-pair, firmware push, consumable order, dispatch.
4. Remediate automatically where the remedy is deterministic. Most field faults are a small set of repeats. Automate the repeats first and the long tail never becomes urgent.
5. Create a case only on escalation. The case is opened after automation has tried and failed, and it carries the full attempt history so the agent does not start from zero.
6. Dispatch through Field Service only when someone must physically attend, with the part and the diagnosis already attached to the work order.

Which device events deserve a case at all?

This is the question most published guidance on connected service skips, and it is where the number actually comes from. A case is a unit of human work, not a unit of telemetry. Sort every event signature into one of three buckets before you build anything:

• Noise. Transient, self-correcting, no customer impact. Suppress it and count it. Never surface it.
• Deterministic. Known fault, known fix, no judgement required. Automate end to end.
• Ambiguous. Needs a person, a decision or a visit. This is the only bucket allowed to create a case.

Teams that skip this exercise end up with proactive alerting that generates more tickets than the old phone line did.

What did the 93 percent look like in practice?

ASSA ABLOY's connected-care business ran a fleet of 11,000 devices producing up to 2.5 million events a week across three markets. Support was absorbing around 3,000 cases a week, and the obvious answer on the table was to hire.

Instead the telemetry was routed into Service Cloud through an autonomous triage layer, and the fleet began resolving itself. Weekly cases settled at about 350. Support headcount did not move.

Two details matter more than the headline:

• The cases that remain are harder, and that is correct. What is left is the ambiguous bucket. Expect average handle time per case to rise while total service cost falls, and have that conversation with your service director before go-live, not after.
• Nothing was rebuilt per market. The device-to-Service-Cloud path shipped as a packaged 2GP component, which is what made the second and third market cheap rather than a repeat project.

What operating model makes the reduction stick?

Architecture gets you the first drop. The operating model is what stops it drifting back within two quarters.

• Treat the rule set as product, not configuration. Version it in source control, review it, deploy it through a pipeline, and be able to roll it back. Rules edited live in production always rot.
• Give service leadership ownership of thresholds. The people who feel the queue should be able to change what fires without waiting for a release.
• Measure cases per thousand devices, not cases. Absolute case count flatters you when the fleet is flat and punishes you when you win customers. The ratio is the only honest signal.
• Review the suppression list on a fixed cadence. Everything you silenced is a bet, and firmware changes turn good bets bad.
• Keep one asset record. The moment device state lives in two systems, agents stop trusting the automation and start opening cases defensively.

Where does this usually go wrong?

• Alerting without remediation. A dashboard of red tiles is a new job, not a saved one.
• Storing every raw event as a platform record. Event volume and case volume are different orders of magnitude and belong in different places.
• No entitlement in the path. Without contract context the automation cannot decide who pays for the visit, so it escalates everything to be safe.

FAQ

Do you need Data 360 to start?

Not for a pilot. You need a volume data layer when event rate outgrows what your core org should be storing, which for most fleets happens well before the millions-per-week mark.

Does this replace Field Service?

No. It reduces how many dispatches happen and improves the ones that remain, because the diagnosis and the part are known before the van leaves.

How quickly does case volume move?

The first measurable drop comes from the deterministic bucket, which is also the smallest build. Sequence that first and you get proof before you get scope.

Will Agentforce do this out of the box?

Agentforce reasons over the context you give it. It does not invent your fault taxonomy, so the classification rules, asset data and entitlement model still have to exist underneath.

We build this pattern as Tekunda IoT Cloud: device events to autonomous triage on Service Cloud, Field Service dispatch, grounded in Data 360. If you run a connected fleet and your case queue grows with your install base, talk to us.