The Exception Is Part of The Process

Every operational process looks remarkably clean when drawn on a screen. A request is created, assigned to the responsible person, processed, approved if necessary and eventually closed. Each step follows the previous one, responsibilities are clear, information arrives when it should, and the workflow moves neatly from beginning to end.

Then the building opens.

A tenant submits a work permit request but the contractor arriving at the property is not the person originally declared. A visitor reports a lost item but remembers the wrong floor. A maintenance request that appeared routine suddenly becomes urgent. A delivery arrives outside the permitted hours. An incident begins as a security issue and ends up involving technical operations, tenant management and legal. Someone enters incomplete information. Someone else enters perfectly correct information that no longer reflects what is happening on site.

None of these situations is extraordinary on its own. That is precisely the point.

In a complex commercial property, enough exceptions happen every day that collectively they stop being exceptions. They become operations.

This is something support teams learn quickly because much of our work happens between the way a process was designed and the way it is actually being used. When everything follows the expected path, there is usually very little to discuss. The interesting cases begin with a sentence we have heard countless times:

“But this isn't an exception. We do this all the time.”

And very often, they are right.

Software needs standardization. Without it, there is no meaningful process to digitize. A work order needs statuses, a complaint needs responsibility, a permit needs approval steps and an incident needs a record. Structure creates accountability and allows thousands of individual activities to become understandable operational data.

But standardizing a process does not standardize reality.

A commercial property is occupied by tenants, visitors, contractors, employees, suppliers and technical teams, all interacting with the same physical environment for different reasons. Information arrives late. Priorities change. Responsibilities overlap. Decisions that made perfect sense an hour ago may no longer fit the situation on the ground.

A process can be standard. The circumstances rarely are.

This is why we have become increasingly cautious about the phrase edge case. Technically, it describes something outside normal operating conditions. Operationally, the distinction is less comfortable. When hundreds of activities take place every day, events with relatively low individual probability begin occurring regularly in aggregate.

The edge of the process becomes surprisingly crowded.

The answer is not to build a new workflow for every deviation. A system that changes whenever one customer encounters one unusual situation eventually stops being a product and becomes a collection of customizations. Flexibility matters, but so does discipline. The real challenge is distinguishing between a genuine exception, a property-specific way of working, and a recurring operational reality that the product itself should understand.

That distinction becomes clearer over time.

When one property tells us, “This isn't an exception,” we listen. When another property operating independently describes the same situation months later, we listen differently. When the same pattern begins appearing across different properties, teams and processes, it is no longer simply a customer request. It may be evidence that the model of the process is incomplete.

This is where support becomes more than solving individual cases.

Every implementation exposes the platform to another operating environment. Every support conversation adds context. Some requests remain specific to one property and should remain that way. Others reveal patterns that can improve how the platform works for everyone. When that happens, what one property teaches us today can mean that the next property joining EPPSO never needs to explain the same problem again.

There is an important balance here. Listening does not mean building everything everyone asks for. If software simply mirrors every individual preference it encounters, standardization disappears and the product eventually becomes a bespoke project for each customer. But ignoring repeated deviations creates the opposite problem: a perfectly structured system that gradually becomes disconnected from the operation it was built to support.

The useful territory lies between those two extremes.

Exceptions can tell us where responsibilities overlap, where information is consistently arriving too late, where users are improvising, where a procedure creates unnecessary friction, or where the formal process has simply failed to evolve alongside the property.

One unusual case may mean nothing.

Ten similar cases may deserve attention.

And when the same “exception” keeps returning, perhaps the most useful question is no longer:

“Why didn't people follow the process?”

Perhaps we should ask:

“Is the process still describing what people actually need to do?”

Because a process should provide structure to an operation without becoming blind to the reality of how that operation evolves. The objective is not to eliminate every exception. It is to recognize when an exception is genuinely exceptional — and when repetition is trying to tell us something.

After years of watching real properties operate, that distinction becomes difficult to ignore.

Maybe the operation didn't leave the process.

Maybe the process left the operation.