Sales, Products and Service History in One Org for a Multi-Brand Equipment Company
An equipment manufacturer and distributor sold and serviced several brands, and its sales, parts orders and service requests lived in scattered records. We built one multi-brand Salesforce org with brand-aware sales, a product catalog and price books, and case handling for service and parts.
ManufacturingAt the base is clean customer data: accounts, contacts and leads, each tagged with the brand it relates to. Above it sits the product layer, a catalog with price books and imported product data, so every quote and parts order uses the same products. The sales layer runs leads to opportunities per brand, with brand filtering, list views and consistent layouts. The service layer handles equipment service and parts orders as cases with issue types, statuses, attachments, correspondence and follow-up tasks. Because sales and service sit on the same account, every team sees the whole customer.
Service
- Service cases
- Parts order cases
- Issue types and statuses
- Follow-up tasks
Every service request has an owner and a history.
Sales
- Leads by brand
- Opportunities
- Brand filtering
- List views
Each brand sells from the same process.
Products
- Product catalog
- Price books
- Imported product data
One catalog behind quotes and parts orders.
Customers
- Accounts
- Contacts
- Brand tags
- Cleaned data
One customer record, whichever brand they buy.
Delivered engagement. The client is not named publicly; the industry, products and outcomes are theirs.
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 across several brands, 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 under different brands. 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, multi-brand 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 multi-brand customer model
We started by cleaning the existing data and agreeing how brands would be represented. Leads, accounts, contacts and opportunities were configured for multiple brands, so each record carries the brand it relates to while the customer remains one record. Duplicates created by brand-by-brand recordkeeping were addressed so the new system started clean.
02 Brand-aware sales views
Brand filtering, list views and consistent Lightning record layouts let each brand team focus on its own pipeline without losing sight of the wider customer. The same sales process runs for every brand, and managers can compare brands 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 brands may need their customer information kept separate from others. We assessed brand-specific 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 across every brand the customer buys. 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 multi-brand businesses need one view of the customer
Companies with several brands are tempted to run each brand as its own world. It feels simpler for each brand 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 brand-aware configuration avoids that. Brand stays visible everywhere it matters, in filters, views, layouts and reports, so brand 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 across brands, 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 brand 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 brand 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, many brands. 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 brand-level sharing that the current setup could not enforce, we assessed it and planned the upgrade that supports it.
What changed
| Area | Before | After |
|---|---|---|
| Customer records | Duplicated across brands | One cleaned customer model with brand tags |
| Sales | Brand pipelines in separate places | Brand-aware 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 |
| Brand 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 brand 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 across brands, and choose your edition to match. Done in that order, one org can serve several brands without losing what makes each of them distinct.
