Skip to main content

​
Escalation path

This article is internal to Servinix support staff. It describes how a complex issue moves from Tier 1 support up through the vendor stack to Danlaw (hardware manufacturer). This article describes the escalation chain for issues that cannot be resolved at Tier 1. Use it when a customer reports a hardware or telematics problem that requires involvement from BitBrew or Danlaw.

​
Escalation chain overview

Customer
  └─► Servinix Tier 1 Support (you)
        └─► Servinix Engineering / Tier 2
              └─► BitBrew (telematics platform)
                    └─► Danlaw (hardware manufacturer)
Trexinet (AI CSR / Maya) is a separate product layer and is not part of the hardware escalation chain. Trexinet issues go directly to Servinix engineering.

​
Tier 1 — Servinix Support

Who handles it: Support agents using this knowledge base. Resolve at Tier 1 when:
  • The issue is a portal or app configuration problem.
  • The customer needs help with a workflow (scheduling, invoicing, GPS setup).
  • The device LED behavior is explained by the installation guide (normal post-ignition off behavior).
  • An RMA can be initiated through the portal without additional investigation.
Escalate to Tier 2 when:
  • Device LEDs are off and the vehicle is running.
  • The device is not reporting data to Servinix and basic installation checks have passed.
  • A cable mismatch is suspected (OBDII vs 6-pin vs 9-pin).
  • A BitBrew Fulfillment API action is required (cable replacement order, stuck RMA).
Before escalating, collect:
  1. Device serial number (on the label on the DataLogger device).
  2. Vehicle make, model, year, and class.
  3. Cable type currently installed (OBDII, 6-pin, or 9-pin).
  4. LED behavior observed (off, solid, blinking — and color if applicable).
  5. Date and time of last successful telematics ping in the portal.
  6. Customer tenant ID.

​
Tier 2 — Servinix Engineering

Contact: (placeholder — confirm internal Slack channel or email) Handles:
  • BitBrew data-flow investigation (packet history, device provisioning status).
  • Portal or API defects confirmed by Tier 1.
  • Trexinet / AI CSR platform issues.
  • RMA orders that are stuck in the BitBrew Fulfillment system.
Escalate to BitBrew when:
  • Engineering confirms the DataLogger is provisioned correctly but telematics data is not reaching the Servinix platform.
  • A BitBrew API error code indicates a platform-side issue.

​
Tier 3 — BitBrew (telematics platform)

Contact: (placeholder — confirm BitBrew support email or portal) Handles:
  • Device provisioning and network registration issues.
  • Telematics data pipeline faults.
  • Fulfillment API errors for cable and accessory orders.
Escalate to Danlaw when:
  • BitBrew confirms the device is not registering on the network.
  • Hardware defect is suspected (device fails to power on with confirmed vehicle and cable).
  • A warranty replacement or RMA needs Danlaw involvement.

​
Tier 4 — Danlaw (hardware manufacturer)

Contact: (placeholder — confirm Danlaw support contact) Handles:
  • Warranty and defect assessment for DataLogger hardware.
  • Firmware issues identified by BitBrew.
  • RMA logistics (return authorization, refurbishment, re-flashing, shipment).

​
Notes on Trexinet

Trexinet is the inbound voice agent product that powers Maya (AI CSR). It is a separate vendor relationship from the telematics stack. Escalate Maya / AI CSR issues to Servinix engineering directly — do not route them through BitBrew or Danlaw.