The Decisions You Deferred Are the Costs You Are Paying Now.

There is a question worth asking before any organisation approves the next phase of its ServiceNow investment. The question is not whether the platform is capable of delivering what the new business case promises. It is why the previous business case did not deliver what it promised, and whether anything has changed in how the programme is being structured that would produce a different result this time.

Most of the time, the honest answer is that nothing has changed. The new investment is scoped the same way the last one was, funded to a go-live, measured at the point of deployment, and handed to the same function that was not resourced to govern the last one. The capability being added is genuine. The structural conditions that prevented the last capability from delivering its full value are still in place underneath it.

This is not a performance problem. The delivery teams are not underperforming. The platform is not failing. What is happening is considerably more structural, and considerably more predictable, than that.

Procurement Model · The Structural Problem

The investment case funds a go-live. It does not fund what comes after.

Enterprise transformation procurement is built around a specific logic. A scope is defined, a budget is approved, a delivery partner is engaged, and success is measured at the point of deployment. That logic works well for building things. It works poorly for building operating models, because an operating model is not something you deliver. It is something you run, and running it requires a different kind of investment, a different kind of accountability, and a different kind of governance than anything the delivery budget was designed to fund.

When a ServiceNow programme closes, the project governance dissolves with it. The steering committee that held accountability during delivery has no formal mandate after go-live. The transformation director who sponsored the business case has usually moved to the next priority. The delivery partner has fulfilled the contract and transitioned to support arrangements. What remains is a platform that was designed to run an enterprise, handed to a function whose budget was never set at the scale required to govern it, and whose mandate was defined around keeping the lights on rather than realising the value the original business case described.

The three governance gaps that follow are entirely predictable from this structure. Accountability for platform outcomes dissolves because no named successor to the project team was ever defined with the authority to hold those outcomes. The data model begins to drift because maintaining it continuously was never funded as an operational responsibility, only as a go-live deliverable. Cross-domain ownership remains undrawn because drawing it required a governance conversation across functional lines that the project structure never had the mandate to force.

None of these gaps are the fault of the team that ran the programme. They are the fault of a procurement model that funds deployment and calls it transformation. The distinction matters because it determines where the fix needs to be applied. Programmes that respond to these gaps by running a second deployment phase are applying the wrong solution to the right problem. The gap is not in what was built. It is in how the accountability for what was built was structured once the build was complete.

GCC Context · Why This Lands Differently Here

The regional conditions that accelerate the gap.

The structural problem described above is not unique to the GCC. It plays out in enterprise programmes across every market. What is distinctive about the GCC is that the conditions that accelerate the gap are present at greater intensity here than in most other enterprise environments.

Organisations across the UAE and Saudi Arabia are expanding at a pace that most platform configurations cannot accommodate without deliberate maintenance. Emiratisation and Saudisation targets are reshaping workforce structures on an annual cycle. Entities are being created, merged, and restructured as Vision 2030 and the UAE's national programme priorities drive diversification across sectors. Each structural change is a new divergence between how the platform understands the organisation and how the organisation actually operates. A ServiceNow environment configured eighteen months ago for an entity structure that has since changed is not a stable foundation. It is a record of a previous state that nobody has been formally accountable for updating.

The multi-entity and multi-jurisdiction dimension adds a further layer. Many of the largest GCC enterprises operate across onshore and free zone structures simultaneously, with different regulatory obligations, different workforce classifications, and different service models applying within the same organisation. A cross-domain governance model that was never formally drawn becomes genuinely difficult to retrofit across that complexity. The onboarding workflow that works for a mainland UAE employee does not automatically apply to a DIFC-based hire, a Saudi national under a specific Saudisation band, or a contractor whose engagement terms sit outside the standard service catalogue. That complexity was present when the platform was built. In most cases it was deferred rather than resolved, with the intention of addressing it in a later phase that has not yet arrived.

AI Investment · Why the Timing Matters

Agentic AI does not wait for the foundation to be ready.

The governance gaps described above have existed in most GCC ServiceNow environments for years. They were manageable because humans were absorbing the consequences. A workflow that routes to the wrong team gets corrected when someone picks up the phone. A data model that reflects an outdated organisational structure produces a wrong answer that a knowledgeable employee catches before it becomes an operational event. A cross-domain handoff that nobody owns causes friction and delay, but it surfaces visibly enough that someone intervenes.

Agentic AI removes the human buffer that made those gaps manageable. An AI Specialist on the ServiceNow platform does not pause to evaluate whether the data it is acting on reflects the current state of the organisation. It acts on what it finds, at the speed and scale that make it commercially compelling. The wrong routing decision becomes a wrong action at volume. The outdated service classification becomes an operational error that compounds across every case the agent handles before the pattern is identified. The undrawn cross-domain boundary becomes a governance void through which agents act without a named owner who can account for what they did and why.

This is not a warning about AI. It is a precise description of what happens when an organisation deploys genuine capability on a foundation that was not designed to carry it. The AI programme does not create the governance gap. It exposes the one that was already there, under conditions where the cost of exposure is considerably higher and the window for correction is considerably narrower than it was when humans were the buffer.

For the GCC CIO facing board pressure to activate AI on an existing ServiceNow estate, and for the COO being asked to approve that investment, the relevant question is not whether the AI capability is ready. It is whether the foundation it will operate on has been assessed honestly against what agentic execution actually requires. The organisations that have done that assessment, and addressed what it revealed, are deploying AI as an acceleration. The ones that have not are compressing the timeline to a point where the gaps become visible under the worst possible conditions.

The pattern described in this article is not inevitable. It is the predictable output of a procurement model that has not been updated to reflect what sustainable platform value actually requires. The organisations breaking it are not doing so with larger budgets or better delivery teams. They are doing so by asking a different question at the point of investment: not what will be built, and by when, but who will be accountable for what it delivers, for how long, and under what governance model.

That question, asked before the first configuration is written, is worth more to the long-term value of a ServiceNow programme than any capability that can be added to it later. It is also the question that most investment cases, structured around a go-live, are not designed to answer.