From portfolio strategy to the bid desk

How a CTO used SmoothOperator.ai to turn a portfolio-wide AI strategy into better bid decisions, with a system built to judge whether a tender fits the business, not just to find it

Every AI strategy has to land somewhere. At board level, the right output is wide and strategic: where AI fits across the business, what it should change and how far to go. The work gets harder as that strategy is translated, level by level, into operations. It has to become a specific workflow, with specific inputs, that changes a specific decision someone makes on an ordinary Tuesday. That translation, from the summit to the workbench, is where AI ambitions most often lose momentum. It is also where SmoothOperator.ai is built to work.

At a glance

Client: An investment and active ownership company with holdings in several industries. This use case served its infrastructure business, which works on manufacturing plant infrastructure, welding and civil works.
Use case: Qualifying public tenders: finding relevant opportunities, judging fit, and deciding where to spend bid preparation effort
What we built: A working prototype that retrieves public tender notices, scores them and produces three review outputs: a go or no-go memo, a scoring workbook and a pipeline briefing
Runs on: Public tender data for the prototype; Private AI planned for production
The challenge: finding tenders is easy; judging fit is the hard part
The Board had set a broad AI agenda across the portfolio. The CTO’s task was to turn it into something operational, starting with a use case that would make sense at every level: as a step in the strategy for leadership, and as a better way to do real work for the teams.

For an infrastructure business, public tenders are a natural choice. Plant infrastructure, welding and civil works are won largely through public procurement. The flow of notices is constant, bid capacity is limited, and every bid prepared for the wrong opportunity takes effort away from the right one.

Finding tenders was never the real problem. The problem is judging fit, because fit is where two things meet. On one side are the tender’s requirements, often spread across specifications and annexes. On the other is what the company can do, has done and is willing to commit to, recorded across policies, capability records and years of past proposals. Both sides are deep, and the decision depends on connecting them. That is why the teams would judge any system against a demanding set of questions:

Does it bring forward the tenders that matter to us, not just keyword matches?

Does it judge fit against our policies, capabilities and track record?

Can the bid team see why a tender scored as it did?

Does the go or no-go decision stay with our people?

Will our proposals, pricing and policies stay under our control?

Can we reuse it for the next decision, and the next company in the portfolio?

The approach: from summit to workbench, one level at a time

Comparing the options openly. We started with the strategy, not the technology. We structured the ambition into alternative implementation roadmaps, alongside the options already on the table: traditional technologies the business had in place and alternative proposals. With these side by side, the CTO chose a phased approach built on business workflows. Tender qualification became one of its proof-of-concept use cases.

Involving the right people at each level. The CTO was the channel into the business. The people who screen tenders and prepare bids took part at the stages where their judgement mattered. That kept the workflow grounded in how opportunities are actually assessed, not how a strategy document imagines they are.

Building what the business had only imagined. The team knew how it wanted opportunities scored but had never built it. We turned that intention into a working workflow. The prototype retrieves public tender notices and supports searches by activity category and date range, so the flow of opportunities is filtered before anyone has to read it.

One evaluation, three levels of detail. The prototype produces three outputs from the same evaluation. The go or no-go memo supports the decision on a single tender. The scoring workbook shows the bid team how each score was reached. The pipeline briefing gives leadership the overall view across opportunities. The strategy moves down the organisation, and the information comes back up in the form each level needs.

Tender search by category and period. Anonymized interface example.

Go/no-go memo selection and context. Anonymized interface example.

Scoring workbook selection and context. Anonymized interface example.

Pipeline briefing selection and context. Anonymized interface example.

Making it about this business. Generic principles can tell you whether a tender is well formed and broadly attractive. Only the company’s own knowledge can tell you whether it fits. We identified the inputs that make the difference: company policies, past proposals and information about the company’s capabilities.

How the platform answers the business’s questions

The business asks	How the platform answers	Pillar	In the prototype
Does it find the tenders that matter?	Connects to public tender sources and filters by activity category and date range before anyone reads a notice	5 · Integration layer	Built
Does it judge fit against our business?	Takes in policies, capability records and past proposals as a curated knowledge base that every evaluation draws on	1 · DataStudio	Inputs identified
Can the bid team see why?	Links each score to the requirement, policy, capability or past proposal behind it, and checks it against the company’s criteria	3 · TruthFlow	Scoring on generic principles
Is every tender scored the same way?	Each notice goes through the same steps, criteria and checks, and the result is presented at the level of detail each reader needs	2 · MetaBuilder	Built
Does the decision stay with our people?	The go or no-go decision passes through an approval gate, with an execution trace and an audit log	Guardrails & Oversight	Designed in
Do proposals and pricing stay under our control?	Models isolated from outside networks, deployed inside the company’s perimeter; no prompt or document leaves the network	4 · Private AI	Planned for production
Can we reuse it?	The same foundation serves the next use case and the next portfolio company, each with its own knowledge	The platform	—

The prototype ran on public tender notices, which carry no confidentiality risk. The knowledge that makes evaluation specific to the business is a different matter: past proposals, pricing and internal policies are among the most sensitive material a company holds. That is why production is planned on Private AI.

Why not just…?

The CTO weighed real alternatives before choosing this approach, and any company facing the same decision will ask the same questions.

…keep using tender alerts and portal searches? They do what they promise: they tell you a tender exists. Our workflow starts the same way, with searches by category and date. But alerts stop where the real work begins. Someone still has to read each notice, check it against what the company can deliver and decide whether it is worth a bid. That reading is the bottleneck the business wanted to remove.

…ask a general-purpose AI assistant? An assistant can summarise a tender well. Judging fit is a different task. It means checking the tender’s requirements against policies, capabilities and years of past proposals, consistently, across a constant flow of notices. When knowledge is both wide and deep, standard retrieval returns what looks similar, not what is logically connected. It gives no guarantee that every requirement was weighed, and no guarantee that two tenders were scored by the same criteria. A bid team can’t compare scores that weren’t produced the same way.

…build it in-house? The interface is the easy part. Behind it, someone would have to build and maintain the knowledge pipeline, structured retrieval, scoring validation, permissions, audit logging and private model hosting. The result would be a tool for one purpose, and the next use case would start again from scratch.

…start with a company-wide AI programme? Board-level ambition is the right place for the strategy to begin. A programme that starts wide often struggles to reach the desk where decisions are made. A phased approach proves the value in one decision the business recognises, on a foundation that every later use case reuses.

What the prototype delivered

The prototype turned tender qualification from a theory into a working process: retrieval, search, scoring and three review outputs. It gave the CTO something concrete to assess and the teams something concrete to react to. In the prototype, evaluation applies generic principles. The platform is designed to replace those with the company’s own knowledge, so recommendations reflect how this business wins work.

The prototype also produced a defined list of the company knowledge needed for tailoring. Most AI initiatives stall because nobody can say exactly what the system needs to know about the business. This one can.

Why this matters

For CTOs, tender qualification links AI investment to a commercial decision everyone recognises: which opportunities deserve bid preparation effort. The Board sees a step in the strategy, the teams see it in their working week, and the CTO can show a working process instead of describing a future one.

For tender-driven industries such as construction, plant infrastructure, engineering services and public works, the need is the same everywhere. There are too many notices, too little bid capacity and too much riding on choosing well. What differs is each company’s knowledge, and that is exactly the part the platform is built to take in.

For investment and active ownership companies, improving how portfolio businesses operate is the job itself. The same foundation serves every business: knowledge preparation, workflow building, links to evidence, governance and Private AI. Each company brings its own policies, history and decisions, and each new use case builds on the last.

We work as a boutique team: senior, close to the people who make the decisions, and focused on one workflow at a time until it earns its place.

From strategy to workflow: how an engagement runs

Structure the ambition into alternative roadmaps and compare them openly with the technologies and alternative proposals already on the table.
Pick a first use case tied to a recognisable business decision, and involve the people who make it.
Build what the business has wanted but never had, and prove it on available data.
Name the company knowledge required: the policies, history and capabilities that make recommendations specific to your business.
Move to production on the right infrastructure, using Private AI when that knowledge is commercially sensitive.

Is your AI strategy still at summit level?

If your organisation has the ambition but not yet the first workflow, let’s find the decision where AI can start earning its place.

Start a conversation ↗