I was in a similar situation a couple years ago and budget requirements forced me to roll my own (crude) tool to handle this. I had a CSV of False-Positives, and another that contained 'Acceptable' vulnerabilities (i.e. those that could not be remediated for whatever reason). I wrote a Python script that took a list of exported CSVs and would filter vulnerabilities (vulnerability name and IP match) from the FP and Acceptable CSVs and then created a new CSV with the remaining vulnerabilities sorted based on CVSS. It wasn't ideal, but the few hours spent creating the script made up for the time spent immediately.
If you have the money, you should probably see if the Nessus SecurityCenter (I'm not familiar with the functionality personally) or another product has better vulnerability management capabilities.
I'm not sure if this hasn't always been in Nessus, but I know that now it will also report if a public exploit exists, as well as which framework it is in (Core, Canvas, and/or Metasploit).
Your remediation recommendations will often be based on common sense, but you'll get better at it as you gain experience. Especially since you're working in a single environment and not consulting with many clients. You'll quickly develop a feel for what is "normal" on your network.
Try not to overwhelm your IT team with recommendations. They're likely understaffed and overloaded as well, and a massive list of vulnerabilities to remediate will likely get ignored. Do what cd1zz mentioned and focus on the low hanging fruit at the onset. If you're just getting started, you'll like find areas where fixing one core issue will have significant impact (i.e. fully patching a system that fell through the cracks and is missing years of updates). If you're using PHP, Java, Adobe, etc., you'll also likely find that a single update will remove a lot of high/critical vulnerabilities from your list.
Other recommendations may strongly depend on your infrastructure. For example, if there are critical SMB vulnerabilities in a DMZ that only has HTTPS publicly available and administrators access that environment via an RDP jump box, those systems are probably at a lower risk of exploitation than if they were on a user network where anyone could download malware that tears through the other systems on the network. Obviously, an attacker may be able to do something through a vulnerable web app, but the DMZ systems would typically be at less risk of exploitation under normal circumstances.
Note, I'm not saying you should disregard those types of vulnerabilities entirely, just that there may be mitigating circumstances that lower their priority, and you can in-turn focus on others that are a higher priority. This will often be a judgment call on your part; I don't know of any guide or framework that assists with more detailed prioritization like this.
The day you stop learning is the day you start becoming obsolete.