Trudian
Channel support operations

Distributor After-Sales, Warranty and Spare-Parts Framework

Set the support handover before the first shipment. Name the case owner, required diagnostic evidence, first-line checks, engineering escalation route and approval authority for parts, returns and commercial disposition.

6support stages
4case classes
5controlled records
Commercial and technical scope

Warranty coverage does not define the support process.

The warranty states what may be covered. The support process states who receives the case, which checks must be completed, who authorizes the remedy and what evidence closes the record. Both belong in the agreed product programme.

Close these points before the first purchase order. Identify the covered models, coverage start date, exclusions, diagnostic ownership, RMA authority, return or replacement route, freight responsibility, spare-parts supply, firmware escalation and minimum case record. Put product-specific warranty periods and response commitments in the quotation or signed agreement.
TRIAGE

Locate the fault domain

Separate door preparation, power, network, configuration and user errors from hardware, firmware, application and cloud faults.

CONTAINMENT

Keep the opening operational

Record the mechanical override, alternative credential, temporary unit and site procedure used to maintain safe access.

CORRECTIVE ACTION

Prevent repeat failures

Group cases by model, batch, hardware revision, firmware and operating condition; link each confirmed cause to containment and permanent action.

Responsibility matrix

Give each support stage one accountable owner.

The split between distributor and manufacturer depends on local capability and the commercial agreement. The matrix below identifies the ownership decisions that must be recorded.

StageDistributor / local partnerManufacturer / development teamClosure evidence
Case intakeRecord the customer, site, model, serial number, symptom, operational impact and immediate safety concernIssue the case template, evidence requirements and escalation channelA complete case record with a reproducible or clearly bounded symptom
First-line diagnosisCheck installation, power, network, door fit, configuration and approved recovery stepsMaintain model-specific diagnostics, current documentation and known-issue guidanceTest results, photos or video, logs and configuration record
Technical escalationSubmit the required evidence, preserve the installed state and update the customerReview the hardware, firmware, application or cloud evidence and define controlled testsFault domain, next action, case owner and review date
Commercial dispositionConfirm local stock, customer handling and the applicable agreementAuthorize the remedy against the product-specific commercial termsRMA number, parts issue, credit, replacement or documented exclusion
Corrective actionApply the field remedy and monitor the affected installed baseControl the engineering change, affected scope, release notes and validationEffectiveness check against the original failure mode
ClosureRecord the deployed remedy and customer acceptanceClose the technical record and retain configuration traceabilityFinal status, closure date, deployed version and residual risk
Commercial boundaryNo universal warranty period, free-spares ratio, response SLA or freight policy is stated here. These terms depend on the product, destination market, support model and signed agreement.
Case classification

Classify cases by operational impact.

Define severity levels and response targets in the commercial agreement. These four classes determine the first action and evidence required for escalation; they are not published service levels.

Case classTypical impactFirst actionEvidence for escalation
Safety or access continuityUnsafe operation, trapped or uncontrolled access, or no approved entry methodApply the documented site safety and fallback procedureImmediate impact statement, affected openings, configuration and containment
Repeated or multi-site failureThe same symptom appears across units, batches, sites or one firmware releasePreserve affected versions and isolate the common conditionUnit list, batch or serial range, recurrence rate and comparison data
Single-unit functional faultOne lock, intercom, gateway or application instance is affectedComplete installation and configuration checks before replacing partsReproduction steps, photos or video, logs, wiring and swap-test result
Configuration or documentationAn incorrect setting, unclear installation step or missing compatibility noteCorrect the field instruction and verify the installed configurationDocument revision, corrected setting and customer confirmation
Controlled records

Keep five records for the installed base.

The service history must survive staff changes, messaging-platform changes and replacement of local service providers. Store it in a controlled record, not an individual's inbox.

Installed-base register

Site, controlled opening, model, serial or batch, hardware and firmware revision, application or platform, installation date and local service owner.

Case intake record

Observed symptom, reproduction steps, photos or video, wiring, network, configuration and immediate containment.

Spare-parts map

Replaceable assemblies, compatible model revisions, storage conditions, diagnostic purpose and replenishment route.

Firmware register

Released version, target hardware, change reason, known limitations, rollback position and deployment approval.

Corrective-action log

Confirmed cause, affected scope, containment, permanent action, validation result and recurrence monitoring.

Support scope review

Define the handover before the first shipment.

Send the destination market, proposed product range, local diagnostic capability, forecast installed base and service model. We will identify first-line ownership, escalation evidence, spare-parts responsibilities and commercial terms that still require agreement.