By Artem Korsakov ·
A warranty repair through a partner consists of stages, each handled by a different participant. If these stages are not described, requests get lost at the handoffs: diagnostics are performed but the manufacturer is unaware of them; work is completed but not accepted by the client; settlement with the partner occurs twice or not at all. Let’s review the process from initial contact to final settlement and note what needs to be verified at each step.
Contact and Warranty Verification
The request begins with a client’s inquiry. The minimum data set includes: equipment type, serial number, address, fault description, and contact details. The inquiry date is recorded automatically.
In the process shown here, warranty validity is checked as of the inquiry date. For example, a client contacts support on the last day of the warranty period, but the service visit is scheduled for a week later. In the demo, the warranty is considered valid; however, the cause of failure and other warranty conditions must be verified separately. For a production system, the start date and verification procedure should be derived from the specific warranty terms.
If the warranty has expired, the request continues as a paid service. The client must be informed of this immediately, before dispatch.
At this same step, it is useful to verify who commissioned the equipment installation. If manufacturer conditions require commissioning by an authorized partner, and it was performed by someone else, this should be determined before diagnostics. Otherwise, a warranty dispute will arise only after the work has already been completed.
Assigning a Partner
A partner is selected based on three conditions: do they operate in the region, do they have the qualifications for this equipment, and are there available technicians? If any one of these conditions is not met, the assignment fails.
A dispatcher may assign a partner manually, but the reason for selection must be recorded. Six months later, these reasons reveal which regions are covered by a single partner, where qualifications are lacking, and who is overburdened. This data informs network development; otherwise, it is lost in phone calls.
An assigned partner sees only their own requests. Requests from other partners, their clients, and terms are inaccessible to them. This ensures confidentiality between partners, allowing each to work with their own list without unnecessary noise.
Diagnostics and Replacement Request
A partner’s engineer arrives on-site and records the results: cause of failure, required work, and parts for replacement. This often occurs in technical rooms without connectivity, so it is important for field staff to have mobile application operation offline with subsequent synchronization. Such capabilities are available in ready-made service systems.
The replacement request lists parts individually. The manufacturer decides on each part separately.
Manufacturer Decision and Paid Portion
The manufacturer may approve everything, nothing, or a portion. A typical mixed case: a valve fails under warranty, while a heat exchanger clog is due to water quality. The valve is replaced at the manufacturer's expense. Flushing can be offered to the client as a paid service.
Sequence is important here. The warranty portion does not depend on the client’s decision regarding paid services: if the client declines flushing, the valve is still replaced. The paid estimate includes only what the manufacturer rejected, and it is accepted by the client separately. A rejection without reason from the manufacturer cannot be accepted; otherwise, the partner will not be able to explain to the client why the work is paid.
Подпись: Illustrative example. The warranty portion does not depend on the client’s decision regarding paid services.
It is also necessary to determine what happens with diagnostics if the case is entirely non-warranty and the client refuses paid work. The visit occurred, the engineer spent time. Who pays for it: the client, the manufacturer, or does the partner absorb the cost? The answer depends on network contracts, but the client must know this before dispatch.
Work, Acceptance, and Settlement
After decisions are made, the partner performs the work and closes it with client acceptance. Without acceptance, the request is not considered completed, and settlement does not begin.
Settlement with the partner consists of bases: warranty diagnostics, warranty work, and a share of the paid portion, if provided by contract. Each base is charged once. Duplicate settlement for the same request must be blocked; otherwise, reconciliation over a quarter will reveal double charges.
The client receives an act with their portion: what was done under warranty, and what is at their expense. The partner’s remuneration does not appear in the client act.
Подпись: Educational amounts and rates. The partner's share of the paid portion is taken as 80% for illustration.
Request accounting, assignment, and control of field work are covered by ready-made service systems. It is additionally necessary to verify whether they support mixed decisions per part and settlement with external partners according to your rules.
Stage Checklist
Go through the last complex request and answer:
- Is the inquiry date recorded separately from the dispatch date?
- Can you see why exactly this partner was assigned?
- Does diagnostics have a list of parts, or only text?
- Did the manufacturer decide on each part?
- Did the client know about the paid portion before work began?
- Is there a client signature of acceptance?
- Can it be proven that the partner was not paid twice?
Each "no" indicates a stage where a request may stall or lead to a dispute. Improvements should begin with the earliest such stage: an error at the beginning of the chain is carried over into all subsequent steps.
In the demo scenario, you can trace the entire chain: warranty, partner, diagnostics, approval, acceptance, and remuneration, with a block on duplicate settlement.
Related article: When a service network is sufficient with a request system, and when a partner portal is needed.
Sources and Example Boundaries
Sources confirm the described functions of ready products, not demand or return on investment for proprietary development. Scenarios and amounts are educational. Demonstrations work with fictional data; real integrations, AI, payments, and external publication are not included.