Sales, parts and service on one customer record.
An equipment manufacturer and distributor had sales, parts orders and service requests in scattered records. SynconAI built one Salesforce org that keeps each customer’s whole history together, with focused views for each team and a single product catalog.
- 1org, one customer record
- 3strands on the record: sales, parts, service
- 1product catalog behind quotes and parts orders
ManufacturingHow it was built
Want the full story behind this case study?
The architecture, data model and delivery detail belong to our client, so we keep them private. Contact us to learn more about this case study, and an architect will walk you through how it was designed, delivered and what it changed, one to one.
Contact us to learn moreFree architect conversation
Learn more about this case study, with an architect.
Tell us a little about your business. We will walk you through how this solution was designed and delivered, what it changed, and how the same approach could work for you.
Real delivery work, written up by industry. The client’s identity and the detail of their systems stay private.
The starting position
Equipment businesses live on long relationships. A customer buys a machine, then needs parts, servicing and eventually a replacement. Over the years, the support relationship is often worth more than the original sale, and the companies that understand each customer's whole history sell and serve them better.
The company in this engagement manufactures and distributes equipment and parts, selling to trade and commercial customers and supporting what it sells. Its customer information was spread thin. Sales activity, parts orders and service requests sat in separate places, and the same customer could appear several times in different records. A salesperson preparing for a meeting could not easily see that the customer had an open service issue. A service coordinator could not see what the customer had recently bought. Product information was not held in one consistent catalog, so quotes and parts orders were assembled from different sources.
The goal was a structured CRM that brought sales, products, service and case history together, so every team saw the same customer.
What we built
01 Data cleanup and a single customer model
We started by cleaning the existing data and agreeing how customers and their relationships would be represented. Leads, accounts, contacts and opportunities were configured so each record carries the context the business needs while the customer remains one record. Duplicates created by fragmented recordkeeping were addressed so the new system started clean.
02 Focused sales views
Filtering, list views and consistent Lightning record layouts let each sales team focus on its own pipeline without losing sight of the wider customer. One sales process runs across the business, and managers can compare teams on the same measures.
03 Case handling for service and parts
Equipment service requests and parts orders are handled as cases. Each case carries an issue type and a status, holds attachments such as photos and documents, records the correspondence with the customer, and drives follow-up tasks so nothing stalls. Because cases sit on the same account as the sales history, support and sales work in the same customer context.
04 Products and price books
We imported product data, including a significant product range supplied as a structured data set, and built out the wider product catalog and price books. Quotes and parts orders now draw from one catalog with consistent pricing.
05 Visibility assessment and roadmap
Some parts of the business may need their customer information kept separate from others. We assessed visibility restrictions with the business and identified that stronger sharing controls, along with more advanced capabilities, depend on the Salesforce edition. A planned upgrade is part of the roadmap to support them. The upgrade is planned, not yet complete, and the current configuration is designed to carry forward into it.
A customer, seen from every side
A trade customer calls about a machine that has stopped working. The service coordinator opens a case, selects the issue type and attaches the photos the customer sends. Correspondence about the fault is recorded on the case, and a follow-up task makes sure someone checks back.
The parts needed for the repair are ordered as a related case, using products and prices from the same catalog. Meanwhile, the account manager responsible for the customer opens the account before a planned visit and sees the open service case, the parts order and the recent opportunities in one place. The visit starts with the service issue, not a sales pitch, and the customer notices.
When the customer later asks about replacing an older machine, the opportunity is created on the same account, with the service history in plain view. That history is often the best argument for the replacement.
Why one view of the customer matters
Companies with several teams or product lines are tempted to run each as its own world. It feels simpler for each team, and it can mirror how the business grew. The cost appears at the customer: the same organization is treated as several unrelated customers, contacted by several teams, and served without anyone seeing the full picture.
One org with well-designed configuration avoids that. The dimensions that matter to each team stay visible where they matter, in filters, views, layouts and reports, so teams keep their focus. Underneath, the customer is one record, the catalog is one catalog and the service history is one history. That is what lets the business spot a customer who is buying more, or one whose service problems are putting future sales at risk.
What good case handling looks like for equipment
Service requests for equipment have a shape of their own, and the case design reflects it.
The issue type matters from the first minute. A machine that will not start, a part that has worn out and a request for routine maintenance need different people and different urgency. Recording the issue type when the case is opened routes the request correctly and makes later reporting meaningful.
Evidence travels with the request. Customers describe faults with photos, serial numbers and documents. Attachments on the case keep that evidence in one place, so nobody has to ask the customer to send it again.
The conversation is part of the record. Correspondence with the customer is stored on the case. When a different coordinator picks it up, or the customer calls back, the full exchange is there.
Follow-up is scheduled, not remembered. Tasks attached to the case make sure someone checks that a part arrived or a repair worked. Requests that would otherwise stall in a busy week keep moving.
Statuses tell the truth. Clear statuses show at a glance which requests are new, in progress, waiting on parts or resolved. Managers can see where work is piling up without asking around.
How we delivered it, end to end
Clean first. Data cleanup and the customer model came before configuration, so the new views and processes were built on records people could trust.
Configure sales and service together. Leads, opportunities and cases were configured as parts of one customer story, not as separate projects.
Load the catalog. Product data and price books were imported and organized so quoting and parts ordering use one source.
Walk the business through it. We documented and demonstrated the configured case handling and sales views with the team, so the process was understood before it was relied on.
Plan the next step honestly. Visibility requirements were assessed and the upgrade was placed on the roadmap as a planned step, kept separate from what has been delivered. The engagement is ongoing.
The decisions that mattered
One customer, one record. Avoiding separate orgs or duplicate customer records was the foundation for everything else.
Cases for parts and service. Using cases gave every request an owner, a status and a history without building a custom tool.
Edition decisions made on evidence. Instead of promising sharing controls that the current setup could not enforce, we assessed the requirement and planned the upgrade that supports it.
What changed
| Area | Before | After |
|---|---|---|
| Customer records | Duplicated across separate records | One cleaned customer model |
| Sales | Pipelines in separate places | Leads and opportunities in one process |
| Service and parts | Scattered requests | Cases with issue types, statuses, attachments and tasks |
| Products | Assembled from different sources | One catalog with price books and imported product data |
| Customer context | Sales and service blind to each other | Both on the same account |
| Visibility | Unclear requirements | Assessed, with a planned upgrade on the roadmap |
What we would tell an equipment company starting this
Start with one customer record and a clear model, and clean your data before you configure anything. Put service and parts on the same account as sales, because that history is the most valuable thing your sales team can see. Then be precise about who needs to see what, and choose your edition to match. Done in that order, one org can serve a varied business without losing what makes each part of it distinct.
