Stop refreshing the report: turn it into tickets

Many teams already know where their problems are. Someone opens a report every morning, or every hour, and looks for what’s new: declined cards, orders paid but not shipped, trials that never activated, angry survey answers. The query is written. The work around it is not, and it costs more than it looks.

Three costs of checking a report

Someone has to remember to look. A report waits to be opened. On a busy day, or when that person is away, nobody looks, and the rows sit there.

Duplicates are your problem. A declined card shows up in every refresh until it’s fixed. People sort out by eye which rows they’ve already handled, and the answer is usually “most of them, probably”.

“Handled” lives somewhere else. A spreadsheet, a Slack thread or someone’s memory tracks who took which row, and it drifts from the data.

The same query, as work that arrives

In Rowfire the report’s query becomes a trigger. You keep the SQL and name two of its columns: the clock (when it happened) and the key (what one row is about):

SELECT o.id          AS order_id,
       c.name        AS customer,
       c.email,
       o.total,
       o.paid_at,
       o.paid_at + interval '24 hours' AS overdue_at
FROM orders o
JOIN customers c ON c.id = o.customer_id
WHERE o.status = 'paid'
  AND o.fulfilled_at IS NULL

The report’s version filtered on paid_at < now() - interval '24 hours'. As a trigger, the 24 hours move into the clock instead: overdue_at, a day after payment. The row fires when that moment passes, and only if the order still hasn’t shipped. The key is order_id. A rule says how often one key may fire (here, once per order) and what happens: a Zendesk ticket with the customer as requester, or a message in #fulfillment. From then on each new row arrives by itself, within a minute by default, and the order that stays unshipped for three days is still one ticket.

That answers all three costs. Nobody has to look; the row comes to the team. Duplicates are decided by the key and the rule, and every send is recorded in a ledger, so a row is never filed twice by accident. And once it’s a ticket, ownership, status and history live in Zendesk, where the team already works, so there’s no tracking sheet to keep in step.

Check it against the report first

Before anything is filed, a backtest replays the rule over past days: how many tickets it would have opened, with example rows to compare with what the report showed. On Rowfire’s demo data, one ticket per account per week turns 211 declined charges into 105 tickets; the other 106 were the same problems showing up again. Then shadow mode renders each ticket against live data without sending it. Switch it on when the tickets look right. A new trigger starts at now, so switching it on doesn’t file a ticket for every row already in the report.

Keep the report for what it’s good at

A report is still the right tool for trends, totals and “how are we doing this month”. A trigger is for the individual rows someone has to act on. See Rowfire vs a scheduled report for where each fits, and how to create Zendesk tickets from a SQL query for the ticket setup step by step, and ticket orders paid but not shipped in 24 hours for this trigger in MySQL. Or try it on sample data in the demo.