Open DPDLocal claims that don’t have a corresponding Jira ticket - direct CS coverage gap. Each row = a customer waiting and nobody is on it.
At a glance
Real-time list of open DPDLocal claims with no matching Jira ticket. Each row is a customer waiting and nobody is on it. The card is the silent-customer-trust-gap detector: a damaged or lost parcel where the carrier claim was filed but CS never picked up the customer-facing thread.
Calculation
Calculated automatically from your DPDLocal data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading.Worked example
A UK lifestyle DTC merchant runs DPDLocal + Jira Cloud (CS team workflow). Reading 12 Mar 26.
Card shows 2 rows in the gap list. Three things to notice:
- CL-44219 has been open 13 days with no CS thread. The customer never heard from the brand after the original where-is-my-order ping; trust eroded silently. NPS at 14-day post-purchase will reflect this.
- The fix is process, not technology. Add a Vortex IQ webhook on this card that auto-creates a Jira ticket from any unmatched claim within 1 hour, owned by the CS triage queue.
- Aim for zero rows. Steady-state above zero is a CS-process gap.
Sibling cards merchants should reference together
Reconciling against the vendor’s own dashboard
Where to look: Neither DPDLocal nor Jira surface this gap natively, the Vortex IQ join is the only view. To verify manually: export open claims from MyDPD; export open Jira tickets containing “DPD” or “claim”; diff by claim ID or consignment number. The card automates this and keeps it real-time. Why our number may differ from a manual diff:
Cross-connector reconciliation:
Known limitations / merchant FAQs
My CS team uses Zendesk, not Jira. Can I still use this card? Yes, with config. Replace thehas_jira_sibling condition with has_zendesk_sibling (or Freshdesk, Gorgias) and adjust the match query to point at the CS-tool’s ticket endpoint. The card framework supports Zendesk and Gorgias today.
The gap count is climbing. What changed?
Three usual causes. (1) CS process change. The team moved from Jira to a different tool but the connector still points at Jira; obvious gap until reconfigured. (2) Claim auto-filing. Some merchants auto-file claims via DPD API on DAMAGED_IN_TRANSIT event without creating a Jira ticket; auto-create the matching Jira ticket via Vortex IQ webhook. (3) CS triage backlog. Inbound CS queue stretched, triage didn’t get to today’s new claims yet; expected to recover within 24 to 48 hours.
Should the card aim for zero or some small number?
Zero is the right target. A non-zero count is a customer waiting and nobody is on it. Treat any persistent non-zero state as a CS-process bug, not a steady state.
Can I auto-create Jira tickets from this card?
Yes. Add a Vortex IQ webhook on this card that triggers a Jira ticket creation with a templated summary (Open DPDLocal claim {claim_id} for consignment {consignment_number}, customer {customer_email}). The webhook fires within minutes of the gap detection.
What if the same customer has a Jira ticket but for a different claim?
The card matches by claim ID or consignment number, not by customer. If a customer has two open claims and only one Jira ticket linked, the unmatched claim appears in the gap list. CS should add the second claim ID to the existing ticket or open a second ticket.
Why does the card require Jira specifically?
Default integration only. Replace with any CS connector that exposes a ticket-search API; configuration is per-merchant.