---
icon: clipboard-list
---

# What to Include in a Ticket

The details that get a sharper, faster answer. None of this
is strictly required — send the message anyway if you're
unsure, and we'll ask follow-ups — but the more of it you
include up front, the less back-and-forth before we can
actually do something.

## Always useful

- **Which service or project** you're asking about. If
  you have more than one site, mailbox, or active project
  with us, name the specific one (the domain, the project
  title, the invoice number). Saves us a clarifying email.
- **What you tried to do** in plain language. "I clicked
  the login button" beats "I tried to log in" — the more
  literal, the better we can reproduce.
- **What happened instead** — the error message you saw,
  the screen you ended up on, the URL in the address bar
  at the moment things went wrong.
- **When it started** — "this morning", "after I changed
  something", "since last Tuesday". Helps us narrow down
  what changed.

## Very useful when applicable

- **A screenshot.** A picture of the actual screen with
  the actual error settles a lot of guesswork.
- **The URL** of the page where you're seeing the issue.
  If it's a multi-step flow, the URL of every step.
- **The browser and device** you're using. "Safari on
  iPhone" is enough; we don't need the version number
  unless we ask.
- **Whether it's reproducible.** "Every time" vs "just
  the once" leads to very different debugging paths.
- **Whether anyone else on your team is affected.** A
  problem only you can see vs. one your whole team
  hits points us at different root causes.

## For payment / billing questions

- **The invoice number** as printed on the document
  (e.g. `INV-0543`).
- **The transfer date and amount**, if you've already
  paid.
- **Which bank account you sent from**, if there's any
  chance the name on the transfer doesn't match your
  company name.

## For website-down reports

- **The URL** you tried to visit.
- **The error message** (or "blank page", "loading
  forever", whatever applies).
- **What time you first saw it** — even a rough
  "around 3pm" helps cross-reference monitoring.
- **Whether it's down for others** if you've checked
  (sites like *downforeveryoneorjustme.com* are useful
  here).

You can skip all this and just write *"site is down"* —
we'll dig in either way. The details just shave time off
the diagnosis.

## What you don't need to include

- **Your password.** Not for any reason. If we need to
  test the issue on your account, we'll do it through our
  own tools — and if we genuinely need fresh access for a
  third party, we'll ask for it on a per-case basis.
- **An apology for asking.** Asking is what we're here
  for; no need to soften it.
- **The full technical stack analysis.** A description of
  what you saw is more useful than a guess at what's
  broken underneath — that diagnosis is our job.

## How to send it

Whichever channel fits — see
[How to reach us](how-to-reach-us). For most things,
email is best because it leaves a written trail. Phone
when it's urgent and a quick conversation will get
further than a paragraph.