Automating the Hidden Work

Yet amid all this demand, a significant and almost entirely undiscussed portion of every FM technology team’s engineering hours is consumed by work that no one has examined, prioritized or targeted for improvement. It is neither glamorous nor technically complex. It is manual, repetitive configuration and maintenance work: room attribute updates in calendar and booking systems, user provisioning in space management platforms, recurring data exports assembled by hand for reports that executives need weekly, and routine vendor communication workflows that follow predictable logic but require a human to execute every time.

This is the hidden work. And it is quietly preventing FM technology organizations from delivering the capabilities their stakeholders most urgently need.

According to JLL Technologies’ State of FM Technology 2024 report, FM practitioners cite shrinking budgets as their top concern, with approximately 43 percent describing their teams as understaffed. Most responses to this capacity challenge focus on what platform to buy next, what vendor to replace or what AI capability to evaluate. The more immediate and higher-return opportunity lies in a different question entirely: what is the team already doing every week that a well-designed automation could do instead?

The anatomy of hidden work

Hidden work accumulates through a mechanism that is both predictable and difficult to see clearly from inside an organization. When a new FM technology platform is deployed, the implementation team identifies a set of recurring operational tasks (configuration updates, data synchronizations, reporting outputs) that are not automated by the platform out of the box. These tasks are assigned to team members as part of their operational responsibilities. They are completed. Stakeholders receive their outputs. The cycle repeats.

The critical failure is what happens next: because the work is completed and stakeholders are satisfied, there is no organizational pressure to revisit it. The task becomes a line item in someone’s weekly routine instead of a candidate for improvement. Over time, as platforms multiply and integrations grow more complex, the aggregate hidden workload grows, but no single task is large enough to trigger a formal review, and the team’s delivery capacity quietly erodes.

Every hour an FM technology engineer spends on rule-based, repeatable manual configuration is an hour not invested in data quality improvement, platform modernization, quality assurance (QA) maturity or the analytics capability that translates occupancy and lease data into portfolio decisions.

Auditing for automation candidates

The starting point is a structured audit of current FM technology operations; not a high-level process review, but a granular inventory of what each team member actually does each week, decomposed to the individual task level. This audit is most effective when it focuses on three qualifying criteria.

The first criterion is rule-based execution. A task qualifies for automation consideration when its completion process can be expressed as a decision tree with no ambiguous branches: if this condition is true, perform this action; if not, perform that action. Tasks that require genuine judgment, stakeholder interpretation or contextual knowledge that varies unpredictably do not qualify. Tasks that feel complex because they involve multiple systems but follow a consistent logical sequence often do.

The second criterion is predictable recurrence. Tasks that happen on a fixed schedule (daily, weekly, monthly or triggered by a predictable system event) are fundamentally different from tasks that arise reactively. Scheduled recurrence is what makes automation economically viable: the development cost is amortized across every future execution of the task.

The third criterion is material time consumption. A task that takes 30 minutes per occurrence and recurs 100 times per year represents 50 hours of engineering time annually, more than a full work week. Multiplied across a portfolio of five or six such tasks, the aggregate hidden workload can represent several months of engineering capacity per year. Teams that have never conducted this audit are frequently surprised by the magnitude.

Calculating ROI

Once automation candidates are identified, the return on investment (ROI) calculation should be structured in terms that resonate with both FM and IT leadership, covering not just cost savings but capacity recovery and error rate reduction.

The capacity recovery calculation is straightforward: multiply the average time required per task execution by the annual recurrence frequency to arrive at annual hours consumed. The denominator (automation development and ongoing maintenance cost) is typically a one-time investment of hours to build the automation script or workflow, plus modest ongoing governance overhead. For lightweight application programming interface (API)-based automations on common FM and workplace platforms, the initial development investment is often 10 to 20 hours for a task that recovers 50 or more hours annually.

The error rate reduction argument is equally important but frequently underweighted. Manual configuration tasks are error-prone not because the people performing them are careless, but because human attention is variable in ways that well-designed automation is not. A room attribute update performed manually 200 times per year will, statistically, produce errors. Each error creates a data inconsistency that propagates into downstream reports, dashboards and potentially compliance records. Quantifying even an approximate error rate and connecting it to data quality risk often strengthens the business case more than the hours-recovered calculation alone.

Building lightweight automation without a development team

A common misconception among FM technology leaders is that workflow automation requires either a dedicated software development resource or a new technology investment in an automation platform. In practice, the majority of hidden work in FM technology organizations can be automated using lightweight scripting that interacts with the APIs of platforms already deployed.

Most enterprise FM and workplace platforms (space management systems, lease administration tools, digital signage platforms, visitor management systems and calendar integrations) expose API endpoints that allow external systems to read, create, update and delete records programmatically. These APIs are designed precisely for the type of integration and configuration work that FM technology teams currently perform manually. An automation that calls these APIs on a schedule, or in response to a trigger event, can replace manual task execution without touching the platform’s underlying architecture.

The practical sequence for building this type of automation follows four steps.

Map the task to its data inputs, logical conditions and outputs.

Identify the relevant API endpoints in the platforms involved, verifying that the required operations are available, and confirming that the team has the necessary service account credentials to execute them.

Build the script in a language and environment already familiar to the team, with no need to introduce new infrastructure for most use cases.

Test the automation in a nonproduction environment across a representative set of inputs, including edge cases that the manual process handles through human judgment, to confirm that outputs are correct and failure modes are manageable.

Teams that approach automation incrementally, starting with the single highest-volume, lowest-risk task, build confidence and governance discipline faster than teams that attempt to automate multiple workflows simultaneously. A single successful automation that demonstrably recovers engineering time creates organizational momentum for the next one.

Governance that makes automation sustainable

Automation without governance creates a distinct operational risk: configuration changes that are invisible, irreversible or impossible to audit. FM technology leaders who build automation programs without governance frameworks often encounter this problem 6 to 12 months after initial deployment, when a silent automation failure produces data errors that are difficult to trace to their source.

Four governance practices make automation sustainable at enterprise scale.

Execution logging. Every automation run should produce a timestamped log entry recording the inputs processed, the actions taken and any exceptions encountered. This log is the audit trail that allows the team to diagnose failures, demonstrate compliance to stakeholders and verify that the automation is behaving as designed.

Alerting for exceptions. Automations should be designed to fail loudly rather than silently. When an input falls outside expected parameters, or when an API call fails, the automation should generate an alert to a designated team member rather than proceeding with a potentially incorrect action.

Reversibility design. Where possible, automations should be designed so that their outputs can be undone, either through a compensating API call or through a manual review-and-correct workflow triggered by the exception alert. Configuration changes that are irreversible on short notice introduce disproportionate risk relative to the time they save.

Periodic review. Automation logic should be reviewed against current platform behavior on a defined schedule (quarterly is appropriate for most FM technology environments) because platform APIs and data schemas change with software updates, and an automation that was correct when built may produce incorrect outputs after a platform version upgrade.

From capacity recovery to strategic capability

The argument for automating hidden work is often framed as an efficiency argument, and the efficiency gains are real and measurable. But the more consequential argument is strategic.

FM technology teams that are consumed by manual operational work cannot invest in the platform modernization, data quality improvement, QA maturity and vendor governance activities that produce long-term organizational value. Each of those activities requires sustained engineering attention; not a single project, but an ongoing discipline of iteration, measurement and refinement. Teams with insufficient capacity for that sustained attention deliver platforms that technically function but fail to produce the decision-quality data that senior real estate and workplace leadership need.

Portfolio optimization was the primary occupancy planning objective for 73 percent of organizations in 2025, according to JLL’s Global Occupancy Planning Benchmark Report, making it the leading corporate real estate priority for the third consecutive year. Yet the same report found that only 7 percent of organizations rate their space data capabilities as excellent, and 20 percent report poor or no data capability at all. The gap between the portfolio decisions organizations want to make and the data quality required to support them is not a platform problem. It is a data infrastructure problem, and it is precisely what unaddressed hidden work perpetuates.

The FM technology leaders who consistently outperform their peers in delivering strategic capability are not, in most cases, the ones with the largest teams or the most advanced platforms. They are the ones who have disciplined their organizations to protect engineering capacity for strategic work, and who treat the elimination of hidden work as a foundational operational practice, not an occasional efficiency project.

And in an industry where 43 percent of FM technology teams describe themselves as understaffed while simultaneously being asked to deliver more sophisticated capabilities year over year, capacity recovery is not a nice-to-have. It is the prerequisite for everything else.

None of these undertakings requires a specialized development team, new platform investment or a major change initiative. Any FM technology organization with the discipline to look clearly at where engineering hours are actually going and the willingness to act on what it finds can begin recovering capacity within weeks.