Integrated Facilities Management: A Practical IFM Guide

Quick answer

In this guide, integrated facilities management (IFM) means one provider works across at least two facility service areas. Those areas may include operations and maintenance, energy, support services, the built environment, or data and technology.

IFM does not mean that every service uses one process or one software product. The proposal still needs to identify service ownership, measures, data rights, subcontracting rules, and the records required to review performance.

For day-to-day delivery, test whether a service issue keeps a visible owner, current status, completion evidence, and agreed measure as it crosses teams or systems.

What is integrated facilities management?

The International Facility Management Association uses the ISO definition of facility management: an organizational function that integrates people, place, and process within the built environment.

The Global FM Impact Report uses a provider-focused definition of IFM: one provider working across at least two service areas such as operations and maintenance, energy, support services, the built environment, or data and technology. This guide uses IFM in that provider-market sense. Internal and hybrid delivery models can use similar coordination controls, but they are different sourcing choices.

What an IFM contract may cover

An IFM contract may include:

• Hard services such as HVAC, electrical, plumbing, lifts, fire systems, and building fabric
• Soft services such as cleaning, security, reception, waste, catering, and grounds
• Workplace services such as rooms, visitors, moves, and occupant requests
• Service partners, permits, approvals, rate cards, and completion evidence
• Building and IoT signals that need an accountable response
• Performance, cost, risk, and audit records across sites

Not every contract needs every area. The scope should name the included services, interfaces, records, and measures rather than relying on the IFM label.

IFM is not a software category

Separate the sourcing model from the software scope when comparing proposals.

Software can support IFM, but a tool cannot decide who approves emergency work, which supplier owns a missed service, or how an unresolved alarm escalates. Those are operating-model decisions.

The technology should make those decisions visible and repeatable. At minimum, teams need a reliable record of:

1. Where demand came from
2. Which site, space, asset, or service it affects
3. Who owns the next action
4. What priority and due time apply
5. What changed and when
6. What evidence supports completion
7. Who accepted or rejected the outcome
8. What cost and performance data should be reviewed

Infodeck’s facility operations platform is designed around that shared record. Maintenance, service requests, contractors, approvals, and proof stay connected rather than becoming separate reports that someone reconciles later.

IFM compared with traditional facility management

Traditional FM is not automatically fragmented. A well-run internal team can coordinate services effectively. The problem begins when each service develops a separate intake path, ownership model, supplier record, and reporting language.

Integration does not mean making every service identical. A fire-system inspection and a cleaning request need different checks. They can still share request identity, ownership, due time, evidence, approval, and audit history.

IFM, IWMS, CMMS, CAFM, and BMS

These are working boundaries rather than product rules. They align with IBM’s explanations of CMMS and IWMS, plus the US Department of Energy’s BMS glossary definition. Product coverage varies, so confirm which records each product owns.

A BMS can detect a high temperature. A BMS integration can pass that event to another system. The operating model still needs to decide whether the event opens work, how it is prioritised, who responds, and what closes the incident.

Likewise, a CMMS can hold the maintenance record while an IWMS manages leases and space. The integration question is not “Which system does everything?” It is “Which system owns each record, and where can a person see the request, owner, status, and completion record?”

For a wider category comparison, see the facility management software taxonomy guide.

Five controls to test in an IFM proposal

1. Shared service intake

People report issues through the channel closest to them: a QR code, form, phone call, email, reception desk, mobile app, or messaging channel. Buildings add alarms and sensor events.

A multi-service contract does not make those channels consistent by itself. Define the fields each route must create so the receiving team has enough context to act.

A useful minimum includes:

• Requester or source
• Site and exact location
• Service category
• Asset, when known
• Description and evidence
• Impact or urgency
• Contact and access details

Fault reporting and work order management should preserve that context as work moves between requesters, teams, and suppliers.

2. Named ownership and escalation

Every open item needs one current owner. Assign it to a named person or supplier, not only to a department queue.

Define:

• Who triages each service category
• Who can reassign work
• Which events require approval
• When a due time begins and pauses
• What triggers escalation
• Who can accept completion

Test these rules with the people doing the work. Remove steps that technicians, supervisors, or suppliers cannot complete during a normal shift.

3. Connected asset and service context

Some work belongs to an asset. Other work belongs to a space, visitor, supplier, service agreement, or site event.

An integrated record should keep the relevant context without forcing every request into an equipment hierarchy. Use asset records for equipment history, warranties, criticality, and replacement context. Use service and location records for work such as cleaning, reception, waste, or room issues.

4. Evidence and acceptance

“Complete” should mean more than a status selected by the assignee.

Evidence may include:

• Technician notes
• Before-and-after photos
• Readings or checklist results
• Parts and labour used
• Permit or safety confirmation
• Requester or supervisor acceptance
• A reason when the expected result was not achieved

The required evidence should match the risk. Replacing a light and closing a fire-system defect should not require the same completion checks.

5. Measures tied to decisions

Avoid starting with a large dashboard. Begin with measures that change a decision:

• Open demand by age and priority
• Response and resolution against the agreed service target
• Reopened work
• Preventive work completed on time
• Repeat failure by asset or fault type
• Supplier work awaiting evidence or approval
• Cost by service, site, asset, or supplier

Each measure needs an owner and an agreed action when the result moves outside target. Without that action, the number creates reporting work rather than operational control.

How to plan an IFM transition

Step 1: Map one request-to-close path

Choose a service with visible friction and enough volume to learn from. Examples include reactive HVAC work, occupant fault reporting, contractor call-outs, or planned inspections.

Map what happens now:

1. How demand enters
2. Who decides priority
3. Who assigns work
4. Which systems or sheets are updated
5. What evidence is collected
6. Who accepts completion
7. How cost and performance are reported

Mark every handoff, duplicate entry, missing decision, and item waiting without a clear next owner. This becomes the baseline.

Step 2: Define the operating record

Agree on the minimum fields and ownership rules before selecting integrations.

For each field, name:

• The system of record
• Who creates it
• Who can change it
• Whether it is required
• How errors are corrected
• How long it is retained

Do not migrate every historical field simply because it exists. Move the data needed for active work, compliance, asset decisions, and useful trend analysis.

Step 3: Separate connection types

The Infodeck integrations page separates three paths:

• CSV import and export, plus supported notifications
• API and webhook access on Pro and Enterprise plans
• Building, enterprise, and legacy connections that need confirmed requirements

This distinction matters in any IFM program. A documented webhook is not the same effort as reconciling finance records with an ERP. Name the connection type, owner, test data, failure behaviour, and how the team confirms the data is correct before quoting a delivery date.

Step 4: Pilot with real work

Use real requests, real locations, and representative users. A pilot should include normal cases and exceptions:

• Work that changes priority
• Work reassigned to a contractor
• Missing access or parts
• A failed integration
• A rejected completion
• A reopened request

Measure whether users can find the current owner and status without asking someone outside the system.

Step 5: Expand by repeatable pattern

After the pilot works, reuse the operating pattern for adjacent services. Keep the common record fields and controls, then add service-specific checks.

Expand after users can find the current owner and status, required evidence is present, and exceptions have a named recovery path.

Build, buy, or outsource?

The right delivery model depends on service criticality, internal capability, portfolio scale, and supplier maturity.

In this guide, IFM describes outsourced multi-service delivery. Internal and hybrid models can use similar controls without being the same sourcing model.

Internal service integration

Internal teams retain direct control over standards, data, and service delivery. This model needs enough operational and technical capacity to maintain processes, supplier controls, and systems over time.

Outsourced IFM

A lead provider coordinates several service areas. This can reduce contract interfaces, but the customer still needs clear data ownership, service definitions, audit rights, exit provisions, and performance review.

Hybrid service delivery

An internal team owns the operating model and data while specialist providers deliver selected services. This is common when technical work requires licensed or local expertise.

Whichever model you choose, ask the same questions:

• Who owns the service standard?
• Who owns the operational data?
• Can records be exported in a usable format?
• How are subcontractors controlled?
• What evidence is required before payment?
• What happens when the provider or software changes?

How to evaluate software used in IFM delivery

Feature lists are useful for coverage, but scenarios reveal fit.

Bring these tests to a demo:

1. Occupant request: A person reports a leak with a photo. Show triage, assignment, updates, completion, and requester visibility.
2. Asset failure: A technician opens the asset record, sees history, records parts and labour, and flags replacement risk.
3. Contractor work: An external party receives only its assigned work, submits evidence, and waits for acceptance.
4. Planned inspection: A recurring task becomes overdue and escalates without losing the original schedule.
5. Building signal: An alarm or sensor threshold creates an accountable response and keeps the event with the work record.
6. Portfolio review: A manager compares sites and opens the underlying records behind a weak measure.
7. Integration failure: A webhook or sync fails. Show retries, error visibility, ownership, and recovery.

Then compare the commercial scope:

• Which users need paid access?
• Which sites, assets, requests, visitors, devices, and API calls have limits?
• Which connections are included, configured, or separately mapped?
• What migration and training work belongs to the customer?

Use the CMMS comparison hub to structure a shortlist and review Infodeck pricing before a scoped demo.

Common IFM mistakes

Treating consolidation as integration

Reducing supplier count can simplify administration, but it does not create shared ownership or data by itself.

Starting with software configuration

If decision rights and service rules are unclear, the software will encode that confusion.

Forcing every service into one template

Keep shared fields and ownership rules, then preserve controls that differ by service and risk.

Migrating poor data without ownership

Cleaning data once is not enough. Define who maintains locations, assets, suppliers, categories, and user access after go-live.

Measuring what the system can count

Choose measures because they support decisions, not because a dashboard widget is available.

Hiding exceptions

Failed connections, rejected work, missing evidence, and overdue approvals are part of normal operations. Record them and assign an owner instead of hiding them from reports.

Final checklist

An IFM program is ready to expand when:

• Requests create a consistent record across agreed channels
• Every open item has a current owner
• Service and asset context is available to the people doing the work
• Completion evidence matches the risk
• Suppliers work within the same acceptance rules
• Integrations have named owners and failure paths
• Managers can open the records behind each measure
• Users can see status without starting a separate follow-up chain

IFM places several service areas with one provider. That arrangement still needs explicit ownership, accessible records, service-specific controls, exception handling, and customer data rights.

Sources

• IFMA: What is facility management?
• IFMA: The Global FM Impact Report 2023