Audience: Tech-CS triage / whoever is covering the role. This is the working method for turning Tech-CS issues into engineering tickets, not a general agent guide.
Purpose: This article sets out how a Tech-CS issue is triaged and turned into a Jira ticket, so tickets are consistent, well-formed, and easy for engineers to work from.
The principle: investigate before you raise
A Jira ticket should only be raised once you have (a) confirmed it is a genuine issue, not merchant error or expected behaviour, and (b) gathered enough detail for an engineer to act. Rushing to a ticket without investigating creates noise and stalls; taking a few minutes to check first produces a ticket that can actually be picked up and fixed.
Step 1: Check for duplicates
Before creating anything, check whether a ticket already exists for the same issue. Search Jira (the Tech-CS epic, OPS-3583) by merchant ID, order ID, SKU, or a distinctive keyword from the error.
- If a matching open ticket exists: do not raise a new one. Add a comment to the existing ticket with the new merchant ID, order, and Zendesk detail as another affected example. This is how we track that an issue is hitting multiple merchants.
- If there is a closed ticket for the same thing: check whether this is a recurrence; note the old ticket in the new one so engineering has the history.
Step 2: Investigate and rule out
Establish whether it is actually a bug. Rule out the obvious first: is the order paused, are funds sufficient, is the artwork configured, is the merchant doing something the product does not support (for example an out-of-range page count, or artwork built to the wrong dimensions)? Be honest about bug vs user error, if it is user error, the answer is to guide the merchant, not raise a ticket. If it is genuinely both (the merchant did something wrong and the system handled it badly), say so in the ticket.
Step 3: Write the ticket, requirements, not implementation
Tickets must describe what needs to be true, not how to build it. No code, no implementation detail. Structure it so an engineer can work from it:
- Summary: succinct and specific (SKU, symptom, merchant)
- Merchant details: email, merchant ID, Zendesk ticket number
- Affected order: order ID, OMS ID, SKU, destination
- Error: the exact error text or reference
- Expected behaviour vs Actual behaviour
- Requirements: what needs investigating and fixing, as clear points
- Additional context: related tickets, patterns, priority-merchant flags
Step 4: Set the essentials
- Project: always Operations (OPS)
- Parent: always the Tech-CS epic, OPS-3583
- Priority: High for blocking/production-impacting or priority-queue merchants; Medium for most others
- Assignee: the engineer who owns the area (see the engineer routing guide). Assign only when it is clear; if unsure, note the likely owner in the ticket
- Type: Bug for something broken, Task for a data addition or a feasibility/feedback item
Step 5: Attach the evidence (critical)
Engineers cannot see Zendesk. Every screenshot, error screen, print file, and piece of merchant history the engineer needs must be attached to the Jira ticket. A ticket that references "the screenshot in Zendesk" without attaching it will stall. This is the single most common reason tickets get stuck.
Step 6: Close the loop
- Post the ticket link back so CS and the merchant can be updated (format: https://prodigiuk.atlassian.net/browse/OPS-XXXX)
- Where the ticket was raised from a Slack thread, resolution will post back to that thread automatically
- Update the team workload view (Miro board) so the ticket is visible
Golden rules
- Investigate before raising, be honest about bug vs user error
- Always dedupe first; add to an existing ticket rather than creating a parallel one
- Requirements only, no implementation detail
- Always parent to OPS-3583, always in the OPS project
- Attach the evidence, engineers cannot see Zendesk
- Always provide the ticket link after creating