The Challenge

The Fort Nelson specification contained 219 individual service requirements. Those requirements covered everything from frequently repeated cleaning activities through to periodic and as-required tasks. MobiliseHQ identified 214 unique Service Area + Task + Frequency combinations, while retaining all 219 source requirements. Nothing from the original specification was discarded.

The frequency analysis identified:

The MobiliseHQ Approach

MobiliseHQ transformed the cleaning specification into a structured operational model. Instead of treating the tender document as a long list of cleaning instructions, each requirement could be understood in terms of:

This creates the bridge between the procurement specification and the contractor's commercial pricing model.

From Frequency to Workload

One of the most important stages is converting written frequencies into measurable occurrences. For example, MobiliseHQ identified 362 daily occurrences per year within the Fort Nelson service model. That allows the contractor to move beyond statements such as:

The same principle can then be applied across weekly, monthly, biannual and annual requirements. This creates a measurable annual workload rather than a collection of written instructions.

From Workload to Labour

Once the frequency has been established, the contractor can apply its own operational knowledge. For each activity, the contractor can determine how long the activity will take and how many operatives are required.

Occurrences × Duration × Number of Operatives = Annual Person-Hours

For example, if an activity occurs 362 times per year, takes 30 minutes and requires one operative:

This is where MobiliseHQ begins converting a tender specification into a genuine delivery model. The same calculation can be repeated across the specification to aggregate daily, weekly, monthly and annual labour requirements — and ultimately total contract labour hours.

TUPE Cannot Be Considered in Isolation

The Fort Nelson opportunity also demonstrates why pricing cannot simply be based on the existing workforce. Where TUPE applies, information about transferring employees is extremely important. But TUPE data answers one question — "What workforce may transfer to the incoming contractor?" — it does not necessarily answer "What workforce is actually required to deliver the new specification?"

MobiliseHQ allows the contractor to build the workload requirement from the specification first. The resulting labour requirement can then be compared against the TUPE information. This can help identify whether:

• the existing workforce appears sufficient;
• additional labour may be required;
• working patterns may need restructuring;
• there may be excess capacity;
• supervisory resources need to be considered; or
• the proposed service model needs further investigation.

This turns TUPE from something that is simply accepted as a tender cost into something that can be tested against the actual service requirement.

Labour Is Only the Beginning

A viable tender price cannot be calculated from wages alone. Once the operational workload has been established, the contractor also needs to consider the wider cost of delivering the Fort Nelson contract:

MobiliseHQ provides a structure for bringing these costs together rather than allowing them to remain disconnected across spreadsheets, tender documents and individual calculations.

From Cost to Tender Price

Once labour and additional operating costs have been established, the contractor can calculate the estimated annual cost of delivering the contract. The commercial process then becomes:

The contractor can then apply its required commercial margin. For example:

The figures above are illustrative. The purpose is not for MobiliseHQ to determine what the contractor should charge — its purpose is to allow the contractor to understand what its own assumptions mean commercially.

Testing Commercial Viability

This is where the model becomes particularly valuable before a bid is submitted. Suppose the contractor's detailed operational model produced an annual cost of £95,000 before profit. If the authority's indicative annual budget was approximately £90,000, that would immediately raise an important question.

The contractor could investigate:

• Are our productivity assumptions too conservative?
• Have we misunderstood part of the specification?
• Can the service be delivered differently?
• Are TUPE costs creating an issue?
• Is the authority's budget commercially realistic?
• Should we bid at all?

That is a far better position than discovering after winning the contract that the price submitted cannot support the required service.

Protecting Margin

The reverse is equally important. A contractor might initially believe it needs to bid £90,000 per year simply because that appears to be the authority's anticipated budget. But its detailed MobiliseHQ model might demonstrate that the contract can be delivered properly for £72,000. If the contractor automatically reduces its tender price to £75,000 in an attempt to be competitive, it could unnecessarily give away a substantial amount of potential margin.

MobiliseHQ therefore helps answer two different questions:

Those are not necessarily the same number.

Creating an Evidence Trail

The Fort Nelson model also creates something that is often missing from tender pricing: a clear explanation of how the price was reached. Instead of a final figure sitting at the bottom of a spreadsheet with little connection to the specification, the contractor can trace the commercial logic:

This provides a much stronger foundation for internal approval, pricing discussions and mobilisation if the contract is subsequently won.

From Bid to Mobilisation

The value of the model does not necessarily end when the tender is submitted. If the contractor wins Fort Nelson, much of the information required for mobilisation has already been structured. The contractor already has visibility of:

The tender pricing exercise therefore becomes the starting point for operational mobilisation rather than a spreadsheet that is forgotten once the procurement process ends.