When enterprises procure software or digital intelligence services, tender documents still commonly stipulate requirements such as “bidders must assign XX senior engineers and maintain on-site presence for no less than XX person-months.” The evaluation forms score candidates based on headcount, qualifications, and unit prices—weighted accordingly. While this approach was reasonable ten years ago, today, with the widespread adoption of intelligent agents and AI-assisted delivery at , it often ends up selecting the supplier with the largest workforce rather than the one delivering the clearest results.
Policy Background: Procurement Logic Is Changing
In September 2026, the Ministry of Industry and Information Technology released the “Special Action Plan for ‘AI + Software,’” which calls for advancing software toward intelligent transformation and developing service models such as “intelligent agent as a service,” while emphasizing that what matters is not how much is invested, but how effective the outcomes are. For buyers, the signal is clear: if they continue to judge solely by man-days and on-site personnel, they may end up purchasing a “noisy implementation” without achieving verifiable business improvements.
Man-Day Evaluation vs. Outcome-Based Evaluation: What’s the Difference?
| Dimensions | Traditional Man-Day/Headcount Evaluation | Outcome-Oriented Evaluation |
|---|---|---|
| Core Metrics | Number of personnel, their levels, days on-site, and unit prices | Closed-loop scenarios, acceptance scripts, and post-launch KPIs |
| Requirements Expression | Checklist of functional features | Job operations, data standards, and exception rules |
| Change Management | On-site negotiations for adding staff or funds | Impact of change orders on milestones and KPIs |
| AI/Intelligent Agents | Typically Not Included in Scoring | Requirements should specify efficiency gains, manual review points, and permission boundaries |
| Payment Milestones | Settlement by quarter or per person-month | Payment upon milestone-based acceptance |
| Points of Contention | “Are the personnel in place?” | “Have the scripts been successfully executed and have the metrics improved?” |
Business Logic: How Should Tender Documents Be Revised?
To shift procurement documentation from “buying manpower” to “buying results,” we recommend rewriting four key sections:
- Scenario Checklist : Write out “current pain points → target actions” for each role—for example, “procurement staff switch from placing orders via email to completing PO approvals within the system.”
- Acceptance Scripts : Attach test steps, input data, and expected outputs to each scenario; bidders must respond item by item regarding feasibility.
- KPI Commitments : Quantifiable metrics within 90 days after go-live, such as the percentage reduction in approval cycles, discrepancy rates in reconciliation, and inventory accuracy—metrics must be systematically measurable.
- Service Boundaries : Clearly delineate responsibilities for training, operations & maintenance, data migration, and intelligent agent rule maintenance to avoid the situation where “the project ends once it goes live.”
Proposed Scoring Weights: Scheme–acceptance alignment 40% + effectiveness of similar cases 30% + price 20% + team capability 10% . Teams still need to be considered, but shouldn’t dominate; otherwise, we’ll revert to simply counting heads.
Design Logic: How Can Intelligent Agents and Automation Be Integrated into the Evaluation Process?
If a proposal includes intelligent customer service, automated follow-ups, or rule engines, buyers should require bidders to address:
- Input and Output : Which documents are read, which statuses are written back, and whether auditing is possible.
- Permissions and Escalation : Which operations require manual confirmation, and how to escalate when deadlines are missed.
- Accuracy and Spot Checks : How to measure baseline commitments and roll back errors.
- Supplier Lock-In : Whether models, rules, and knowledge bases can be exported to prevent paralysis when switching vendors.
Implementation and Acceptance: Three-Phase Access Control
It’s recommended to explicitly state three-phase access control in the contract and tie payments to acceptance:
- Phase One (4–8 weeks) : Ensure 100% pass rate for core scenario scripts and complete training for key roles. No payment for Phase Two unless Phase One passes.
- Phase Two (8–12 weeks) : Integrate cross-departmental workflows, stabilize interfaces and master data, and begin collecting baseline KPI data.
- Phase Three (90 days of operation) : Review against contractual KPIs; those failing will face rectification periods and deductions instead of indefinite on-site presence.
On-site staffing numbers can serve as implementation measures included in appendices, but should not constitute the main contract subject. The primary contract focus should be “which scripts pass and which metrics improve.”
Common Misconceptions Among Buyers
Misconception One: Winning bids through low-cost man-days —later, additional charges drive up total costs. Countermeasure: Cap the total price and create a separate pricing table for changes.
Misconception Two: More features mean better —but lead to lower launch success rates. Countermeasure: Implement phased scenarios, keeping Phase One minimal yet fully closed-loop.
Misconception Three: Ignoring master data —resulting in messy data after system launch, with intelligent agents amplifying errors. Countermeasure: Treat master data governance milestones as separate acceptance criteria.
Misconception Four: Failing to define KPI measurement standards —leading to disputes over who calculates what. Countermeasure: Include metric formulas, data sources, and statistical cycles in appendices, and have the IT department confirm the system’s ability to automatically collect data.
Next Steps
If you’re currently re-tendering ERP, OA, SRM, or custom digitalization projects, consider spending a week conducting a “tender health check”: redline all man-day clauses in your existing RFPs and rewrite them one by one into scenario-based formats, complete with scripts and KPIs. Even if you don’t finish everything, at least the next round of tenders won’t still rely on the 2015 logic of choosing suppliers based on headcount.
Technological upgrades in the software industry aren’t limited to vendor workshops—they also happen in buyer-side procurement departments. Whoever adopts outcome-based evaluation first is more likely to secure a truly usable, accountable, and analyzable management system in the age of intelligent agents, rather than just a thick list of personnel.
Additional Considerations for State-Owned Enterprises and Group Purchases
Large-scale procurements often balance compliance with practical effectiveness: You can retain qualification thresholds and anti-fraud provisions in tender documents, but the technical scoring matrix must designate “completeness of acceptance script responses” and “KPI measurability” as mandatory sub-items, preventing technical scores from becoming mere formalities.In the multi-legal-entity scenario of the group, bidders should be required to explain how master data and permissions support subsidiaries, and roll out the solution only after the pilot legal entity has successfully executed the scripts in Phase I—rather than attempting to integrate the entire group right from the start.
During the procurement committee’s demonstration phase, it is recommended to randomly select 2–3 scripts for the bidder to execute on-site, with the evaluators scoring against the expected outcomes—this approach better reflects the real-world experience post‑go-live than assessing based solely on PPT presentations or headcount configurations. In the contract negotiation stage, including “rectification periods and penalty formulas for failing to meet KPIs” directly in the main text provides stronger protection for both parties than relying on informal negotiations afterward. The evaluation reform does not need to wait for the next national standard; the next procurement can already begin by piloting a single script, one KPI, and a Phase I access control system. Taking small, incremental steps to identify and correct errors is far more effective at keeping pace with rapid changes in both policy and technology than waiting for a perfect template.