Technology Never Stands Still, and Neither Do We
Validated Mini-ITX platforms engineered for reliable deployment in industrial, edge, and embedded system environments.
Hardware Support Service Levels
Mini-ITX Service Level Agreement for Engineering Support
Response targets, escalation inputs, warranty handling, validation evidence, and engineering documentation for industrial Mini-ITX deployments.
Response and Resolution Matrix
Severity Determines the Engineering Response Clock
Deployment impact, workaround availability, and functional loss determine ticket severity. Initial response and resolution or workaround are tracked separately.
| Severity | Engineering Condition | Initial Response | Resolution / Workaround |
|---|---|---|---|
| Critical | Hardware failure blocks deployment or stops an operating system with no practical workaround. | Within 2 business hours | Within 4 business hours or documented workaround |
| High | Major degradation affects integration, performance, or deployment and no practical workaround is available. | Within 4 business hours | Within 12 business hours |
| Medium | Partial function loss is present, but the system can continue operating while engineering investigates. | Within 8 business hours | Within 1 business day |
| Low | Documentation, configuration, or non-blocking technical request with no immediate deployment stop. | Within 24 business hours | Within 3 business days |
Contract precedence: Priority and Enterprise agreements can define different coverage windows, response targets, resolution targets, or escalation routes. The signed support agreement controls where terms differ.
Support Coverage
Choose Coverage by Deployment Risk, Not Order Size Alone
Support scope changes with escalation urgency, required communication channel, BIOS involvement, and whether the deployed system can tolerate business-hour-only handling.
Development and Routine Production Support
- Business-hour email support
- Severity-based response matrix
- Product documentation and firmware access
- Configuration and integration questions
Faster Triage for Active OEM Integration
- Priority email and phone support
- 1 business hour response target stated for the plan
- BIOS configuration guidance
- Earlier roadmap communication
Mission-Critical and High-Volume Deployment Coverage
- 24/7 emergency support under contract
- Custom response and resolution terms
- Pre-launch hardware validation
- Dedicated engineering liaison path
Incident Intake
Give Engineering Enough Evidence to Reproduce the Failure
A severity label without electrical, firmware, and operating context slows triage. A useful ticket identifies the exact hardware state that produced the failure.
Minimum Hardware Fault Package
- Identity
- Board model, serial number, production lot if available
- Firmware
- BIOS version, firmware revision, relevant BIOS settings
- Power
- Input voltage, adapter rating, measured rail behavior if available
- Load
- CPU workload, storage, USB, LAN, COM, display, or PCIe devices connected
- Environment
- Ambient temperature, enclosure, cooling method, vibration or vehicle power context
- Evidence
- Reproduction steps, timestamps, photos, logs, screenshots, scope captures, or failure video
01
Log
Record hardware identity and failure evidence.
02
Classify
Assign severity from deployment impact and workaround availability.
03
Triage
Separate power, BIOS, thermal, I/O, component, and software-path causes.
04
Contain
Issue a workaround, configuration change, or test request when possible.
05
Close
Document repair, replacement, firmware action, or validated corrective action.
RMA and Warranty
Separate Warranty Eligibility from Failure Reproduction
RMA handling requires traceable hardware identity and enough evidence to determine whether the issue is reproducible, configuration-related, repairable, or eligible for replacement.
Standard Warranty
Factory-defect coverage stated for standard products.
Extended Industrial Coverage
Available for selected industrial SKUs when explicitly included in the contract.
RMA Traceability
Hardware identity and reproducible evidence should accompany the return request.
Before Hardware Return
- Confirm board model and serial number
- Record BIOS and firmware revision
- Reproduce the failure with known-good power and peripherals where practical
- Document visible damage and connector condition
- Preserve logs or test evidence tied to the failed unit
Validation Evidence
Define the Test Condition Before Calling a Result Compliant
Validation evidence is useful only when the board revision, BIOS, load, environment, test method, acceptance limit, and result are tied to the same test record.
12V / 24V Power and Transient Validation
Record nominal input, tolerance, source impedance, startup load, peripheral load, brownout behavior, and recovery state. Use the exact board input range rather than a platform-wide assumption.
IEC 61000-4-2 and IEC 61000-4-4 Test Context
Where ESD or EFT testing is required, document test level, coupling method, port under test, operating mode, pass criteria, and post-event recovery behavior.
Ambient, Load, and Cooling Must Be Recorded Together
Thermal evidence should identify ambient temperature, CPU workload, enclosure state, heat-spreader interface, fan state, test duration, throttling behavior, and maximum component temperatures.
Certification Scope Must Match the Selected SKU
CE, FCC, RoHS, REACH, WEEE, or other documentation should be checked against the exact product, revision, destination market, and customer compliance requirement.
Engineering Documents
Keep Support Decisions Bound to Revision-Controlled Records
For repeat production, the useful support record is not a generic datasheet. It is the set of files that identifies what was built, configured, tested, changed, and released.
Product Specification
CPU, memory, storage, I/O, DC input, mechanical dimensions, environmental limits, and SKU-specific options.
BIOS / Firmware Baseline
Released version, configuration baseline, update package, recovery method, and changelog when applicable.
Mechanical Record
Board dimensions, mounting-hole coordinates, connector position, component height, and enclosure clearance information.
Validation Record
Test condition, sample identity, equipment or method, acceptance criteria, measured result, and revision under test.
Lifecycle Change Record
BOM, approved substitute, BIOS dependency, PCN/EOL status, qualification evidence, and release approval for repeat builds.
RMA Closure Record
Failure symptom, reproduction status, root cause when identified, repair or replacement action, and returned-unit disposition.
SLA Search Questions
Service Level Agreement FAQ for Hardware Support
What is the SLA response time for critical hardware failures?
Critical incidents target an initial response within 2 business hours and a resolution or documented workaround within 4 business hours, unless contracted terms define different targets.
What is the difference between SLA response and resolution time?
Response time measures acknowledgement and triage. Resolution time measures restoration, workaround, or closure. Tracking both prevents a fast first reply from being mistaken for a corrected hardware issue.
How are SLA business hours calculated for support tickets?
Business-hour timers count only the support window defined in the applicable agreement. Priority and Enterprise contracts can use different coverage windows, including 24/7 emergency support.
How long is the warranty for an industrial Mini-ITX motherboard?
Standard warranty is 12 months for factory defects. Selected industrial SKUs may qualify for extended coverage up to 36 months when specified in the supply or support contract.
What information is needed for a motherboard RMA request?
Provide board model, serial number, BIOS version, failure symptoms, reproduction steps, power input, connected peripherals, operating environment, and photos or logs that help engineering reproduce the fault.