Most manufacturers treat post-delivery service as a different business than the one that sells the product. Sales uses Salesforce; Service uses a ticket queue; Field uses spreadsheets. When a customer calls about installation, a warranty claim, or an appointment, three teams check out three systems - and the customer waits while they argue about who owns the Asset.
This isn't a service problem. It's an architecture problem. Post-delivery service runs on one Salesforce chain: Customer Asset → Case → Work Order → Service Appointment for service work, or Customer Asset → Case → Claim Line Item with warranty rules applied for claims. Every record links to the Asset created when Transport status hits Confirmed. Break the chain and the customer repeats themselves to whoever picks up next.
The fix is a Service Cloud architecture that routes every customer to touch through structured Cases and resolves them through a Work Order with Field Service Lightning or a Claim with auto-calculated warranty amounts - owned by one team on one platform.
Here's how manufacturers manage installation, field service, and warranty claims in Salesforce without losing the customer between systems.
Five forces fragment post-delivery service in legacy setups:
Each gap hurts customer experience. Combined, they explain why the manufacturer with the best product gets the worst CSAT score in the segment.
The source pattern starts every service interaction with a Case linked to a Customer Asset. From there, two paths open. The first - installation, service, or demo - runs through Work Orders and Field Service Lightning.
A Case arrives via Customer, Email, Web, or Service Rep. The Service Rep identifies the affected Customer Asset (or Assets) and creates Case Line Items linking each Asset to the work needed.
Once classified as Service, Installation, or Demo, the Case spawns a Work Order. The Work Order carries the technical detail - parts needed, estimated duration, Work Plan - that the field team needs.
The Service Appointment is created from the Work Order with scheduling logic that respects Territory (geo-mapped from the Account) and Round Robin assignment within the qualified technician pool.
The Technician arrives, executes the Work Plan, captures a Service Report on the mobile app, and gets a Customer Signature. The Work Order moves to Completed; the Case closes.
The second outcome path - Claim - runs when the customer reports a defect or covered failure. The source pattern handles this with a structured Claim object instead of letting it leak into informal email approval.
When the Service Rep classifies the Case as a warranty claim, the system creates a Claim record linked to the Case, the Customer Asset(s), and the original Sales Order.
For every Customer Asset involved, the system creates a Claim Line Item. This unit-level granularity is what makes partial claim approval and parts-only coverage possible.
The system pulls warranty terms from the Asset record - Duration, Coverage tier (Parts, Labor, Expense) - and applies them to each Line Item. Coverage that's expired, partially applicable, or excluded gets flagged for review.
The Claim amount is calculated against the rules in real time. There's no "let me check with finance" pause; the system either auto-approves within policy or escalates outside policy to a defined approver.
Two scheduling rules sit underneath every Service Appointment in the source pattern. Getting this right is what stops the wrong tech from arriving on the wrong day.
The customer's Account record carries a geographic location. Territory rules map that location to a service Territory boundary. The Service Appointment is constrained to technicians who serve that Territory - no cross-territory rolls.
Within the Territory, the Round Robin assignment cycles through qualified technicians based on skills, certifications, current load, and SLA priority. The next Appointment goes to the next eligible tech - not the loudest one or the manager's favorite.
If the Work Order requires a specific skill - HVAC refrigerant certification, heavy-equipment lift license - the assignment narrows to techs with the matching skill before Round Robin runs. Round Robin is the secondary sort, not the primary.
Five validation rules keep the chain from breaking under pressure.
Block Case save without at least one Customer Asset linked through a Case Line Item. Generic Account-level Cases lose the warranty and service context.
Block Work Order activation if no Service Appointment is scheduled within the customer's SLA window. The "we'll figure out scheduling later" path is what creates the missed-appointment customer call.
Enforce that the number of Claim Line Items matches the number of Assets in the Claim. Aggregated Claims lose per-unit visibility that warranty audits depend on.
Block Claim approval if Duration and Parts/Labor/Expense coverage rules haven't been evaluated against the Asset's warranty terms. No claim closes outside the rules.
Block Work Order Completed status until both Service Report and Customer Signature are captured. Without these, the audit trail breaks and warranty defence weakens.
Salesforce identifies the Customer Asset through one or more inputs - the customer's phone or email matched against Account records, an Asset serial number provided by the customer, or a manual lookup by the Service Rep. Once identified, Case Line Items connect the Case to each affected Asset, preserving unit-level service history.
A Case is the customer-facing record of the issue or request. A Work Order is the operational task that resolves the Case - parts, Work Plan, estimated duration. A Service Appointment is the calendared visit by a specific Technician that fulfils the Work Order. One Case can spawn multiple Work Orders; one Work Order can require multiple Service Appointments.
When a Case converts to a Claim, the system creates a Claim Line Item per Customer Asset, pulls warranty terms from the Asset (Duration plus Parts/Labor/Expense coverage), evaluates whether the claim falls within those terms, and calculates the eligible amount dynamically. Auto-approvals run within policy; out-of-policy claims escalate to a defined approver.
The assignment runs in two layers. Territory rules - derived from the Account's geographic location - narrow the pool to technicians who serve that area. Round Robin then cycles through that pool, weighted by current load and skill match. Skills override Round Robin when the work requires a certification.
The three-teams-three-systems chaos in the opening scene isn't an outlier. Across manufacturing, the gap between a customer call and resolution shows up as Account-level routing, manual warranty calculations, and field technicians arriving without context. The architecture to close it isn't complicated. It just has to anchor on the Customer Asset.
The Salesforce Manufacturing Cloud Starter is the product Minuscule built for manufacturers who don't want their next service call to take three departments. It covers Cases linked to Customer Assets, Case → Work Order → Service Appointment with Territory and Round Robin dispatch, Service Report and Customer Signature capture, and Case → Claim → Claim Line Item with dynamic warranty calculation - engineered into one production-ready Service Cloud + FSL platform. Manufacturers running it resolve service calls without escalation.
Connect with our enterprise architecture team and we'll walk through the Manufacturing Cloud Starter and the post-delivery service architecture for your operations.
You've seen what's possible. Now, let's make it happen for your business. Whether you need an end-to-end Salesforce solution, a complex integration, or ongoing managed services, our team is ready to deliver.
Schedule a Free Strategic Call
