Datapipe

Customer support · USE CASE

Find the support tickets that need another look.

Use Zendesk status, priority and update times to see which unresolved tickets deserve a review.

Zendesk
Try it with your data Free with up to 3 data sources · No credit card
A WORKED EXAMPLE
Unresolved tickets to check
3814 · Checkout errorHighOpen → Nov 5
3807 · Account accessNormalPending → Nov 4
3822 · Setup questionNormalSolved → Nov 7
Current ticket state · Example review Nov 8, 2026 UTC

Two unresolved tickets have no update for at least 72 hours.

EXAMPLE CONVERSATION

Your question.
A useful answer.

✦ AI assistant
Zendesk
YOU

  1. 01
    Ticket 3814 · Open · High priorityReview first

    Next

  2. 02
    Ticket 3807 · Pending4 days without an update

    Next

Example review · Nov 8, 2026 UTC

01 · CONNECT YOUR DATA

Your tools. One place to ask.

1 of 3 Free data sources
No credit card · Daily refresh

DatapipeYour project
Your AI assistantor a report in Sheets / Data Studio
  1. Create your free workspace

    Sign up with your company email. Your first project opens on Data sources.

  2. Add your data source

    Choose the accounts for this workflow. Authorize access and select the property or site.

  3. Bring your question

    Connect your project to a supported AI assistant, or build your source reports.

Create a free account →
Setup steps & what you need

Email/password signups confirm their email first. Use Google signup with a company account if you prefer.

  • Zendesk: Enter your Zendesk subdomain and authorize the intended account using its supported setup. Setup guide ↗

Free includes 3 data sources across the workspace. One account/property added to one project counts as one. Extra properties or the same account in another project use another slot.

02 · ASK A USEFUL QUESTION

Start with a prompt.
Follow the evidence.

Copy these in order into your connected assistant.
Each builds on the answer before it.

01

Find inactive unresolved tickets

Read the full prompt
Use only this project’s authorized data sources. Discover the accounts, datasets and fields first. Confirm the account, review timezone and reporting coverage. Preserve missing data instead of substituting examples.

Read Zendesk expanded current tickets with id, subject, status, priority, assignee_id and updated_at. Use our chosen review time in UTC and a 72-hour inactivity threshold. Exclude solved and closed tickets, show last update and hours inactive, and flag missing timestamps or archive/visibility limits.
02

Check the conversation and owner

Read the full prompt
For that shortlist, inspect the selected ticket’s available comments or details and assignee context. Distinguish a pending customer response from work the team still owns. An updated_at timestamp is not automatically a reply time; do not infer an SLA breach or customer wait duration from it.
03

Prepare a support-review agenda

Read the full prompt
Prepare a short review agenda with ticket identity, observed status and priority, inactivity duration, and the next owner or conversation check. Keep uncertainties explicit. Do not contact customers, change ticket fields, or claim a historical response-time trend from current ticket state.

03 · USE WHAT YOU FIND

Review the conversation and ownership before deciding the next response.

  1. 01

    Read the current accessible tickets and exclude solved or closed work.

  2. 02

    Apply your chosen inactivity threshold using an explicit review time.

  3. 03

    Inspect the latest conversation and assignee before following up.

Check the result at your next review.

Repeat the review at a useful cadence. Use proper ticket metrics and history for SLA or response-time reporting; current inactivity is a different measure.

Implementation tips for this use case

Review the selected ticket’s conversation and assigned owner. Decide whether to respond, ask internally for an update, or continue waiting for customer information.

WHEN YOU NEED MORE CONTEXT

Go a little deeper.

The method and reporting checks
behind this example.

How to find inactive unresolved support tickets
  1. Read the current accessible tickets.

    Use Expanded current tickets with ticket ID, subject, status, priority, assignee ID and updated_at. Ordinary ticket lists can exclude archived or inaccessible tickets.

  2. Apply an explicit inactivity threshold.

    Choose a review time and timezone, exclude solved/closed work, and find tickets with no update for your chosen number of hours. Last update means any ticket activity, not necessarily the last public reply.

  3. Read the conversation before responding.

    Check the latest comments and assigned owner. Pending may mean the customer owes a reply. Bring priority and business context into the review without treating inactivity as proof of an SLA breach.

See the complete example report
EXAMPLE REPORTFictional sample data

Unresolved tickets to check

Current ticket state · Example review Nov 8, 2026 UTC

Unresolved tickets to check · fictional sample data
TicketStatusLast updatePriority
3814 · Checkout errorOpenNov 5High
3807 · Account accessPendingNov 4Normal
3822 · Setup questionSolvedNov 7Normal
WHAT TO LOOK ATTwo unresolved tickets have had no update for at least 72 hours.

Review the conversation and ownership before deciding the next response.

Illustrative report output · no live query or source change

The open checkout ticket is high priority and has not been updated for three days. The pending account-access ticket has had no update for four days; check whether it is waiting on the customer.

Try the example with sample CSVs

Fictional rows matching the example above. Attach these files to your assistant for a sample analysis.

Data method, reporting checks & sources

Use Zendesk expanded current tickets with native id, subject, status, priority, assignee_id and updated_at. A last update can be any ticket change; it is not necessarily a customer or agent reply. The ordinary list can exclude archived or inaccessible tickets.

Inactivity does not prove a missed SLA or customer wait time. Custom status categories and archive limits matter. Historical response-time or SLA conclusions need additional appropriate data.

  • The inactivity threshold and review timezone are explicit.
  • Solved/closed tickets are excluded and visibility limits are retained.
  • Ticket updates are not mistaken for reply times or SLA deadlines.
  • An authorized Zendesk account with access to the intended tickets.
  • A chosen inactivity threshold and review timezone.
  • Ticket conversation and ownership context before a response.

For blended reports, align dates, normalized URLs, and reporting grain. Query-level search rows must not duplicate page-level sessions. This is an illustrative workflow; live accounts and destinations need their own setup.

A FEW USEFUL ANSWERS

Before you start.

Does updated_at show the last customer reply?

Not necessarily. A ticket update can include other activity. Inspect comments or suitable event history before measuring reply time or deciding who owes a response.

Does an inactive ticket mean we breached an SLA?

No. A breach depends on the applicable SLA policy, clocks and event context. This example prepares a review list from current status and update time.

YOUR NEXT STEP

Try it with your own data.

Start free with up to 3 data sources. No credit card.

Start free →