Product Parts (Spare Parts): What it is and how it works
Product Parts (also called spare parts) is a Claimlane capability that helps customers and support teams identify which specific part of a product is affected, instead of treating the entire product as “the item.”
This is especially useful when:
The product has many parts.
Only one part needs replacement.
Support teams need structured information to ship the correct part.
What “Product Parts” means in practice
A “part” is a specific component that belongs to a product, for example:
A screw kit
A handle
A panel
A wheel
A left or right component in an assembly
In a Product Parts flow, the goal is to capture the part the customer needs in a way that is easy for the customer to specify, and is clear and searchable for internal teams handling the ticket.
How the customer identifies the part (Self-Service Portal)
In Claimlane’s Self-Service Portal flow, the customer identifies the relevant part during ticket creation:
Using product documentation (PDF/assembly manuals)
PDF assembly guides can be made available so the customer can reference diagrams and identify the correct component.
Entering the part name
In a typical setup, the customer types the part name as free text in the Product Parts step.
The part the customer enters is what will initially appear on the ticket as the “Part.”
What happens after submission (internal handling)
Once the ticket is created, internal teams can use the part information to process the case.
A key element of Product Parts is that customer-entered parts can be validated and enriched:
A customer can submit an initial part name.
An agent can validate the input and add structured identifiers (for example SKU/item number), so future handling becomes faster and more consistent.
Over time, this supports building a more structured parts dataset, reducing repeat manual work.
Product ↔ Parts relationship (how parts are connected to products)
In some product data setups, the relationship between a product and its parts is defined in the product catalog data.
Example (Shopify):
The relationship between the product and its parts can be stored as a metafield on the product, containing a list of the associated parts.
This ensures that customers and agents see relevant parts for the relevant product, instead of searching through a global list.
Item numbers, SKUs, and identifiers (why they matter)
Many organizations do not want to rely on free-text part names internally, because spelling and naming will vary.
To support reliable internal operations (search, picking, fulfillment, reporting), parts can include identifiers such as:
Item number
SKU
EAN
Parent EAN (link back to the main product)
In at least one documented payload example, parts are represented as a productParts array that includes fields like itemNumber, ean, parentEan, sku, and quantity.
What the customer sees vs. what internal teams see
A common setup is:
Customer view: a simple part selection / entry experience (often without showing internal identifiers).
Internal view: structured fields such as item number or SKU to support searching and fulfillment.
This is important when companies want internal accuracy without exposing internal catalog codes to the customer.
Summary
Product Parts helps Claimlane users:
Collect which component is affected (not just which product).
Reduce back-and-forth on “which part do you mean?”
Support internal search and handling with structured identifiers over time.