How B10 Rebuilt Catalyst’s Reactive Maintenance System

How B10 Rebuilt Catalyst’s Reactive Maintenance System

b10 rebuilt Catalyst’s reactive maintenance system by replacing fragmented ticket entry, manual contractor chasing and unclear status tracking with a centralised, automated workflow. The new system connects monday.com, Make, WhatsApp Business through 360dialog, and Microsoft 365 so tickets can be created, assigned, updated, tracked and closed through one controlled operating process.

Reactive maintenance looks like a facilities problem on the surface. A tenant reports an issue. A member of the team reviews it. A contractor is contacted. The work gets done. The ticket is closed.

That version sounds simple because it hides the operational reality. In a live environment, reactive maintenance can quickly become a network of emails, calls, informal messages, manual follow-ups, status uncertainty, inconsistent contractor responses, tenant chasing and reporting gaps. The issue is rarely one person doing something wrong. The issue is usually the architecture of the workflow.

That was the real problem b10 found at Catalyst. The reactive maintenance process was not broken because the facilities team lacked effort. It was structurally inefficient because the workflow relied too heavily on manual coordination. Requests could come through different routes. Contractor communication required staff intervention. Ticket progress was not visible enough. Ownership was not always clear enough. SLA performance could not be managed with the level of control the operation needed.

b10 did not approach the project as a simple automation task. The work was treated as an operational system rebuild. The aim was to remove fragmentation, create one controlled flow, automate repetitive communication, improve stakeholder visibility and give Catalyst a scalable foundation for future maintenance operations.

What is reactive maintenance workflow automation?

Reactive maintenance workflow automation is the use of structured systems, forms, rules, notifications and integrations to manage maintenance issues from request to resolution without relying on manual chasing at every step. It matters because reactive maintenance becomes risky when requests, contractors, tenants and internal teams operate through disconnected communication routes.

A proper reactive maintenance workflow should answer seven operational questions:

If the system cannot answer those questions quickly, the problem is not just administration. It is operational risk.

Catalyst before the rebuild

Before the rebuild, Catalyst’s reactive maintenance process had the classic signs of a fragmented operational workflow.

There were multiple ticket entry points. Issues could be raised through different channels, including email, informal communication, internal reporting and manual methods. That created a visibility problem. When a workflow has several front doors, the team cannot reliably manage every request through the same operating model.

There was also manual contractor communication. Facilities staff had to contact contractors, pass on job details, chase responses, track acceptance, request progress updates and confirm completion. That meant the process depended on people remembering to push the work forward. In a low-volume environment, that might be manageable. As ticket volume grows, it creates delay, inconsistency and administrative load.

The third issue was central tracking. Without one controlled operational view, the facilities team had limited visibility of job status, contractor response, SLA performance and tenant communication. That made the workflow reactive in the worst sense: the team could respond to problems, but the system was not managing the flow with enough structure.

The fourth issue was tenant visibility. When tenants do not receive clear updates, they chase. When tenants chase, facilities staff lose more time. When facilities staff spend more time replying to update requests, less time goes into managing the actual work. Poor communication does not just affect experience. It creates operational drag.

The final issue was scalability. A system based on manual coordination can work while demand is low and experienced staff hold the process together. However, it becomes fragile when volume increases, people are unavailable, contractors respond inconsistently, or management needs a reliable view of performance.

The design philosophy

one entry point, automation, visibility

b10 rebuilt the process around three principles.

Single point of entry

Every maintenance request needed to enter one controlled system. That does not mean every user sees the same interface. It means the operational data lands in the same place, follows the same structure and can be managed through one workflow.

For Catalyst, this meant centralising ticket creation through a form connected to monday.com. Instead of requests being scattered across manual routes, the issue now becomes a structured ticket inside the operational board. That is the first major shift: the workflow starts clean.

Automation at every repeatable step

Automation was not added for novelty. It was applied where manual action created delay, repetition or risk.

Contractor notifications are triggered automatically. Status changes update the workflow. Tenant updates are sent at the right points. Contractor responses can update the ticket. Follow-up logic can create a new ticket when required. The system now carries the process forward instead of waiting for a person to remember the next step.

Clear ownership and real-time visibility

A maintenance system needs more than task capture. It needs operational accountability. Catalyst staff need to know who owns the ticket, where it sits, what priority it has, whether a contractor has accepted, whether the contractor is on-site, whether the work is complete, and whether a follow-up is required.

That visibility now sits inside the workflow. Staff do not need to rebuild the status from emails, messages and memory. The system provides the operational view.

The technology stack B10 implemented

b10 designed the reactive maintenance workflow around four connected platforms:

The value was not the individual tools. The value was the architecture between them. Many businesses already have useful tools, but the tools do not create operational control unless they are connected around a clear process.

In this rebuild, monday.com became the single operational source of truth. Make became the automation layer. WhatsApp became the contractor response interface. Microsoft 365 supported email communication where required. Together, those components created a controlled maintenance operating system.

How the new reactive maintenance workflow works

The new system manages the lifecycle of a maintenance request from submission to closure.

Step 1: Ticket creation

A tenant submits a maintenance request through a centralised form. The form creates a ticket directly in monday.com. The ticket contains the required details, including the issue, location, status and supporting information.

This step removes the first major source of inefficiency: fragmented request capture. The issue does not sit in somebody’s inbox or memory. It enters the system.

Step 2: Facilities review

The Catalyst facilities team reviews the ticket. They assign the relevant internal person, confirm the location, adjust the priority and determine whether contractor intervention is required.

This keeps human judgement where it matters. Automation should not remove operational decision-making. It should remove repetitive chasing and manual transfer of information.

Step 3: Contractor assignment

When a contractor is needed, the contractor is assigned inside monday.com. That assignment triggers the communication flow automatically.

The key point is that the facilities team does not need to manually build and send every message. The system generates the next step based on the ticket status and assignment logic.

Step 4: Automated contractor communication

The contractor receives the job details through WhatsApp and email. The communication includes the relevant ticket information, location, issue description and instructions to accept or decline the job.

This reduces delay at the exact point where many maintenance workflows slow down. Instead of waiting for manual outreach, the contractor is notified immediately through a practical communication channel.

Step 5: Contractor response

Contractors can interact with the workflow through WhatsApp. They can accept or decline the job, confirm progress, provide updates, submit images and confirm completion.

This matters because contractor communication is often where facilities workflows become messy. If every contractor update arrives as a separate call, email or message, the facilities team has to translate that communication back into the tracking system. b10 removed that gap by allowing contractor responses to feed the workflow directly.

Step 6: Automatic ticket updates

Contractor responses update the monday.com ticket automatically. The team does not need to manually change every status field or reconstruct the job history from external communication.

This is where automation starts to create real control. The system becomes a live operational view rather than a database that staff update after the fact.

Step 7: Resolution

When the contractor completes the job, they can provide a summary of work completed and optional image confirmation. The ticket can then move towards closure with a clearer operational record.

This improves accountability. The work is not just “done” because someone said it was done. The workflow captures completion evidence and keeps the status visible.

Step 8: Follow-up handling

If further work is required, the system can create a follow-up ticket and close the original one. That keeps the workflow clean. The first issue is resolved as far as it can be, while the next action becomes its own trackable item.

This is important because follow-up work often disappears into vague notes or informal reminders. b10 turned it into a structured continuation of the process.

Before and after

the operational shift

The biggest change is the move from manual coordination to system-driven operations.

Before b10, the process depended on facilities staff manually receiving requests, contacting contractors, chasing updates, informing tenants and tracking progress. After the rebuild, the process is structured through a central system that captures tickets, triggers communication, updates status and gives stakeholders visibility.

This is why the project should not be described as “we automated some messages”. b10 rebuilt the operating model behind the workflow.

Why this matters commercially

Operational workflows affect commercial performance more than many leaders realise.

In a facilities environment, slow maintenance response affects tenant experience. Poor visibility increases internal pressure. Manual chasing consumes staff capacity. Unclear contractor ownership creates delays. Weak SLA tracking reduces management control. Fragmented communication makes reporting unreliable.

Those problems might not appear on a sales dashboard, but they still affect revenue efficiency, retention risk, team capacity and operating margin. This is why b10 treats operations as part of the wider commercial system. A business cannot scale efficiently if growth creates more manual work, more hidden risk and more dependency on individual memory.

For founder-led and MD-led companies, the lesson is direct: if a workflow only works because good people are constantly chasing it, the system is not scalable. You do not have operational control. You have operational heroics.

The AI layer

useful intelligence, not theatre

The Catalyst system also included useful AI features to support ticket understanding. These included AI-generated ticket summaries and sentiment or ticket-type detection to help facilities staff understand the nature of the request more quickly.

The important word is “useful”. AI was not positioned as the centre of the project. The centre was operational control. AI supported the workflow by improving understanding, summarisation and classification. That is the right role for AI in operational transformation: reduce friction, improve clarity and support decisions without pretending the technology is the strategy.

What this enables next

The new architecture gives Catalyst a foundation that can evolve.

First, it can support preventative maintenance. Once reactive maintenance is structured, scheduled inspection workflows and planned maintenance tasks can be built into the same operating logic.

Second, it can support contractor performance tracking. Over time, Catalyst can analyse response times, acceptance rates, completion rates, evidence quality and SLA performance.

Third, it can support better operational reporting. The system can be expanded into dashboards that show backlog, open tickets, resolution patterns, repeat issues, tenant feedback and workflow bottlenecks.

Fourth, it can support automation across other departments. The same architecture can be applied to internal support, operations, tenant communication, onboarding, service requests and other repeatable workflows.

This is where the project connects to Commercial Transformation. The maintenance workflow is one operational use case. The method is broader: diagnose the fragmented system, rebuild the process, connect the tools, automate the handoffs and create a controlled operating layer.

B10’s diagnostic view

what other companies should learn

If your business has a maintenance, operations, support, onboarding or service workflow, ask these questions:

If the answer is no, the problem is probably not “we need another tool”. The problem is that the workflow has not been designed as a system.

The CTI Benefit

The CTI is b10’s commercial maturity diagnostic. In a project like this, CTI would look at operations and automation maturity as part of the wider commercial system. It would assess whether the business has clear workflows, clean ownership, connected tools, reporting visibility and scalable handoffs.

Catalyst’s reactive maintenance rebuild shows the implementation side of that logic. b10 does not just identify that a system is fragmented. b10 can rebuild the workflow, connect the stack and create operating control.

That is the distinction. Diagnosis tells you what is broken. Implementation fixes the system. Managed improvement keeps it working as the business changes.

Conclusion

b10 rebuilt Catalyst’s reactive maintenance system by turning a fragmented, manual workflow into a centralised, automated operating process. The project reduced hidden workflow risk, automated contractor communication, improved ticket visibility, supported SLA tracking, improved tenant updates and created a foundation for future operational automation.

The real value was not the software stack on its own. The real value was the system design: one entry point, clear ownership, automated communication, live status visibility and scalable workflow logic.

For any business relying on manual operational coordination, the lesson is blunt. If the process depends on people remembering to chase, update and inform everyone, the process is not under control. It is being held together manually.

b10 helps businesses move beyond that. We diagnose fragmented systems, rebuild the workflow and create the operating control needed to scale without adding unnecessary administrative drag.

Let’s Transform Your Operations Engine

Speak To An Expert