Ticket and Support Workflow

How support tickets are created, routed, and resolved — operator-side open through resolution.

The Ticket and Support Workflow is the cross-product process that takes an operator from "I need help" to "the issue is resolved". It begins inside SG-Dashboard with the operator opening a ticket, hands off to the support team's handling system, and ends with the resolution communicated back to the operator. This page is the Reference definition.

What is this for?

Read this page when you want the structural definition of the support-ticket flow — how tickets are opened, what context attaches automatically, where the ticket goes, and how resolution is communicated.

Good use cases

• You hit a question requiring SGEN support and want to know what happens after you open a ticket.
• You are explaining to a stakeholder how SGEN handles support handoff.
• You are designing internal SOPs around support escalation.

What NOT to use this for

• Step-by-step ticket-open procedures — open the relevant Guide.
• Per-release shipped change — open What's New or Changelog.
• Per-customer SLA detail — customer agreement.

How this connects to other features

• Workflows Overview — parent Reference area.
• SG-Dashboard Overview — entry surface for ticket open.

Definition

The Ticket and Support Workflow is the cross-product process for creating, routing, and resolving support tickets. The workflow has an entry surface (SG-Dashboard Support panel), a routing layer (the support team's handling system), and a resolution channel (in-platform notification + email).

The defining property is account-tier. Tickets are scoped to the account, not to individual sites. Account owners and operators with support access can open and view tickets.

Purpose

The purpose of this page is to define the support-ticket flow as a Reference layer. It explains the entry path, the context that attaches automatically, and the resolution channel.

Scope

This page covers the workflow at the Reference level.

The page covers:

• The entry surface (SG-Dashboard → Support).
• The auto-attached context (account, sites, recent activity).
• The routing layer.
• The resolution communication channel.

• Step-by-step ticket-open procedures — Guides.
• Per-customer SLA detail — customer agreement.
• Per-release shipped change — What's New or Changelog.

Entry surface

SG-Dashboard → Support → Open Ticket

The operator opens SG-Dashboard, clicks Support, clicks Open Ticket. The Dashboard surfaces the ticket-open form with subject, description, and (where applicable) a category selector.

Auto-attached context

When the ticket is opened, the platform automatically attaches relevant context so support can engage without re-asking.

Account identity

Account name, plan tier, recent billing state.

Site context

The site (or sites) the operator was working in when the ticket was opened.

Recent activity

Recent operator actions across the platform that may relate to the issue.

Operator identity

Operator name, role, and contact preference.

Routing layer

The ticket routes through the support team's handling system. The operator does not need to know the routing internals; the Reference here covers what the operator sees from the platform side.

Resolution channel

Resolution is communicated back through two channels.

In-platform notification

Notification Logic delivers the in-app notification when support replies or closes the ticket.

Email

The support reply also arrives via email through the same Email and SMTP transport.

Ticket history

The full ticket history (operator open, support replies, operator follow-ups, resolution) lives inside the SG-Dashboard Support panel for review.

Constraints and boundaries

This Reference covers the cross-product support-ticket flow.

Use this Reference for:

• Understanding the ticket flow from open to resolution.
• Reasoning about what context auto-attaches.

• Per-step ticket open — Guides.
• Per-customer SLA — customer agreement.
• Per-release shipped change — What's New or Changelog.

Public boundary

This page is intentionally public-safe.

Examples

Example 1 — Operator opens a ticket about a layout issue

The operator opens the ticket; auto-attached context (account, site, recent theme change) attaches. Support engages with full context. Resolution lands via in-platform notification + email.

Example 2 — Operator follows up on an existing ticket

The operator opens the SG-Dashboard Support panel, finds the existing ticket, adds a follow-up note. Support sees the follow-up and replies through the same channel.

Example 3 — Stakeholder asks "what does support see when we open a ticket?"

The platform lead opens this page (Auto-attached context section) and walks the stakeholder through what attaches automatically. The Reference resolves the structural question.

Documentation guidance

Use this page as the structural definition for the support-ticket flow. Procedural detail belongs in Guides; per-release behavior change belongs in What's New or Changelog.

Reading order

Open this page when scoping support handoff or troubleshooting ticket-flow questions.

Related reading

• Workflows Overview — parent Reference area.
• SG-Dashboard Overview — entry surface.

Vocabulary cross-reference

• Ticket is a recorded support request from the operator.
• Auto-attached context is the account / site / activity data the platform attaches at open time.
• Routing layer is the support team's handling system.
• Resolution channel is the in-platform notification + email path that returns the support reply.

Maintenance discipline

When the ticket workflow changes across releases (new auto-attached field, new resolution channel, new routing surface), update this Reference and log the change in Changelog.

Related reading

Prerequisites

Before working a ticket queue:

• You are signed in as a Support user or have been granted ticket-handling permission by an Owner.
• You know which routing channel (queue / category / tag) you cover.
• You can see the ticket inbox at dashboard.sgen.com/support (or the operator's equivalent route).

Steps — Work a support ticket end-to-end

1. Open the support inbox

From SG-Dashboard, navigate to Support in the left sidebar. The inbox lists tickets by queue with status, subject, requester, and last-update time.

2. Triage and claim

Filter by your queue. Sort by Created ascending so the oldest unaddressed ticket comes first. Click a ticket to open it. Use the Assign to me action to claim it — this prevents duplicate work by other operators.

3. Resolve and close

Reply with the resolution. Set status to Resolved when the customer's blocker is unblocked. Add an internal note if any follow-up is needed before close. Status Closed is the final state — only set once the customer confirms or 48h passes without reply.

Rollback / Recovery — reopening a closed ticket

If a ticket was closed prematurely or new info arrived after close:

• Reopen from the ticket detail view — click Reopen at the bottom of the ticket. Status flips back to Open and the customer + assignee are notified.
• Wrong assignee — use Unassign then Assign to me (or assign correctly). The audit log records both actions.
• Wrong status set — manually flip the status back via the status dropdown. The history pane shows who changed it and when.

Troubleshooting — ticket workflow issues

• Submitted ticket doesn't appear in the inbox. Confirm the customer's ticket reached the correct queue — some submission paths route by category. Check the Spam/Filtered tab if your inbox has filtering rules.
• Reply not delivered to customer. Check the customer's email is correct on the ticket. If correct, check the Mail Settings on the support channel — if the From address is wrong, replies fail silently.
• Assignment dropdown is empty. Your role lacks ticket-assignment permission. Ask your support lead or Owner to grant it.
• Internal notes are visible to customer. Notes marked Public post to the customer. Edit the note, toggle Private, save. If the note already sent, follow with a Public correction.

Where to find it

Open your SG-Admin and navigate via the sidebar group that owns this surface. For platform-level reference (this page), the entry point is the SGEN documentation index at docs.sgen.com. For the operator-facing configuration screen, the entry point is the corresponding SG-Admin module page linked in Related features above.

Reference shape

A minimal payload that this surface accepts or emits looks like:

{"site": "your-site.com","surface": "ticket-and-support-workflow","actor": "operator@your-domain.com","timestamp": "2026-04-22T14:03:00Z"}

Use this shape when scripting against the surface or when reading audit logs that reference it.

Sample payloads

A ticket record carries the following shape end-to-end:

{"ticket_id": "TKT-2026-04881","site": "your-site.com","requester": "operator@your-domain.com","subject": "Checkout failing on Canvas Tote","status": "open","queue": "support","assigned_to": "ada.lovelace@sgen.com","created_at": "2026-04-22T14:03:00Z"}

A reply event posted from the inbox:

{"ticket_id": "TKT-2026-04881","actor": "ada.lovelace@sgen.com","type": "public-reply","body": "Thanks for flagging — checkout is now restored.","timestamp": "2026-04-22T14:09:00Z"}

A status transition emitted when a ticket closes:

ticket_id: TKT-2026-04881from: resolvedto: closedactor: operator@your-domain.comclosed_at: 2026-04-24T08:11:00Z