Case study 01 / Procurement & operations
From opportunity
to informed review.
A growing tender-intelligence workflow: public-source discovery, business-specific relevance checks, document research and indicative BOQ pricing. Built for a plant-hire and civil-works context.
Finding a notice is
only the beginning.
A tender can look relevant by title and still be unsuitable in scope, geography, eligibility or commercial terms. The project brings discovery and assessment into a more structured process, so the next person sees the opportunity, the supporting evidence and the unanswered questions together.
The work has involved researching the operating context, refining a relevance profile, navigating procurement sources, examining accessible tender material and developing an indicative priced example. The aim is a better starting point for a decision—not automatic bid submission.
Five connected stages.
Each stage produces something the next stage can use. Some parts run as code; others remain research and review tasks.
Discover
Scan public eTenders listings, follow source references and check the actual notice rather than relying on a search snippet.
Match
Compare the scope with a working business profile. Distinguish direct fit, conditional fit and possible subcontract packages.
Understand
Review accessible documents, deadlines and requirements. Flag missing evidence instead of treating relevance as proof of eligibility.
Develop the pricing view
Use quantities and historical rate guidance to build an indicative example, checking units, inclusions and provisional allowances.
Report for review
Bring the source links, reason for fit, open checks and next steps into readable outputs. Commercial approval remains with a person.
The detail behind
the headline number.
A bill of quantities (BOQ) breaks a package into measurable items. I’ve worked with a historical rates workbook and developed an indicative priced example, using spreadsheet and PDF outputs to make the assumptions reviewable.
The important work is understanding what a rate includes. Plant and labour, materials supplied by others, specialist items, transport and markup cannot be treated as interchangeable. A missing rate is a question to resolve, not a zero.
| Item | Unit check | Pricing question | Review outcome |
|---|---|---|---|
| Excavation | Volume / quantity basis | Plant and labour included? | Check inclusions |
| Imported material | Volume or mass | Supply and haulage allowed? | Confirm quotation |
| Specialist package | Defined scope | Specialist input available? | Provisional until reviewed |
| Preliminaries | Project-specific basis | What is already in the rates? | Avoid double counting |
No client quantities, rates or prices are shown. This is a simplified illustration of the review method.
Historical rates need context, escalation checks and current commercial input. The example does not establish an approved rate card, margin, profitability, capacity or bid readiness.
Different portals.
Different constraints.
eTenders
The cloud reporting path scans public publication-window listings. Pagination, stable references, notice dates and overlapping look-back windows help make collection repeatable. The relevance profile adds context beyond a broad keyword match.
Documents, amendments and qualifications still need review. A public listing scan cannot establish complete coverage of every change to an older competition.
SupplyGov
The research has included its supplier workflows, framework and DPS routes, and the distinction between public opportunities and private invitations. Access and membership affect what can actually be seen.
Private invitation coverage and persistent unattended access are not established. SupplyGov is a researched part of the wider workflow, not a claimed complete cloud integration.
Portal research is read-only. The workflow does not change supplier profiles, join frameworks, express interest or submit responses.
A workflow that can
outlive the laptop session.
GitHub Actions runs the public scanner, compares observations with stored history and produces HTML, Markdown and JSON reports. Preview, rehearsal and production histories are separated so testing does not overwrite production observations.
Manual cloud runs and a scheduled production scan have succeeded. Scheduling also exposed an operational lesson: a configured time is not a guarantee of exact-time execution. Diagnostics, catch-up windows and clear incomplete-scan reporting matter as much as the happy path.
Demonstrated
- Public-source cloud report generation.
- Observation history and change classification.
- An indicative BOQ pricing example.
- Source-specific relevance and research.
Still developing
- Evidence of repeated scheduling reliability.
- Broader amendment and invitation coverage.
- Production Gmail authorization and delivery.
- Verified delivery history before automatic email.
Where I’m taking it
A connected research and review workflow that brings opportunities, evidence and commercial questions together. The next steps are carefully scoped integrations and more operational verification—not removing the human decision.
I’m exploring Google Cloud developer tooling and OAuth for future Gmail integration. Email sending remains disabled. Read the integration and data-use notes ↗
Good automation needs
good boundaries.
Relevance is different from eligibility. A rate is different from a final price. A successful run is different from a reliable service. This project has been a practical education in keeping those distinctions visible while building something useful.
Next in the collection