1. A deep understanding of why the client is doing this project and how it delivers value to the client. Stating specific estimates of dollars this project can create/save or time/hassle it can save is a great thing to try and figure out and include. But be sure to state these are estimates and use large ranges. The goal isn't to be specific, just to illustrate the scope of the problem/opportunity. Most proposals DON'T have this. This alone will let you stand out from the crowd.
2. Understanding key stakeholders. Who will be involved in the project on the clients end and how will you bring them into the process in a way they'll be comfortable with.
3. Outline processes to get to success. What will the project look like from the day to day. How will you project manage? How will you communicate. What meetings will be needed? Will there be user testing? Who will do what - on your team and theirs?
4. Break up the project into larger chunks/variations. What is the smallest chunk that can deliver value ASAP. How can additional chunks be added in a modular, step by step approach that can bring value? Monolothic Yes/No proposals having a lower conversion rate than a "Menu of Options" the client can mix and match to their liking. Get creative!
5. What support options will you offer after the project ends? Will you disappear on them and leave them to fend for themselves? Will you train their team? Will you help them hire/transition to internal tech teams?
6. Include case studies for clients you've done something similar for before. This de-risks the project from the clients end and a big part of vendor decision making is de-risking.
So my speccing process is asking a bunch of really specific and pointed questions so I can make a great proposal. Sometimes I send them an online survey to fill out before our first speccing meeting. Sometimes it's just a meeting. But I've honed a long set of questions over time that get me the answers I need to write a great proposal. Then really listen to answers to those questions.
Somebody in this thread asked if I make wireframes in my speccing process. I prefer a collaborative whiteboarding session in the speccing meeting if it will help flesh out what the project is. It's much more fun and allows you to demonstrate your ability to work with them and incorporate their feedback on the fly.
But your proposal should be more about the problem you're solving and how you're going to solve it than about the lines of code/screens you're going to create. Don't be a craftsperson. Be a problem solver!