Find the real bugs in Zoho Desk and file them once in Linear

Every weekday at 9am, review the open tickets in Zoho Desk, work out which ones are genuine engineering bugs, and hand those off to Linear properly. The single most important rule is that the same defect must never be filed in Linear twice.

Start with List Tickets in Zoho Desk to pull the currently open tickets, newest first. For every ticket that could plausibly be a defect, use Get Ticket for the full record and List Ticket Conversations to read the whole exchange between the customer and support. Judge from what the conversation actually says, not from the subject line, because subjects are frequently misleading.

Treat a ticket as a confirmed bug only when the product behaved differently from the way it is designed or documented to behave. Qualifying signals include: something that used to work and now fails, an error message or crash, data that saves incorrectly or disappears, a page or control that does not respond, a report or export showing wrong or empty values, and an integration that stopped syncing.

Exclude the following, even when the customer is frustrated: how-to and usage questions, configuration or permission problems on the customer's own side, billing, invoicing, refund and plan questions, feature requests and "it would be nice if" asks, and user error where support explained the correct steps and the customer was satisfied. When the conversation is ambiguous, or support never managed to reproduce the problem, leave the ticket alone rather than guessing. A missed escalation is cheap to catch later; a wrong or duplicated issue is expensive.

Before doing any work on a ticket, call List Ticket Comments on it and skip the ticket entirely if an earlier run already left a comment containing a Linear issue reference. This keeps repeated runs idempotent.

For each confirmed bug, check Linear for an existing issue before filing anything. Use Search Issues several times with different phrasings of the same defect: the customer's own wording, the exact error text, and the name of the affected feature or screen. Do not conclude that nothing exists after a single search. Compare candidates on the underlying defect rather than the wording, because two customers will describe one bug in completely different language. Same feature plus same failure plus same conditions means it is the same bug. Include recently closed issues in your judgement, since a defect that has resurfaced belongs on the existing thread as a regression rather than in a fresh issue.

When a matching issue already exists, do not create a new one. Use Add Comment to Issue to attach the new customer evidence: the customer name, what they experienced, the date they reported it, any error text or steps taken from the conversation, a link back to the Zoho Desk ticket, and the updated total of how many tickets have now reported this defect.

When nothing matches, use Create Issue. Give it a title naming the specific defect rather than the customer's complaint. In the description include numbered reproduction steps reconstructed from the conversation, the expected behaviour versus what actually happened, the affected customer along with any environment detail mentioned such as browser, device or plan, a link back to the originating Zoho Desk ticket, and the number of tickets reporting the defect so far, which is one for a first report.

Once the issue is filed or updated, use Add Ticket Comment on the Zoho Desk ticket to record the Linear issue identifier and its URL. Post it as a private comment so support can track engineering status directly from the ticket without exposing internal tracking to the customer.

Finish by sending one Slack message summarizing the run: the new issues filed with their links and the customer behind each, the tickets that were attached to existing issues and which issue each joined, any defect now reported by three or more tickets called out for attention, and a count of how many tickets were reviewed and how many were skipped with the main reasons. If nothing qualified, say so in a single line rather than staying silent, so the team knows the check ran.