Procurement intelligence vs manual monitoring is a workflow decision, not a contest over who lists more portals. Your team needs relevant opportunities early enough to decide whether to bid, with a manageable review workload and a reliable handoff to an owner.
Keep the current process if it does that job. Pilot a tool if you can name a specific failure to test. Buy only when the pilot meets your operational requirements and the costs fit an explicit budget. This guide gives a bid manager and budget owner a shared decision worksheet; it does not claim results for Duke or any other vendor.
Start with the failure you need to fix
Write one sentence before requesting a demo: “We need to improve ___ for ___, measured by ___, without increasing ___.”
For example: “We need to find relevant maintenance lots before our internal review cut-off, measured against our agreed buyer/source sample, without adding more than two hours of review each week.” This is an illustrative requirement, not a recommended universal target.
Choose the next step from evidence you already have:
| Current evidence | Sensible next step | Decision artifact |
|---|---|---|
| Relevant notices arrive in time; a named person reviews them; workload is acceptable | Keep manual monitoring and maintain a backup owner | Documented source list and review schedule |
| Searches are inconsistent, duplicates fill the list, or nobody owns follow-up | Repair the process before comparing tools | One search brief and deduplicated review log |
| A repeatable discovery or handoff problem remains after that repair | Run a bounded side-by-side pilot | Pre-agreed sample, measurements and acceptance criteria |
| Pilot requirements pass and the business case fits the budget | Consider buying, subject to contract and exit checks | Signed decision record with cost assumptions |
| Sample is too small or the vendor cannot demonstrate a required source/workflow | Extend the specific test or decline | Unresolved questions, owner and next review date |
“Manual” need not mean repeating every search by hand. TED supports saved searches and scheduled search alerts for signed-in users; include the tools you actually use in the baseline. Do not compare a configured paid service against an artificially weak manual process. See TED’s official search-results help.
If your baseline is not documented, first build a monitoring brief around classification, geography and buyers.
Run the same test on both workflows
Choose a fixed observation period that includes representative work. Two working weeks can be a starting point, but extend it if notice volume is too low or a seasonal gap makes the comparison uninformative. This is a test design suggestion, not evidence of a typical payback period.
Before starting, record:
- Scope: services you can deliver, geographic constraints, relevant classifications, target buyers, exclusions and minimum time needed to prepare a bid.
- Opportunity unit: use the same unit on both sides, such as a procedure plus relevant lot. An amendment is an update to that opportunity, not another potential contract.
- Source sample: named official sources and buyers, date window, notice stages and any inaccessible sources. Keep original notice links and identifiers.
- Timing: original publication time where available, discovery time, review time and internal cut-off. Mark unavailable timestamps as unknown.
- Decision: relevant, irrelevant or unresolved, with a reason and reviewer. Use the same criteria for both workflows.
- Effort: search, deduplication, initial qualification, correction of errors and handoff, measured in non-overlapping time entries. Record setup/training separately.
Keep the manual process running during the pilot. Record each workflow’s discovery before merging the results, so a notice copied from one into the other is not credited twice. Review disputed relevance decisions without relying on a vendor score as the answer.
Measure observed discovery, not “market coverage”
Checking four of fifteen portals says how many portals you checked. It does not establish that you found 27% of relevant opportunities: the sources may overlap and their relevant volumes may differ.
Create a deduplicated reference set from both workflows plus an independent check of the agreed official-source sample. Then report:
| Measure | Calculation | What it cannot establish |
|---|---|---|
| Relevant discovery within the test | Relevant opportunities found by a workflow ÷ relevant opportunities in the reviewed reference set | Recall across the entire market; both workflows can miss the same opportunity |
| Timely discovery | Relevant opportunities found before your cut-off ÷ relevant opportunities in that reference set | A universal acceptable delay |
| Review precision | Relevant opportunities ÷ all opportunities reviewed from that workflow | Completeness; a very small list can look precise while missing work |
| Incremental relevant discoveries | Relevant opportunities found only by the candidate workflow, after deduplication | Additional bids, wins or revenue |
| Review effort | Recorded search, triage, correction and handoff hours | Cash savings unless spending actually changes |
Always show numerator, denominator, observation period and unresolved cases. If there are no relevant opportunities in the sample, discovery-rate measures are undefined: do not report a perfect score. Investigate important misses individually instead of hiding them inside an average. Use the procurement metrics guide to keep definitions consistent.
Build a cost worksheet from your inputs
Use one period, currency and tax basis throughout. Ask the budget owner how to treat recoverable taxes and internal labour. Include monitoring work that remains after buying; do not assume all current effort disappears.
| Input | Your value | Evidence to attach |
|---|---|---|
| Manual workflow hours per active week, Hm | ___ | Baseline time log |
| Candidate workflow hours per active week, Ht | ___ | Pilot log, including alert review, corrections and residual portal checks |
| Active monitoring weeks per year, W | ___ | Team schedule; do not automatically assume 52 |
| Internal hourly cost for capacity valuation, R | ___ | Finance-approved rate; split by role if rates differ |
| Recurring external cost, P | ___ | Written price for required seats, sources, exports and support |
| One-off external implementation cost, S | ___ | Quote, including migration or integration work |
| One-off internal setup/training hours, T | ___ | Logged or explicitly estimated work, excluded from Ht |
| Actual annual avoidable cash spending, A | ___ | Identifiable overtime, contractor or other spend that will cease |
Calculate these separately:
Hours released per year = (Hm - Ht) × W
Indicative released-capacity value = (Hm - Ht) × W × R
First-year external cash cost = P + S
First-year cash impact = A - P - S
Negative hours released means the candidate adds workload. Released-capacity value is not cash in the bank. If salaries stay the same, do not present those salaries as avoided expenditure. Name the work the released hours will fund and who will check that it happened.
An optional capacity-valued comparison is released-capacity value - T × R - P - S. This is a planning comparison, not realised profit. For multiple roles, calculate the labour terms separately at each role’s rate. Do not add the cash-impact result to it: cash savings may value the same hours and the costs would be counted twice.
Illustrative worksheet: a pilot does not automatically justify a purchase
The following numbers are invented solely to demonstrate arithmetic. They are not customer results, vendor prices, salary benchmarks or expected savings.
Assume Hm = 12 hours/week, Ht = 7, W = 46 weeks, R = €40/hour, P = €6,000/year, S = €1,200 and T = 20 hours. Assume no spending is actually avoided, so A = €0.
- Hours released:
(12 - 7) × 46 = 230 hours/year. - Indicative capacity value:
230 × €40 = €9,200/year. - First-year external cash cost:
€6,000 + €1,200 = €7,200. - First-year cash impact:
€0 - €7,200 = -€7,200. - Optional first-year capacity-valued balance:
€9,200 - (20 × €40) - €7,200 = €1,200.
This is not a claim of positive cash ROI: the organisation spends €7,200 and expects to release 230 hours, while also using 20 internal hours for setup. Buying would require a credible use for that capacity, operational benefits that pass the pilot, and an approved budget.
Test a downside case before deciding. If only three hours per week are released, annual capacity value becomes 3 × 46 × €40 = €5,520; the same first-year capacity-valued balance is €5,520 - €800 - €7,200 = -€2,480. The cash impact is still -€7,200. Replace these inputs with measured ranges; do not select only the favourable case.
Keep revenue out of the base case
Finding another relevant notice is not winning a contract. A bid may be declined, lose, be cancelled or create delivery obligations your team cannot meet. An award value is not necessarily revenue earned within your evaluation period.
Start with zero incremental revenue benefit in the monitoring-tool decision. Track candidate-only discoveries through the same bid/no-bid assessment as everything else.
If you later build an upside scenario, label it separately and document incremental bids, an evidence-based win-probability assumption, expected revenue within the chosen period, delivery costs and additional pursuit costs. Contribution means revenue less the attributable costs you specify; it is not revenue and need not equal net profit. Have finance approve the definition and any overhead allocation.
Do not add gross pipeline value, probability-weighted revenue and contribution together. They are different views of the same potential work. Do not also count released hours as a second benefit if those same hours are already included in the scenario’s extra bid activity without accounting for their use. Keep observed pilot results separate from this uncertain upside.
Ask vendors to demonstrate the requirements you actually have
Use the same sample for each candidate. Request evidence rather than assuming the label “procurement intelligence” guarantees a feature.
| Requirement | Demonstration to request |
|---|---|
| Your target sources and notice stages | Retrieve named examples and explain missing records or stages |
| Relevant lots and updates | Show your example lot, its source link, amendments and current deadline |
| Reviewable recommendations | Explain why a sample result appeared and let your reviewer inspect the underlying notice |
| A workable handoff | Complete your actual assignment/export step with the intended users and permissions |
| Buyer or award context, if needed | Trace sample claims back to records; distinguish unknown values from zero |
| Predictable cost and exit | Obtain a written quote, renewal/cancellation terms and an example usable export |
These are evaluation requests, not statements that Duke or every platform offers them. Use the platform evaluation guide for a broader shortlist; use this worksheet to decide whether changing the workflow is worthwhile at all.
Finish with a one-page decision
Copy this into your team’s decision record:
Decision: keep manual / repair manual / extend pilot / buy
Workflow problem and owner:
Scope, observation dates and source sample:
Required results agreed before the pilot:
Observed results, including misses and unresolved cases:
Manual hours / candidate hours / setup hours:
Recurring and first-year external cost:
Cash spending actually avoided, with evidence:
Released capacity and named intended use:
Downside case and remaining unknowns:
Budget approver / contract owner / cancellation deadline:
Review date and conditions for changing this decision:
If the pilot fails, record why and keep the functioning parts of the manual process. If it passes, retain source checks and review ownership after purchase. The decision is complete when the team can explain what improves, what it costs and how it will know if the improvement stops.