There are two issues, which need disentanbled.
Stop quoting in time, start quoting in dollars. This quickly allows them to do a cost / benefit analysis, and allows you to add a standard "time to analyze" quote. Time is too sticky, because it doesn't reflect the real amount of work done (forty hours could be done in a day, five days, or three weeks), and it is far too easy to not push the budgeted release cycle back for such a request.
Provide the sales staff a request input into the dev cycle (preferably a non-human interface, to save time (measured in money)).
Sales people tend to think in terms of (if I have X, I can close this sale). Their requests are often not coherent with the current architecture of the product, but they are coherent with the current need of a customer.
Indicate to the sales force that such requests are vital for your product, and as such, you need to not lose them in the "quick request, will take longer than the period of interest, drop the request, repeat" cycle. Such requests need to be captured, analyzed, prioritized, integrated into the product, tested, and released with the next release cycle.
Then back up your words with actions. Shorten the release cycle to under two months, indicate which items are going to be in the release, and hit your deadlines. Don't educate the sales staff about the internal reasons this is necessary, just do an analysis of what an out-of-cycle request minimally costs (in dollars), and what the risk (extra dollars and percentage of occurrence) it could cost if a problem exceeds minimal complexity. Then ask the sales person if the sale is large enough to support the out-of-cycle request.
Once they have a process for an in-cycle request, and they have an idea of how much it costs to handle an out-of-cycle request, odds are good that you can convert their out-of-cycle request into an in-cycle request, or determine that the out-of-cycle request is profitable enough to justify the expense.