Vendor Mismatch

Pattern Description

Vendor mismatch occurs when a ticket reaches Exxact support, but the failing product, accessory, software stack, or requested administration path is actually owned by another vendor or outside Exxact’s support boundary. In this set, the mismatch appears as non-Exxact serial numbers, third-party add-in hardware, OEM prebuilds, vendor-managed networking gear, or software support that belongs with the manufacturer.

Evidence

• Non-Exxact systems or unclear ownership stop support early. #13008 closed after the customer confirmed the servers came from another vendor, #5934 stalled because Exxact could not confirm it sold the system, #7215 used a non-Exxact serial format, and #39187 ended once the customer confirmed the system was likely from another vendor.
• Third-party components inside an Exxact environment shift responsibility. In #27310 the added Seagate drives were customer-purchased and turned out to be the real fault, #31128 involved a third-party TPM module that Exxact would not support beyond high-level guidance, #38774 was a non-Exxact HDD follow-up, and #17949 shifted suspicion from the Exxact system to the customer-provided HTG FPGA card.
• OEM or manufacturer-owned products require vendor routing. #23021 was cancelled when the returned RTX4000 was identified as not sold by Exxact, #34080 was routed back to Supermicro because it was an SMC prebuild, #31350 was redirected to NVIDIA for Mellanox switch NOS support, and #7467 also became a vendor-boundary networking case.
• Boundary confusion also appears in admin and parts requests. #17990 was a Synology administration request outside Exxact break-fix scope, #18365 centered on a Gigabyte server and unsupported memory path, #17590 pointed the customer toward ASUS for rails on an older system, and #41839 references a Gigabyte system in a credit-return workflow rather than a normal Exxact replacement path.

Impact

• Vendor mismatch delays real troubleshooting because agents must first prove ownership and support scope.
• It creates customer frustration when a ticket looks like a hardware fault but closes as a redirect.
• It also distorts support metrics by mixing true Exxact failures with third-party or out-of-scope requests.

Recommendations

• Require serial-number validation and product-origin checks at intake before deep troubleshooting or RMA approval.
• Add clearer macros for non-Exxact hardware, third-party component, OEM prebuild, and vendor software boundary cases.
• When redirecting, name the correct vendor and the exact unsupported boundary, not just a generic decline.
• Track this pattern separately so vendor-boundary tickets do not inflate Exxact issue trends.

Referenced by

No incoming references yet.