The difference between a report that gets triaged in a day and one that rots in the queue for three weeks is rarely the severity of the bug. It's the first three paragraphs. Triagers are human, tired, and reading a hundred reports; you are writing for that person, not for a scoreboard. A good submission does their job for them.
Lead with impact, in one sentence
Open with what an attacker can do, to whom, under what conditions. "IDOR in the invoices endpoint lets any authenticated user read any other tenant's invoices by changing a numeric ID" tells the triager the class, the location, the precondition, and the blast radius before they've finished their coffee. Everything else is evidence for that sentence.
Make the reproduction impossible to get wrong
Numbered steps, exact requests, real-but-sanitized values. If the triager has to guess a header, a role, or the order of operations, you've added a round-trip and a day. Include the raw request and the raw response — the diff between "expected 403" and "got 200" is the whole report.
A report that reproduces on the first try gets fixed. A report that needs a follow-up question gets a lower priority and a slower clock.
Prove impact without crossing lines
Demonstrate the vulnerability with the minimum necessary access. Read one record you shouldn't, not the whole table. Screenshot the proof, redact the sensitive parts, and stop. Escalating "to show severity" turns a valid finding into a scope violation and torches your reputation with that program.
Rate it honestly
Attach a CVSS vector and explain your reasoning, but don't inflate. Triagers recalibrate constantly, and a submitter who consistently over-rates gets read with a discount. A calibrated reporter who says "this is a 5.3 and here's why" earns trust that pays off on the next, bigger find.
The bug is your ticket in. The write-up is what determines how fast — and how well — it gets resolved. Spend the extra twenty minutes on the first three paragraphs; it's the highest-leverage time in the whole engagement.