Writing the proof of concept of a report

Without the proof of concept replication steps, there is no way that the team can recreate the scenario that you just created, so it is important that you list down the steps exactly as you replicated the vulnerability. You should always treat the program owner as a newbie when explaining the proof of concept to them. This way, you can list down all of the steps in a hierarchical manner. Having simple, easy-to-follow, step-by-step instructions will help those triaging your issue to confirm its validity at the earliest opportunity. For instance, if I identified an XSS vulnerability, here is what the replication steps would look like:

1. Go to the following [URL].
2. Log in using your username and password (you need an account to do this).
3. On the search box at the top-right, insert the following information:

<script>alert(document.domain);</script> 

1. Click the Lookup button.
2. You'll see a JavaScript popup box showing your domain.

The addition of screenshots as well as videos can greatly help the program owners to understand the vulnerability. Visual aids are always appreciated by the team. If the team is busy reviewing hundreds of reports in a day, it is possible that they may not even go through your report.

To give the program owner an idea about the severity of the flaw you found, you can show them how a malicious attacker could exploit the vulnerability you identified. You can describe a possible scenario and how and what the organization (and its clients) could lose by exploiting this flaw.