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.
| What it counts | claims WHERE status=open AND NOT EXISTS (jira.tracker_item WHERE refs CONTAINS claim_id OR refs CONTAINS consignment_number). Pulls open DPDLocal claims and checks whether any Jira ticket references the claim ID or the underlying consignment number. |
| Match logic | Match is on either claim_id or consignment_number appearing in any Jira ticket field (summary, description, custom field). Tunable via the connector’s jira_search_fields config. |
only_when: has_jira_sibling | Card only renders when Jira (or Jira Cloud) is connected. |
| CS-tool agnostic | The Jira integration is the default; merchants on Zendesk, Freshdesk, or Gorgias can substitute by configuring the relevant CS connector’s match query. |
| Time window | RT |
| Alert trigger | row count >0. Any unmatched open claim is a coverage gap; the card aims at zero. |
| Roles | owner, operations |
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.| Open claim | Filed | Consignment | Customer | Jira ticket | Status |
|---|---|---|---|---|---|
| CL-44219 | 27 Feb 26 | 154-DPD-9981 | Walker, K | (none) | Coverage gap |
| CL-44241 | 02 Mar 26 | 154-DPD-9986 | Patel, A | CS-3142 | Covered |
| CL-44263 | 05 Mar 26 | 154-DPD-9991 | Lee, R | (none) | Coverage gap |
- 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
| Card | Why pair |
|---|---|
| Open Claims | The total population this card filters. |
| Open Claim Value | Quantifies the £ at risk on the unmatched rows. |
| Ageing Claim Watchlist | Adjacent CS-process check. |
| Open Claims by Age | Confirms “silent” gap claims are typically the ones ageing past 14d. |
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:| Reason | Direction | Why |
|---|---|---|
| Match field coverage | Either | If your CS team types “DPD parcel issue” without the consignment number in the Jira summary, the match fails. Tune jira_search_fields to include description and custom fields. |
| Closed Jira tickets | Either | The card matches against open Jira tickets only. A claim re-opened after the Jira ticket was already closed will appear as a gap. |
| Free-text reference variants | Card stricter | Consignment numbers like 15409981 may be entered as 154-DPD-9981 or 15409981; configure regex normalisation for higher recall. |
| Card | Expected relationship |
|---|---|
| Open Claims | Total open claims; unmatched rows here ≤ total open claims always. |
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.