SOAP Builder: When your bid writing needs solution clarity and guidance from the start
A service that combines a focused workshop with expert design to help teams clarify, structure, and communicate their proposed solution in a single compelling graphic – a Solution On A Page.
There is a moment in most bids where things start to unravel.
Not because people aren’t trying. Quite the opposite. Everyone is busy. Everyone has opinions. Everyone is producing something. But ask the team a simple question: ‘what is the solution we are actually proposing?’ and you will get five different answers.
None of them are wrong. They are just incomplete.
Bids get into difficulty when the team does not have a clear guiding picture of the solution from the start. Win themes get written early, then quietly parked when the ITN arrives. Solutioning becomes reactive, shaped by deadlines rather than intent. Writers begin drafting without really knowing what the solution is or which messages need to land.
At that point, the bid stops being designed and starts being assembled.
The consequences are familiar. It becomes hard to convincingly articulate what you are offering, why you are different, and what value you actually deliver. Without an early reference point, people interpret the solution in different ways. Contradictions creep in. Alignment relies on meetings, memory and goodwill. Everything eventually comes together late, under pressure, through rework. We get it. We’ve been Bid Managers, so we understand the issues.
SOAP Builder was created to stop this happening.
The problem we kept seeing
Most bid teams do strategy work. Capture planning, win themes, value propositions, competitive analysis. None of that is new. The problem is what happens next.
That thinking rarely gets embedded into the solution itself. It lives in documents that are read once, then forgotten. Detailed solution design runs in parallel. Writing begins downstream with the assumption that the story will somehow emerge along the way.
By the time it does it is normally too late.
The issue is not effort. It is the lack of a shared picture that connects strategy, solution and narrative early enough to matter.
SOAP Builder exists to create that picture.
What SOAP actually is
A SOAP is a single, professionally designed visual that shows the shape of the proposed solution.
Not every detail. Not every technical component. The shape.
What are we offering? How does it fit together? Why does it win? How does it move the customer from where they are today to their desired future state?
It is created through a short, focused workshop that brings the right people into the same conversation at the same time. Not to design everything, but to agree what matters and how the solution should hang together. That thinking is then distilled into one page. From that point on, the bid has an anchor.
Why a single visual changes things
When teams have a shared visual of the solution, something shifts.
Conversations become easier. Differences of interpretation show up immediately instead of weeks later. Decisions speed up because people are working from the same reference point, not debating interpretations.
Writers stop guessing what the story is meant to be. Reviewers stop pulling in different directions. Consortium partners can see how their piece fits into the whole.
Most importantly, strategy stops floating above the bid and starts shaping it. Win themes, value, differentiation and evaluation criteria are baked into the solution from the outset, not layered on at the end.
This is why SOAPs get used. They are not produced to be filed away and forgotten. They are produced to be referred to throughout every stage of the opportunity. The result is less rework, fewer review cycles and a more controlled route to submission.
When an idea becomes something you can point to
One of the less obvious problems in bidding is how abstract everything is at the start.
Strategy is discussed in workshops. Value is described in language that sounds convincing but floats a little. Solutions exist as concepts in people’s heads, reinforced by hundreds of slides, notes and shared assumptions. Until the writing starts, much of the thinking lives in a theoretical space. This can be comfortable for a while. Then it becomes a liability.
When something is only discussed, it is easy to think there is alignment when there isn’t. People nod along. Everyone leaves the room believing they are talking about the same thing, when in reality they are carrying slightly different versions of the solution in their heads. Turning that thinking into a graphic changes the conversation. The moment an idea becomes visual, it becomes tangible. It can be pointed at. Questioned. Tested. Improved. Gaps show up. Overlaps become obvious. Assumptions get exposed. The solution moves from something imagined to something shared.
This is where SOAP comes into its own. The visual does not simplify the thinking. It makes the thinking real. It anchors abstract strategy in something concrete that the whole team can engage with, challenge and refine. It also creates a common language. Instead of explaining the solution again and again in different ways, teams can return to the same reference point and move the discussion forward.
Perhaps most importantly, a graphic makes it much harder to hide behind words. When the solution is visible, it has to make sense. The logic has to work. The story has to hold together. That discipline is invaluable early in a bid, when there is still time to change course deliberately rather than reactively. SOAP is not powerful because it is visual. It is powerful because it turns abstract intention into something real enough for the team to build around.
How a SOAP comes together
Every SOAP is built for a specific opportunity, but most follow a similar underlying logic.
At the heart of the SOAP is a clear picture of the future state. This is the moment that matters most. What success looks like once the customer’s problem has been solved and the solution is in place. It is where the intent, value and ambition of the proposal come into focus, not as a list of features, but as a tangible picture of a better outcome.
From there, the surrounding elements fall into place. The SOAP acknowledges the customer’s current situation and the realities they are operating within, enough to show understanding and context. Where it adds value, it may also show how the transition happens, how the move from today to tomorrow is made credible and achievable.
Supporting this are the core enablers. The capabilities, methods, platforms or partnerships that make the future state possible. These give the picture weight and reassure the reader that the solution is deliverable, not aspirational.
Crucially, the SOAP also draws out a clear, explicit set of benefits. These are stated plainly, not implied, so the customer does not have to infer where the value sits. They connect the solution back to what matters most to the customer and make the impact of the approach unambiguous.
Some SOAPs include additional elements. Some lean more heavily into certain areas than others. That flexibility is intentional. The aim is never to force information onto a page, but to shape a clear, coherent view of the solution that fits the opportunity and gives everyone a shared point of reference.
What happens in the workshop
We start by bringing everyone onto the same page. Not just on the opportunity, but on what the session is there to achieve. We spend time understanding the customer, their drivers and the real challenges sitting behind the requirement.
We then focus on the what, how and why of the solution. What does it actually deliver? How does it work? Why is it the right choice in this context?
Value, differentiation and added value are explored deliberately during the session, not left to chance or bolted on later. Because customers so often ask teams to demonstrate added value, we make space to surface it explicitly. By the end of the workshop, the team has a shared, concrete view of where the real value sits in the solution and how it strengthens both the approach and the story the bid needs to tell.
We take those outputs away and turn them into the first version of the SOAP, usually within a few days.
Why SOAP Builder exists
SOAP Builder was created because we kept seeing the same avoidable issues derail good bids. Not lack of skill. Not lack of effort. Lack of early clarity.
As bids become more complex, more collaborative and more scrutinised, that gap hurts more. Trying to fix alignment late in the process is expensive and exhausting. Fixing it early is surprisingly straightforward. SOAP Builder is our way of doing that. If there is one thing worth remembering, it is this.
Clarity should not arrive in the final days of a bid. It should be there from the start.
Interested in what we said, let’s talk about how you can start benefiting from SOAP.