I think that adding in a more complex setup isn’t going to fill in the gap in your business, which is project management. I have never personally known a development firm that had to tie sales incentives to developer productivity in order to keep projects moving effectively.
Also, you are almost 100% certain to create a devastating conflict of interest if you put sales and tech in the ‘same boat’. Those two need different boats! Imagine if sales brings in a 100k project. Tech approves of the cost/schedule. Everything is great, until sales brings in a 12k change order which they liked but refused to bump the schedule to accommodate the changes. The project slips, and the client is unhappy which makes sales unhappy. Sales leans on tech, and you get this:
sales: “We need this to be done by Jan 15!!”
tech: “Well, we could have if you didn’t increase scope on us”
sales: “Well, we have to find a way to make it work!”
tech: “The only way to make it work is for us to work 24/7 to accommodate your lack of concern for the scope creep. This always happens!”
etc. etc. 
However, I have heard time and time again that sales as allowing too much scope creep and tech is not able to keep up. That classic problem is best solved by adding the needed management into the middle.
A good project manager builds a bridge between sales and tech - encouraging sales to help contain scope creep and encouraging tech to support sales with good pricing and scheduling estimation.
If there is a ‘gap’ there, it will be hard to systematize a solution through some sort of financial incentive. Having managed many hundreds of technical resources (literally) my observation is that they are very different when it comes to management than sales, and don’t respond to simple financial incentives in the way that you’d expect.
Why not go the traditional model and see if you can find ways to improve the team, company, and project management so that you can help out these problems?
One easy policy is to simply stop allowing sales to ‘approve’ change requests. They will always screw the developers. As a result, the developers become defeated and lose any motivation to bring projects on time as they are generally thwarted. Sales should only close a deal using pricing that was approved by a project manager who coordinated with the tech lead. Change orders should be the same way. This empowers developers as they have a bit of say on what is reasonable and what isn’t.
Another policy is to use a simple review/bonus approach to optimize you developer output. There is a BIG difference between getting a ‘cut’ and getting appreciation and a bonus. Developers ultimately love development more than money, time and time again. They thrive on having a voice, innovation, doing things ‘right’, etc. Having a real review session with developers and using that session to determine their raises, positions, bonuses, etc. is a proven model.
If you aren’t able to keep with the projects because they are too numerous/small, perhaps you could look at some ways to improve on this. Perhaps you could hire on a project manager - a good one can radically change your business success. Or maybe an assistant for you. Or, invest in an extranet or other system to help systematize management (although there are limits to this).
You could also look at the long-term outlook and discuss with your partners how you might evolve the business so that it sees longer, more lucrative clients with better margins - lowering management drag while increasing profits.
Back to basics, I say! 