# 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.

- Source: https://synconai.com/case-studies/equipment-company-sales-parts-service-one-record
- Publisher: SynconAI (https://synconai.com)
- Type: Case study
- Evidence: Real delivery work, written up by industry. The client’s identity and the detail of their systems stay private.
- Organisation: A manufacturer and distributor of equipment and parts selling and supporting products to trade and commercial customers
- Industry: Manufacturing
- Products: Sales Cloud, Case Management, Products and Price Books, Salesforce Platform, Flow
- Service: Salesforce Sales Cloud Consulting (https://synconai.com/salesforce-sales-cloud-consulting)
- Reading time: 6 minutes

## In short

We built a single Salesforce org for an equipment manufacturer and distributor. Cleaned customer data, segment-aware leads, accounts, contacts and opportunities, a product catalog with price books, and cases for equipment service and parts orders now sit together, so sales and support see each customer’s whole history in one place.

## Key points

- Clean the data before you configure. Duplicate customer records are the fastest way to lose trust in a new CRM.
- Make the dimensions your teams care about fields, then use them everywhere: filters, list views, layouts and reports. One org can serve different parts of a business without becoming several orgs.
- Service is part of the customer relationship. Linking parts and service cases to the same account as sales shows who is a growing customer and who is a struggling one.
- Assess sharing rules early. Whether teams may see each other’s customers is a business decision that shapes the license and the configuration.

## 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.

## Questions

### Why one org instead of several?

Many customers buy more than one product line, and the same team often supports several. One org gives one customer record, one product catalog and one process, while fields, filters and list views keep each team’s work easy to focus on. Separate orgs would have duplicated customers and doubled the administration.

### Can teams be kept from seeing each other’s customers?

We assessed visibility restrictions with the business. Stronger sharing controls of that kind depend on the Salesforce edition, so a planned upgrade is part of the roadmap to support them along with more advanced capabilities.

### How are parts orders handled?

Parts orders and equipment service requests are both handled as cases, with issue types, statuses, attachments, customer correspondence and follow-up tasks. They sit on the same account as the customer’s sales history, so a salesperson can see an open service issue before calling.

---

SynconAI. https://synconai.com/case-studies/equipment-company-sales-parts-service-one-record