The customer's installed base
The installed base is the list of machines a customer actually owns. Once it exists, the shop stops being a catalogue and becomes their machines with their parts — which is the difference between a spare parts shop that gets used and one that gets bookmarked and forgotten.
Why this is worth the effort
A buyer with three registered machines sees a different shop. "My machines" is the entry point instead of a search box. The parts list they land on is the one for their serial, not for the current model. A part that does not fit any of their machines can be flagged before checkout. Their last order for that machine is one click away, which matters because spare parts are bought repeatedly — the seal that failed this year is the seal that fails next year.
It also changes what you can do proactively. When 4711-A is superseded, you
can tell exactly which customers have machines containing it. When a service
interval comes round, you know whose. That is the bridge from parts shop to
customer portal.
1. Decide what a registered machine is
One record per physical machine, not per model. It carries:
| Field | Example | Why |
|---|---|---|
| Serial number | FS200-2014-0871 | The identity. Unique, permanent |
| Machine / series | FS-200 | Which parts lists apply |
| Owning organization | Müller Abfüllt GmbH | Who may see it |
| Location / hall | Werk 2, Linie 3 | Customers with 40 machines need this |
| Customer's own name for it | "Linie 3 alt" | They will search by this, not by your serial |
| Commissioned on | 2014-06-11 | Warranty, service intervals |
| Build configuration | Rev C dosing head | Which BOM revision applies |
The customer's own designation is the field teams forget and buyers use most. A
maintenance manager thinks in "Linie 3", never in FS200-2014-0871.
2. Decide how machines get registered
Three routes, and most companies end up using all three.
Self-registration by serial. The buyer types the serial in the portal, you resolve it against your build records, and it appears in their list. The best route, and it needs the serial-number resolution described in How buyers identify a spare part. Show a photo of where the type plate is, and accept the serial in every format anyone writes it.
Derived from order history. If your ERP knows which machine went to which customer, seed the installed base from it. This is the fastest way to a useful list on day one, and it is usually incomplete — machines get resold, moved between plants, and bought second-hand.
Entered by your service organisation. Your technicians know exactly which machines stand where, because they service them. Give them a way to add one, and the list becomes accurate in the accounts that matter most.
3. Decide who may see what
A registered machine belongs to an organization, not to a person. The maintenance technician who registered it leaves; the machine stays. Contacts of the organization inherit access according to their role — see Contacts and roles.
Two edge cases to settle before launch, because both will happen:
- A machine is sold on. Ownership transfers. Decide who may do that and what happens to the service history — usually the machine moves and the history does not.
- A multi-site customer. Machines belong to a location within the organization, and a plant manager should see their own hall rather than all forty machines in the group.
4. Connect it to the parts list
The installed base is only useful when it resolves. Registering a machine must produce, in one click:
- The parts list for that serial — the BOM revision valid for its build, not the current model's.
- The drawings for that revision.
- Their prices and current availability, per Contract prices for a customer.
- Their order history for that machine — what they bought for it before.
If step 1 falls back to the current model's parts list, you have built a convenience feature and a wrong-part generator. Where the serial cannot be resolved to a build, say so on the page and route to a person.
How this works in the Revenue Cloud today
What you can build now, and what it gets you:
- Machines as catalogue objects — reference records or products, per Compatibility and fits-with. Do this regardless; it is the prerequisite for every version of the feature.
- Organizations and contacts are real, and so is the role model that decides who sees what — Organizations.
- Order history per organization already answers "what did they buy for this
machine" if the order lines carry the machine reference. Put the serial on the
order line as a reference, or in the line's
user_datafield, at the point of ordering, and the history becomes machine-aware without any new entity. - Customer activity records events against a contact and an organization, which is where a service visit or a commissioning date can live in the meantime — Customer activity.
- Order lists give a buyer a saved, named list of the parts for one machine, which is a usable stand-in for "my machines" while the real thing is built — Order lists.
What to check
- A registered machine resolves to a parts list, and it is the right revision for its serial.
- A serial that cannot be resolved fails visibly, with a route to a person — never silently onto the current model.
- Access follows the organization. Log in as a second contact of the same customer and confirm the machines are there.
- Nothing is gated. Log out entirely and confirm every identification path still works.
Next
- The buyer's path: find a spare part — the installed base in use.
- Run a customer portal — where this leads.