A Stage-Gated, Auditable Bid Process Designed for a Defence and Space Contractor

#The starting position

Bidding for defence and space programs is unlike most selling. Opportunities are large, long and heavily governed. A bid passes through formal gates where senior people decide whether to keep investing in it, and each gate requires a clear view of the risks, the commercial terms, the payment milestones and the documents behind them. Decisions have to be recorded and defensible. Information about one program often cannot be visible to people working on another.

The contractor in this engagement works across defence systems and space, two divisions with their own programs, people and sensitivities. It already had Salesforce, but the org had not been shaped around this way of bidding. Gate preparation, approvals, risk and milestone information, and the link between a bid and its documents in SharePoint were not brought together on the bid record. A process like that can work through effort and experience, and it is hard to audit, slow to prepare for each gate and dependent on the people who know how it really runs.

The contractor engaged us, through its implementation partner, to review the existing Salesforce system and design how it should support the bid process properly.

#What we designed

01 An org review

We started by reviewing the existing Salesforce org: how opportunities, accounts and users were set up, what customizations existed and where the current configuration fell short of the bid process. The review set out what to keep, what to change and what to add.

02 A bid framework with formal stage gates

The design models each bid as an opportunity that moves through formal stage gates, configured in Salesforce to match the contractor's governance. Each gate defines what must be true before a bid can progress.

03 Risk register and payment milestones

Each bid carries a structured risk register and its payment milestones, so the information decision-makers need at a gate is held as data on the bid instead of in separate spreadsheets.

04 An approval matrix with status write-back

The approval matrix decides who must approve a bid at each gate, depending on the bid's characteristics. The design runs the matrix through Power Automate, because the contractor's approvers work in Microsoft 365, and writes the approval status back to the opportunity in Salesforce. The bid record always shows where a decision stands.

05 One-click gate packs

The presentation reviewed at each gate is generated in one click as a PowerPoint from the Salesforce data. The design removes the hours spent assembling slides and, more importantly, makes sure the pack matches the record it describes.

06 SharePoint links and document handling

Bid documents remain in SharePoint, where the contractor manages them, with links from the bid in Salesforce. The design covers how documents are created, linked and found, so anyone reviewing a bid can reach its documents directly.

07 Division-level access, reports and feedback

Access is designed at division level, so defence systems and space bids are visible only to the people entitled to see them. The design also covers reports for leadership, the record of interactions with customers and partners, and a way to capture feedback after gates and outcomes.

#How a bid would move through the design

A business development lead in the space division opens a new opportunity for a program. Only people with access to space division bids can see it. Over the following weeks, the team builds out the risk register and the payment milestones as they learn more.

When the bid reaches its first formal gate, the lead generates the gate pack in one click. The PowerPoint pulls the bid summary, risks and milestones straight from the record. The approval request goes to the right approvers through the matrix in Microsoft 365. They review the pack and approve, and the status is written back to the opportunity, which moves to the next stage.

At any point, a director can open the bid and see its current gate, every approval decision, its risks and milestones, and links to every document in SharePoint. If an auditor later asks how the decision to proceed was made, the answer is on the record.

#Why design comes first on a bid process like this

It is tempting to start configuring stages and fields straight away. On a governed defence bid process, that tends to produce a system that mirrors today's habits rather than the governance the business needs. The cost of getting gates, approvals and access wrong is high: a gate that can be skipped, an approval that is not recorded or a program visible to the wrong division undermines the whole purpose.

A detailed design settles those questions before anything is built. It defines the gates and what each requires, who approves what, how documents are handled, and who can see which bids. It also identifies the integration points with Microsoft 365, which are central to how this contractor works, and makes sure the approval and document flows complete the loop back to Salesforce.

#Integrating Salesforce with Microsoft 365

The contractor works in Microsoft 365. Its approvers work in Microsoft 365, and its bid documents live in SharePoint. A design that asked everyone to move into Salesforce for approvals and documents would have met resistance and duplicated what already works.

The design instead treats Microsoft 365 as part of the solution. The approval matrix runs in Power Automate, close to the approvers. Documents stay in SharePoint, close to the people who write them. Salesforce remains the system that knows the state of every bid: which gate it is at, what has been approved, what the risks and milestones are, and where its documents are. The integration points are designed so information flows in the right direction: approval outcomes come back to Salesforce, document links are stored on the bid, and gate packs are generated from Salesforce data.

#How we approached it

Review before redesign. The org review established what already worked and what had to change.

Gates as the backbone. The framework was designed around the contractor's formal gates, with data, approvals and documents attached to them.

Meet approvers where they work. Approvals were designed for Microsoft 365, with status written back to Salesforce.

Documents stay in SharePoint. The design links to documents rather than duplicating them.

Access by division from the start. Visibility rules were part of the design, not an afterthought.

Two phases, clearly scoped. The engagement was scoped as two phases totaling about 293 hours. This study describes the design; implementation of the full scope is a separate step.

#The decisions that mattered

Generated gate packs. Producing the gate presentation from the record removes manual effort and keeps the pack consistent with the data.

Approval status written back. Running approvals in Microsoft 365 only works if Salesforce knows the outcome; the write-back makes the bid record complete.

Division-level visibility. Separating defence systems and space bids reflects how the contractor must protect program information.

#What the design changes

#What we would tell a defence or aerospace contractor starting this

Design your gates before you configure your org. Decide what each gate requires, who approves it and what evidence must exist, then make the system produce the gate pack and record the decision automatically. Connect approvals and documents to the tools your people already use, write every outcome back to the bid, and set visibility by division from day one. The aim is a bid process that runs faster and can explain itself to anyone who asks.