Planning and Actual Results in Facility Management: What Data Is Collected from the Field?

A work plan can be precise one moment and become unreliable just a few hours later. An unavailable access point, an additional task, a missing material, or an execution time that differs from what was planned can change the day’s operations in the field. If this information remains in a phone call, a chat, or the operator’s memory, those coordinating the operations continue to plan based on a situation that is now outdated.

There’s no need to collect every detail. The information that comes back from the field should be what enables decision-making: confirming the plan, correcting it, initiating a follow-up task, updating the client, or assessing the impact on the project.

The operational summary begins in the field

The final report is often associated with month-end closing or administrative reporting. For those who organize people and activities, however, the operational summary comes first: what has been done, what has changed, and what requires action.

This information must remain linked to the planned work. A note such as “task completed late” is of little use if it does not specify the project, location, planned activity, team, and date. The primary requirement, therefore, is not the number of fields, but the presence of common and unambiguous references.

Attendance, duration, person-hours, and outcome are not the same thing

To accurately interpret field work, four types of information must be distinguished:

- Attendance indicates when a person is on duty and, if recorded, at which location. It should not be confused with scheduled availability, nor does it, on its own, indicate that the task has been completed.
- The duration of the activity measures how much time a specific task took.
- Person-hours express the total time spent by the people involved.
- The outcome indicates whether the planned activity was completed, partially completed, or not performed.

A purely illustrative example: two workers engaged for two hours correspond to four person-hours, while the duration of the activity remains two hours. However, even these two pieces of data alone do not prove that the work has been completed. For this reason, presence, time, and outcome must remain distinct, even when referring to the same activity.

The minimum information that must be included

The exact set depends on the service and contractual obligations. To design it, you can start with five questions, each linked to a specific decision.

The table is not a universal template. It serves to ensure that every piece of required data has a user and a purpose. If no one knows what to do with a photograph, a free-form note, or a time-stamp, that data burdens the workflow without improving oversight.

Routine confirmations and exceptions require different data

If a task was completed as planned, a structured confirmation may suffice. If a deviation arises, however, the cause, impact, and next steps are needed.

This distinction prevents two mistakes. The first is always requiring lengthy forms, even when they add no value. The second is limiting oneself to generic statuses like “done” or “not done,” which do not explain how to reschedule.

Determine immediately who records and who takes action

Information received after the end of the workday may be accurate but useless to those who need to reorganize the work. The operational signal must be sent when the exception requires a decision; consolidation for the project or administration can follow at a later time.

Clear responsibilities must also be assigned. Who logs the exception? Who verifies it? Who decides on the next course of action? A note such as “missing material” triggers action only if someone is responsible for checking availability, organizing procurement, and updating the date.

Two Hypothetical Scenarios

Let’s imagine scheduled maintenance for Tuesday morning. The technician arrives on-site but discovers that an unanticipated component is needed. Simply writing “job not completed” leaves too many questions unanswered. A useful report links the outcome to the job, indicates the cause, specifies the required component, clarifies the urgency, and assigns the next step. The planner can then verify the material and schedule a second visit.

In a recurring cleaning service, however, two staff members may be present during the scheduled time without having completed all tasks. For example, the regular areas were cleaned, but one room remained locked, and the work there must be rescheduled. Staff presence, completed tasks, and remaining tasks therefore describe different aspects: recording them separately prevents the entire service from being considered complete or, conversely, from discarding what has already been done.

Both examples are illustrative. Data, responsibilities, and urgency levels must be adapted to the specific service and applicable agreements.

A checklist to use even during the demo

Process verification can begin with some real-world cases and be repeated during a software demo. The checklist is brief:

- The plan references remain linked to the actual data.
- The operator quickly confirms routine activities and describes exceptions when necessary.
- Presence, duration, person-hours, and outcome are not confused.
- Information arrives in time for the planned decision.
- Every exception has an assignee, a status, and a next step.

During the demo, these points help you ask specific questions: how is the activity identified, what information is required in different cases, who receives the exception, and how is the data linked to other company systems. The answers depend on the organization’s processes, configuration, interfaces, access rights, and constraints.