You do not need a diagram, a ticket export, or a polished brief. Both doors — the intake on the homepage and the form — are there so you can describe a problem in ordinary language. I read what you choose to send. I do not read a transcript you never submitted. I answer inside a business day, and if it is a fit the next step is one introductory call.
Three things that make the brief useful
Say what you are trying to get done. An audience someone can mail. A report that finishes. A customer list that stops contradicting itself. An estate of packages you want to move without a cutover weekend. The outcome is the thing I scope against.
Say what is in the way, in your words. Duplicate customers. A score nobody trusts. A model that only refreshes when someone remembers. A license that is not doing any work yet. You do not have to diagnose it. The stuck point is enough.
Name the systems if you can, at the level of a category: CRM, point of sale, ecommerce, email, ERP, finance. Those names tell me which history exists. They do not have to be a vendor inventory.
What to leave out
Do not send passwords, tokens, connection strings, or a customer file. I will not ask for them in a first exchange, and a note that arrives with them is more than I should be holding before we have agreed there is work. A sentence about the shape of the data is more useful than an export.
If you would rather not use the terminal, the form asks the same questions. Either way, nothing is sent until you choose to send it.
Start with the intake, or use the form if you already know what you want to say.