One of Halo's strengths is that it can be deployed at very different levels of complexity. A small IT team can be up and running in weeks with a clean, simple service desk. A larger enterprise can build a fully structured CMDB, automate ticket routing and escalation based on service ownership, and track availability against defined targets. Both are valid. Both are real Halo implementations.
The question is not which approach is better. It is which approach is right for your organisation, and whether the implementation you bought was scoped to deliver it.
Two very different implementations, both called "Halo"
Most Halo deployments fall somewhere on a spectrum between fast and functional at one end, and deeply automated and service-aware at the other. Understanding where you sit on that spectrum before implementation begins is the single most important scoping decision you will make.
Simple, operational service desk
Focused on getting a clean ticketing system live quickly. Incident, request, and change workflows. A service catalogue built for users. Small team, limited budget, fast time to value. No CMDB architecture or service hierarchy required. This is a legitimate and well-served use case for Halo.
Service-aware automation platform
Built around a structured CMDB and defined service ownership. Ticket routing, impact calculation, change governance, and availability tracking all driven by the Service Data Model and Target Operating Model. Requires more time and investment upfront, but unlocks Halo's full automation capability.
The problem is not choosing one over the other. The problem is expecting the outcomes of the second while scoping and budgeting for the first.
When objectives are not met
Some organisations reach a point where Halo is not delivering the visibility or automation they expected. Tickets are still being manually assigned. Reporting does not reflect service impact. Change approvals are still chased by email. The team is using Halo but not really benefiting from it.
In most cases, this comes down to a mismatch between what was scoped and what was expected. That mismatch can happen regardless of who did the implementation. We see it in environments set up internally by IT teams, in projects delivered by other Halo partners, and in deployments done through Halo's own professional services. It is a scope problem, not a vendor problem.
The most common reasons the scope ends up misaligned:
-
Ambitions were underestimated at the start. The organisation wanted automation and service visibility but scoped a basic deployment, either to control cost or because the fuller capability was not fully understood at the time.
-
The CMDB was treated as optional. A service hierarchy and ownership model takes time to design and configure. When budget is tight it is often the first thing removed, but it is the foundation that everything else runs on.
-
Go-live was the finish line. Without a structured review after the system is live, misalignment between the implementation and real operational needs goes unaddressed. The environment stays static while the organisation evolves around it.
The part most implementations skip: people, process, and technology
Even a well-scoped Halo implementation can underdeliver if change and adoption are left as an afterthought. It is one of the most commonly overlooked areas in ITSM projects, and the consequences tend to show up a few months after go-live when usage drops off and old habits return.
A useful way to think about this is through three lenses: people, process, and technology. Most implementations focus almost entirely on the technology and treat the other two as someone else's problem.
Do your team understand why?
Users who do not understand why the system exists or how it benefits them will work around it. Communication, training, and visible sponsorship from leadership are not optional extras — they are the difference between a tool that gets used and one that gets ignored.
Does the system reflect how work actually happens?
When processes in Halo do not match how the team actually works, people revert to email and spreadsheets. Effective implementations map real workflows before configuring anything, then adapt the system to support them rather than forcing the team to change to fit the tool.
Is Halo configured to support, not complicate?
Technology is the enabler, not the answer. Halo should make it easier for people to follow the right process, not harder. Overconfigured screens, unnecessary required fields, and workflows that do not mirror reality all erode confidence in the platform quickly.
The organisations that get the most from Halo are the ones that treat these three areas with equal weight from the start. When only the technology is addressed, the investment in the platform rarely delivers its potential.
Closing the gap
If your Halo environment is not delivering what you expected, it does not necessarily mean starting over. A focused review of what was scoped, what was built, and what the organisation actually needs now is usually enough to identify a practical path forward.
Sometimes that means adding structure that was not included in the original scope. Sometimes it means simplifying an overconfigured environment that has become hard to use. Sometimes it means addressing the people and process gaps that were never tackled at go-live.
The starting point is always the same: understand what you actually need, then work out what needs to change.