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. 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.