Support logs an issue and keeps the conversation about it together, rather than scattered across email. Replies land on the request itself, so anyone picking it up later reads the whole thing in order.

It goes to the people who build the product, not to your own administrators. Raising one notifies the product team directly, which is the right route for something the software is doing wrong — and the wrong route for "who covers Thursday". Notifications about the thread afterwards reach the person who raised it and anyone who has posted on it; nobody else in your organisation is told, and there is no assignee to chase.

Category and sub-category are how it gets to the right people — they are not labels for tidiness, they route it. A request in the wrong category waits for the wrong team to notice it.

Write the detail for someone who has never seen your screen: what happened, what you expected instead, and what you already tried. Screenshots and files can be attached. Do not attach passwords, access tokens, or client and personal information you do not need — redact a screenshot before it goes on.

Requests move through Open → In Progress → Resolved → Closed, and can be Cancelled. A closed or cancelled request stops taking replies, so raise a new one rather than trying to reopen a conversation that has ended.

Setting the priority honestly matters more than setting it high. Creating a request records the issue; it is not a response-time commitment.

Step 1
Open Support
Support in the side menu, then New Request.
Step 2
Categorise it
Pick the category and sub-category that fit. This is the routing, so it is worth a moment's thought — a category is required before the request will submit.
Step 3
Write the subject
Short and specific. This is the line somebody scans in a list of thirty, so "Shifts not showing for Tuesday" beats "Problem".
Step 4
Describe the problem
What happened, what you expected instead, and what you already tried. Attach a screenshot or a file if it helps — redacted.
Step 5
Set the priority and create it
Priority runs Low, Medium, High, Urgent. Set it for what the impact actually is; marking everything Urgent removes the signal from the ones that are.
Step 6
Follow it
Replies land on the request. You will hear about updates, replies and a resolution because you raised it — as will anyone else who has posted on the thread. Somebody who has not is not notified, so if a colleague needs to see it, get them to reply rather than assuming they can see it happening.
Step 7
What the statuses mean
Open is raised and unclaimed, In Progress means somebody is on it, Resolved means they believe it is fixed, Closed ends it. Cancelled is for requests that should not have been raised. Closed and cancelled requests do not accept replies — if the problem comes back, raise a new request and reference the old one.
Step 8
What not to put in one
A support request is read by people outside your immediate team. Keep credentials out of it entirely, and include client or personal details only where they are genuinely needed to reproduce the problem — a client's initials and a date usually are enough. The same goes for screenshots: what is in the corner of the window goes with it.