Onsite Field Service Coordination

Summary

Onsite field-service coordination covers tickets where Support acts as the scheduling, documentation, logistics, and verification owner for a third-party or onsite technician visit or when remote troubleshooting/control is unavailable for a complex recovery (#43197, #42968).

Frequency

• 2 tickets currently cite this workflow (#43197, #42968).

Common Causes

1. New-system physical installation or complex local recovery requires onsite labor. The T.RAD North America workflow required server rack mounting, cabling, and boot verification by an onsite technician after shipment, while another case used an onsite technician as a one-time exception for Linux kernel/NVIDIA/display/WiFi recovery that the customer could not complete remotely (#43197, #42968).
2. Shipment and site readiness drive scheduling. Support tracked the system shipment, ETA, customer site contacts, onsite address, rack-mount documentation, and requested install date before the technician visit (#43197).
3. Technician availability and named-tech/customer-comfort constraints can shape scheduling. The initially scheduled technician had an emergency, requiring the install date/time to be rescheduled with the customer and site; another customer requested the same technician from a prior visit because they were uncomfortable with multiple strangers entering their home (#43197, #42968).

Diagnostic Steps

1. Confirm the onsite scope. Identify whether the visit is rack mounting, cabling, component swap, OS/application install, Linux driver/module recovery, validation, or another field-work-order task before dispatch (#43197, #42968).
2. Collect site prerequisites. Capture onsite address, primary contact, preferred date/time, shipment ETA/tracking, required documentation, and any site constraints before requesting the technician (#43197, #42968).
3. Plan for validation tools and access. Verify whether a crash cart, customer contact, management network, monitor/GPU display path, or other boot-verification path will be available; in #43197 there was no crash cart onsite, so final OS-boot validation depended on available site/customer assistance (#43197).
4. Maintain a reschedule path. If a technician emergency or availability issue occurs, ask for alternate dates/times and keep the field-service provider, customer, and Support owner aligned (#43197).

Solutions

1. Send installation documentation before the visit. Rack-mounting documentation was attached before the T.RAD onsite install was scheduled (#43197).
2. Tie dispatch timing to shipment delivery. Support tracked shipment ETA 2026-05-15 before requesting the technician for the following week (#43197).
3. Verify completion with concrete field notes. Completed visits should record the technician name and concrete result, whether rack-mount/cabling/OS boot verification (#43197) or Linux module/BIOS-setting remediation (#42968).
4. Close with a field service report. A field service report or internal action log was logged after the onsite work was completed (#43197, #42968).

Edge Cases

• Onsite service can prevent RMA for software/module recovery when remote SSH/control is unavailable, but agents should document that such visits may be an exception and record exact remediation steps such as module package installation, Secure Boot changes, and BIOS setting changes (#42968).
• A missing crash cart does not automatically block onsite completion if the technician can cable the system and verify OS boot through another site-supported path (#43197).
• Customer availability during the visit can delay validation even when the technician completes the physical rack-mount and cabling tasks (#43197).

Related Issues

• Hardware Documentation
• RMA Workflow