How to use support tickets

Documentation
, , ,
1

How to use support tickets

This guide explains how to open, manage, and follow up on support tickets from your dashboard for technical and account issues.

Required access: Authenticated customer account.

When to open a support ticket

Open a ticket when self-service troubleshooting fails, when account-level actions are blocked, or when repeated install/update failures require staff investigation.

Before opening a ticket

Prepare this information first:

  1. Product name
  2. Site URL
  3. License key or plan name
  4. Approximate timestamp of issue
  5. Expected result and actual result
  6. Steps already tried

How to create and manage tickets

  1. Open the Support section in your dashboard.
  2. Click new ticket.
  3. Choose the most accurate issue type.
  4. Write a clear problem statement with context.
  5. Submit and save the ticket URL for your team.
  6. Return to ticket thread to post updates or clarifications.
  7. Mark resolved when the issue is closed.

Verification checklist

Confirm:

  • Ticket contains reproducible steps
  • Key identifiers are included (site, product, timestamp)
  • Attachments or logs are added where relevant
  • Follow-up replies are posted in the same ticket thread

What happens after submission

  • Support receives the ticket and can request additional context.
  • You can track all ticket communication in one thread.
  • Resolved tickets remain as internal history for similar incidents.

Related guides

  • Troubleshooting failed installs or updates
  • How to use dashboard history and activity logs

Exact route paths

  • /dashboard/support
  • /dashboard/support/new
  • /dashboard/support/[id]

Expected UI state after each step

  • Step 1: Support listing shows existing tickets and status.
  • Step 2: New ticket form accepts issue details and context.
  • Step 3: Created ticket opens in thread view.
  • Step 4: Replies and updates remain in one ticket timeline.

Screenshot map (step-level)

  1. Support ticket list context

  2. Support thread escalation context

Operational objective

Complete the “How to use support tickets” workflow with predictable outcomes, clear auditability, and repeatable execution quality across team members and projects.

Acceptance criteria (all must pass)

  • The workflow can be completed without missing permissions or blocked route access.
  • All required dashboard routes load successfully for the active account.
  • The expected UI states are visible in the same order as documented.
  • At least one end-to-end validation confirms the process works in practice.
  • Evidence artifacts are captured for support and audit handoff.

Routes that must be reachable during validation:

  • /dashboard/support
  • /dashboard/support/new
  • /dashboard/support/[id]

Failure modes and exact remediation

  • Permission failure: Recheck plan/license entitlements and retry after session refresh.
  • Route loads but action is missing: Confirm feature flags/plan gates and selected context (site/license).
  • Action runs but state does not update: Refresh, re-open the relevant page, and verify from history/log view.
  • Partial success in multi-step operations: Retry only failed sub-steps and preserve successful state.
  • Cross-page mismatch: Reconcile with dashboard history and capture timestamps before escalation.
  • Persistent failure after one controlled retry: Open support ticket with full evidence package.

Evidence package for support escalation

Collect all items before escalating:

  • Account email and user role
  • Affected route path and exact action taken
  • Site URL, product/license identifier (if relevant)
  • Timestamps for first failure and latest retry
  • Expected result vs actual result
  • Screenshot set listed below

Screenshot evidence checklist

  • Step 1: Support ticket list context
  • Step 2: Support thread escalation context
  • One screenshot with visible timestamp (system clock/browser tab)
  • One screenshot showing route context or breadcrumb
  • One screenshot showing final persisted result
  • Replace any generic placeholder/demo visuals with real environment captures

FAQ

Can I skip steps if I already know this workflow?

Skip only after all acceptance criteria still pass. If any criterion fails, run the full sequence exactly as documented.

Should I run this in production first?

Use staging first for medium/high-impact changes. Promote to production only after validation evidence is complete.

What if my screen does not match the guide exactly?

UI can vary by plan and feature access. Validate route access, plan gates, and expected state outcomes instead of pixel-perfect layout.

How many retries should I perform before escalation?

Run one controlled retry after checklist validation. If failure persists, escalate with full evidence to avoid hidden side effects.

Who owns this guide operationally?

Customer Success owns this guide and its periodic review cycle.

Guide metadata

  • Difficulty: Beginner
  • Estimated completion time: 10-15 minutes
  • Owner: Customer Success
  • Last reviewed: 2026-03-18