Singapore’s Revised FM Procurement Guide: How to Specify AI, Automation and Measurable Service Outcomes

A practical Singapore checklist for turning digital FM requirements into measurable tender and contract outcomes.

For Singapore building owners, public-sector FM teams and service providers, the question is no longer simply whether a tender should mention AI or Smart FM. The more important question is: what operational outcome must the technology support, and how will that outcome be measured?

BCA’s revised FM procurement guidance provides a useful four-stage structure covering pre-tender, tender, evaluation and post-tender activities. This creates an opportunity to move away from broad technology language and specify practical requirements for data, workflows, response times, predictive maintenance and service performance.

The following checklist is designed for organisations procuring integrated facilities management, building operations, engineering services or digital FM capabilities in Singapore.

1. Pre-tender: define the operational problem before the technology

A strong digital FM tender begins with the building’s operational needs, not with a preferred platform or an impressive list of AI features.

Before preparing the tender, document:

• Critical building systems and assets, such as air-conditioning, electrical, fire protection, lifts, water systems and access-control interfaces.
• Known pain points, including recurring faults, manual inspections, delayed escalation or incomplete maintenance records.
• Operational constraints, such as occupied areas, warehouse activities, restricted zones, night work and business continuity requirements.
• Existing systems, sensors, equipment interfaces, work-order tools and reporting processes.
• Stakeholders who need information, including building owners, FM supervisors, technicians, tenants, security teams and management.

For each problem, state the required business result. For example, “identify abnormal equipment behaviour early enough for the FM team to investigate” is more useful than “deploy predictive AI”. Similarly, “route urgent faults to the responsible team with a recorded acknowledgement” is more precise than “automate incident management”.

2. Specify the data foundation

AI and automation depend on usable data. A tender should therefore describe the data environment that the supplier will receive, improve or create.

Useful data requirements may include:

• Asset registers with asset IDs, locations, equipment types, criticality and maintenance history.
• Building drawings, equipment manuals, operating schedules and relevant digital information-exchange formats.
• Sensor, meter, alarm and building-management-system data where available.
• Work orders showing fault descriptions, timestamps, assigned personnel, actions taken and closure status.
• Inspection records, photographs, readings and compliance-related evidence where relevant to the service.
• Defined data ownership, access permissions, retention periods, export arrangements and handover requirements.

Do not assume that all assets are equally suitable for automation. Ask suppliers to identify data gaps, data-quality issues and integration dependencies during mobilisation. The tender can also require a baseline assessment and a practical data-improvement plan instead of assuming that a digital model or algorithm will work immediately.

3. Design digital workflows that match real FM operations

Technology creates value when it fits the way people work. A digital FM specification should map the workflow from detection to verification and closure.

For a fault or abnormal condition, define:

1. How the issue is detected, such as through a sensor, alarm, inspection, user report or system rule.
2. How the issue is classified by urgency, asset criticality, location and potential operational impact.
3. Who receives the notification and what information is included.
4. How the job is assigned, acknowledged, escalated and updated.
5. What evidence is required before the work order is closed.
6. How recurring issues are reviewed and converted into preventive or improvement actions.

Specify the minimum information that must be visible to supervisors and managers. This could include asset history, open work orders, response status, repeat faults, overdue tasks and unresolved recommendations. The purpose is not to create more dashboards; it is to support faster and better operational decisions.

4. Convert service expectations into measurable requirements

Response-time metrics should be defined in operational terms. A single “24-hour response” requirement can be ambiguous if the tender does not explain whether response means acknowledgement, remote diagnosis, attendance on site, temporary mitigation or permanent rectification.

Consider separating the service clock into stages:

• Detection or reporting: when the issue enters the system.
• Acknowledgement: when the responsible team confirms receipt.
• Initial assessment: when severity and next action are determined.
• Attendance or remote intervention: when the team begins the required response.
• Rectification or temporary recovery: when the agreed service condition is restored or controlled.
• Closure: when records, evidence and follow-up actions are completed.

Set different targets according to asset criticality and incident severity rather than applying one blanket target. Also define exclusions, dependencies, escalation rules and the evidence needed to verify performance. This makes the KPI fairer for both buyer and supplier.

5. Specify predictive maintenance carefully

Predictive maintenance should not be treated as a guaranteed label. It is a capability that depends on asset condition, failure modes, sensor coverage, historical data, operating context and the FM team’s ability to act on alerts.

A procurement specification should ask suppliers to explain:

• Which asset classes and failure modes are suitable for the proposed approach.
• What data is required and how missing or unreliable data will be handled.
• How alerts will be prioritised to avoid unnecessary alarm volume.
• How the system will show the reason for an alert in language that technicians can use.
• How recommendations will be reviewed, accepted, rejected or converted into work orders.
• How performance will be validated against actual inspections, faults and maintenance outcomes.

Ask for a controlled pilot or phased implementation where the operating data is not yet mature. The contract should distinguish between a system-generated recommendation and a verified maintenance outcome.

6. Evaluate suppliers on delivery capability, not feature count

During tender evaluation, consider a balanced assessment of operational understanding, technical integration, workforce adoption and measurable value.

Suppliers can be asked to demonstrate a realistic use case using sample or anonymised information. The demonstration should show the complete workflow: an issue is detected, prioritised, assigned, escalated, acted on and reported. This is more informative than a presentation of disconnected platform functions.

Evaluation questions may cover:

• How will the supplier mobilise and validate the asset and data baseline?
• Which systems can be integrated, and what interfaces or site-side dependencies are required?
• How will cybersecurity, access control and data governance be managed within the agreed project arrangements?
• How will technicians and supervisors be trained and supported?
• What happens if the algorithm produces a low-confidence or incorrect recommendation?
• How will the supplier report benefits without claiming that every improvement was caused by AI?

7. Build post-tender measurement into the contract

Digital FM transformation should continue after award. The post-tender stage should include mobilisation milestones, data validation, user acceptance, reporting reviews and improvement cycles.

Outcome-based KPIs may include:

• Percentage of critical assets with complete and verified records.
• Percentage of work orders with required timestamps, actions and closure evidence.
• Response, attendance, recovery and closure performance by incident category.
• Repeat-fault trends for selected assets or systems.
• Completion of planned preventive-maintenance activities.
• Percentage of alerts reviewed within the agreed operating process.
• Adoption of digital workflows by the relevant FM teams.
• Quality and timeliness of management reporting.

Set a baseline before claiming improvement. Review whether a KPI measures an actual service outcome or merely platform activity. For example, the number of alerts generated is not by itself evidence of better maintenance. The more meaningful question is whether relevant issues were identified, acted on and verified.

Practical checklist for Singapore FM buyers

Before issuing a tender, confirm that the specification:

• Links each proposed digital capability to a defined operational problem.
• States the available data, required data and known data limitations.
• Describes the end-to-end workflow and roles of people, systems and service providers.
• Separates acknowledgement, attendance, recovery and closure time.
• Defines how AI recommendations will be reviewed and governed.
• Uses outcome-based KPIs with baselines, evidence and review mechanisms.
• Includes mobilisation, training, integration, handover and continuous improvement.

BCA’s Smart FM resources and AI-for-the-built-environment materials provide useful context for organisations planning digital adoption. Other Singapore initiatives, including AI-enabled facilities-management testbeds and technology-enabled workplace-safety developments, also show why procurement teams should consider people, process, data and governance together.

The best FM tender is not the one with the most technology terms. It is the one that gives suppliers enough operational detail to propose a workable solution, while giving the buyer a clear way to verify service performance.

Contact ISS to discuss engineering, facility management or AI automation requirements for your Singapore building, warehouse or business premises. Visit intelligencesolutionservice.com.