Creating a Support Ticket
Start with Hatz docs and the Messenger when you have a question. If the issue still needs account-specific investigation, Hatz can create a structured support ticket.
A support ticket is more than a request for a human. It includes the required fields support needs to route the request, assign priority, and avoid back-and-forth questions.
When to create a ticket
Create a support ticket when:
The docs or Messenger answer does not resolve the issue.
A product issue, account issue, billing question, security/compliance request, legal request, or incident needs a human owner.
You have evidence that Hatz is not behaving as documented.
You need Hatz to investigate account-specific impact during an incident or outage.
For use-case strategy, custom workflow design, prompt consulting, training, or hands-on implementation, support may route you to free enablement or a paid engagement instead of treating the request as break/fix support.
Required ticket fields
Before a ticket is created, Hatz needs enough structured information to route it. These fields are required for every support ticket:
Short summary: one sentence describing the issue.
Issue type: the closest category, such as Workshop Help, Bug / Product Issue, Account Access, Credits / Usage, Billing, Integrations, API / Developer, Files / Exports, Security / Compliance, Legal, Incident / Outage, or Roadmap / Feature Request.
Impact: who is affected and what work is blocked or degraded.
Urgency: timing, deadline, rollout, customer impact, or production impact.
Issue-specific fields
Depending on the issue type, Hatz may ask for these details before creating or routing the ticket.
Workspace, tenant, or account: required when the issue affects a specific Hatz workspace, tenant, customer account, or MSP account.
Affected user: required when a specific user is affected. For MSP-managed tenant issues, include the MSP or tenant-admin context along with the affected user email or role.
Expected behavior: required for bugs, Workshop Help, API / Developer, Files / Exports, Integrations, and product-behavior tickets.
Actual behavior: required for bugs, Workshop Help, API / Developer, Files / Exports, Integrations, and product-behavior tickets.
Evidence: strongly encouraged, and sometimes required for investigation. Include screenshots, error messages, API request IDs when using the API, workflow or run links, chat or item links, generated-file panel details, timestamps, or a diagnostic packet if Hatz asks you to provide one.
For product UI issues, share visible item, run, chat, or generated-file links when available, plus timestamp, screenshot, and error text. For API issues, include the response X-Request-ID.
How priority works
You should describe impact and urgency. Hatz assigns the final priority from that information. Priority may change if the impact changes or if the issue is tied to an active incident.
Use P0 only for active outage or emergency impact. Use P1 for urgent blockers with no acceptable workaround. Normal support issues are usually P2. Low urgency, how-to, roadmap, or advisory requests are usually P3.
Urgent wording alone does not make a ticket P0 or P1. Paid engagement and enablement requests are not P1 unless an existing production Hatz feature is failing and the impact otherwise meets P1 criteria.
After a ticket is created
After a ticket is created, you should receive a clear summary of the issue type, priority, and next step. You can reply to add details, correct severity, or tell us if the issue is resolved.
If support is waiting on your reply, we may send follow-ups. If there is no response after two follow-ups and 10 calendar days, we may close the ticket. You can reply again if the issue comes back or the ticket needs to be reopened.