Blog

A head of IT at a 600-person logistics firm sent me a scoping document last month. Forty-one pages. It had been produced by one of the Big 4 after what they called a “discovery and assessment engagement.” Six weeks, three onsite workshops, nineteen stakeholder interviews, a kickoff deck, an interim readout, a final readout, and a signed statement of work for the next phase. The invoice for the discovery was €84,000. He asked me to look at it before he signed the implementation SOW. I read the whole thing on a Sunday afternoon. The actual content, once you stripped out the appendices, the methodology slides, the “future state vision,” the governance structure diagrams, and the eleven-page stakeholder RACI, fit on about two pages of substance. His current ITSM instance was over-customized. He needed a rebuild of incident, problem, and change on a cleaner data model, with a reasonable integration to his monitoring tool and a sane service catalog for his internal users. That was it. I called him back on the Monday. We spent two hours on the phone. By the end of that call I had a scoped build plan, a sequencing recommendation, a rough cost band, and a shortlist of the three technical…

A client called me a few weeks ago because their new HR onboarding flow had been failing silently for eleven days. Nobody had noticed. The error handler on the parent flow caught the exception, logged a one-line message to a custom table, and quietly moved on. Twelve new hires started that fortnight without laptop requests, access provisioning, or payroll setup. The flow was green in Flow Designer. The dashboards were green. HR found out when the first employee emailed asking why she had no laptop on day three. That is the problem with ServiceNow Flow Designer in production. It makes building the happy path trivial, so teams build the happy path and move on. The error paths, the retries, the idempotency, the observability, the subflow boundaries, the integrationhub rate limits, none of those get the same attention. Six months later the instance is covered in flows that work until they don’t, and when they don’t, nobody can tell. I spend a lot of my consulting time on ServiceNow Flow Designer, both greenfield builds and rescue work on flows other people wrote. The patterns below are what I have learned to trust, and the ones I have learned to rip out when I inherit them.

A programme director at a mid-market insurer called me on a Wednesday last autumn. Her ITSM rollout was eight months in with one of the Big 4. The CMDB was still empty of anything useful. The incident form had thirty-two custom fields nobody could explain. The named architect on the SOW had been rotated to another account twice already, and the delivery lead was a 24-year-old running Scrum ceremonies from a slide template. She wasn’t angry. She was past that. She wanted to know if it was too late to switch. That call isn’t unusual. It’s roughly one in four of the inbound conversations I have, and the pattern repeats so often it has a shape. The engagement didn’t fail at month eight. It failed at month two, when the senior architect who sold the deal handed the keyboard to a bench team. The next six months were the client slowly figuring that out. If you’re reading this with a similar knot in your stomach, the question isn’t whether you can switch your ServiceNow partner mid-build. You can. People do it. The question is whether you understand what breaks when you do, what gets recovered, and what the next three months actually look like.

A new CIO at a mid-market insurer inherited a ServiceNow instance last February. Three years of implementation under a Big 4 partner, two go-lives, one half-finished HRSD rollout, and a renewal invoice sitting on her desk for a licence tier she could not justify. She asked her ServiceNow account manager what state the platform was in. He said “healthy, you’re on Washington.” That was the answer. On a half-million-euro-a-year platform. She called us the following week. Ten business days later she had a 42-page report, a dashboard with 46 scored items across six dimensions, and a conversation to have with her account manager that was no longer symmetric. The instance was not broken. It also was not healthy. It was the normal condition of a ServiceNow instance that has had three years of change, two partner handovers, and nobody specifically paid to look after it.

A finance director at a logistics group in Rotterdam called me in February. Their ServiceNow ITSM rollout had been running for eleven months on a time-and-materials contract with one of the big consultancies. The original estimate was 420 billable days. They had just signed off invoice number thirty-four, and the running total was 710 days. Nothing was live yet. The project manager kept using the phrase “complexity emerged during discovery,” which is consultant Esperanto for “we didn’t scope it and now we’re charging you to fix our scoping.” She asked me one question. “Would a fixed-fee contract have stopped this?” The honest answer is that it would have stopped most of it, and the parts it would not have stopped would at least have been someone else’s problem. That is the whole argument for how ServiceNow consulting costs should be structured in a mid-market engagement. Not that fixed-fee is cheaper on paper, because sometimes it is not. The point is that fixed-fee shifts the scope risk off your P&L and onto the vendor’s, and that is the risk that actually blows budgets.

A COO at a 650-person logistics company calls on a Tuesday morning. They signed the SOW six months ago. The deck promised ITSM, CSM, HR, a bit of ITOM, “foundational governance”, and a roadmap to Now Assist by month ten. Their partner, a mid-tier regional SI, is burning through the budget at a rate that puts them at 140 percent by go-live, and they are now five weeks past the first phase milestone with no live incident module. The CFO wants to know whether to pause, replan, or fire the SI. The COO wants to know what went wrong. Nothing went wrong. The scope went wrong, six months ago, on a slide no one scrutinised. This is the single most common failure mode I see when mid-sized companies buy a platform built for the Fortune 500, and it is almost always baked in before the first developer logs into the instance. ServiceNow sells the same catalog to a 650-person logistics company and to a 65,000-person bank. The modules are identical. The licensing is identical. The sales motion is identical. What is not identical is the organisational capacity to absorb the platform.

A head of IT at a 600-person industrial supplier called me after their partner’s third timeline slip. The signed statement of work said twenty-two weeks to live incident, request, change, and a thin CMDB. By week nineteen, the delivery lead was asking for an eight-week extension and quoting discovery findings as the reason. His board had already approved the extension when he phoned me, so he was not asking for help negotiating. He wanted to know what he could do differently on the next phase so it did not happen again. His question is the right one, and the honest answer is that almost every ServiceNow implementation timeline is decided before the official kickoff meeting. The two weeks before the project is announced to the business are where most of the slip is manufactured, and nobody budgets for them. I say this at the risk of annoying every account executive at every system integrator. They sell a start date. Clients buy a start date. Everybody wants the kickoff slide in the second week of the quarter. What actually drives whether a project lands on time has very little to do with the kickoff and almost everything to do with the preparation that either happened or did not…

A head of service at a 900-person industrial equipment firm in the Benelux region sent me her incident volumes last month. The weekly count had been climbing for eleven months straight, from roughly 180 to just over 320. The service desk was adding people. The CFO was unhappy. The CIO had just agreed a second-wave hiring plan for the service desk. Nobody on the leadership team could tell me what the top five recurring root causes were, because nobody had been counting. That gap is the whole post. The ServiceNow platform ships with a Problem module that is competent out of the box, free to turn on, and almost universally ignored in mid-market shops. Every one of those 320 weekly incidents had a cause. Perhaps forty distinct causes drove the full volume. The firm was paying full ticket cost for all 320 and had never identified the forty. This is the hole where ServiceNow ITIL best practices stop being an abstract reference library and start being a very concrete difference in run cost. I want to walk through what mid-market problem management discipline actually looks like on ServiceNow, where the common failure modes are, and what two or three moves get you most of the value in…

A head of IT at a 650-person logistics group in southern Germany called me in late September. He had just signed with one of the Big 4 for a two-year ServiceNow programme covering ITSM, HRSD and basic SPM. The number on the SOW was a shade under €2.3 million. He was not calling to celebrate. He was calling because, three weeks in, he had met four different people from the delivery team, none of whom had been in the sales meetings, and the solution architect who had sold him the design was now scheduled for one day a month on the engagement. I asked him why he had not seriously evaluated a smaller partner. His answer was the thing I want to write about today: his procurement team ran a standard RFP template they had used for ERP and the enterprise data warehouse. The template filtered out every firm with fewer than 500 employees globally in question 3. He never got to see a boutique ServiceNow consulting proposal because the gate stopped them before the technical scoring started. This is the mechanism. It is not that mid-market buyers prefer the Big 4. It is that mid-market procurement teams import filters built for different categories of spend and apply them to platform work…

A CFO at a 900-person engineering firm pulled me into a call last spring with one question. Not about the platform, not about workflows. “Give me the three lines I write on the slide to the board. Because right now I have ‘service management’ and the board is going to ask me what we got for 480 thousand euros.” That is the real question hiding inside every pitch deck on ServiceNow ITSM benefits. The sales conversation is about automation and single pane of glass. The invoice conversation is about where the money shows up again. Those are not the same conversation, and the gap between them is where most ServiceNow business cases quietly die after year two. I have spent fifteen years watching this. The patterns are consistent. The CFO buys three things, and only three. Everything else is interior decoration.

A programme director at a European insurer rang me in July. Their ITSM rollout was eight months in, twelve weeks behind schedule, and the third change request had just landed on her desk. The partner was one of the big four. The engagement partner had rotated twice. The named architect on the SOW had never appeared on a working call. The offshore build team was three developers who all seemed to be learning ServiceNow on her budget. She asked me one question. “Is it too late to switch?” It was not. It rarely is. But the answer to the second question, the one nobody at her firm was asking yet, mattered more. How do you switch a ServiceNow partner mid-project without losing the eight months of work you already paid for?

A retail CIO called me on a Sunday night. Their point-of-sale integration had been down for four hours across 380 stores. Their MIM process, on paper, was textbook. Dedicated channel in Teams. Incident commander named in the runbook. Bridge open. Status page updating every 15 minutes. Communications template pre-approved by comms and legal. None of it was working. The bridge had 34 people on it, most of them muted, most of them unclear on why they had been invited. The incident commander was a service desk manager who had been told two months earlier that this role was hers on paper. She had never actually run one. The status page updates were being drafted by a comms person who was pulling status from the bridge, which was pulling status from a screenshare of a Kibana dashboard that only one engineer could read. And the ServiceNow major incident record itself had been created 90 minutes into the outage, after someone remembered it should exist. This is what most ServiceNow major incident management looks like when the wheels come off. Not because the tooling is bad. The tooling is fine. Because the process was designed for the audit, not for the crisis.

A head of platform at a European insurer emailed me last month with a screenshot. It was a Now Assist summary of a P2 incident, generated inside the agent workspace. The summary read like it had been written by a competent junior analyst. Concise, factual, decent grouping of the timeline. He wanted to know two things. First, was the platform team crazy to be excited about it. Second, why the SecOps team was still refusing to enable it on their queue. Both questions have the same answer, and it is the answer that anyone actually working with Now Assist ServiceNow deployments in 2026 already knows. The technology works. The rollout does not. Set the marketing to one side. Now Assist is a set of generative AI capabilities baked into the ServiceNow platform, powered by NowLM and, where the customer chooses, by third-party frontier models routed through ServiceNow’s own inference layer. The four capabilities that customers touch most often are case summarization, resolution note drafting, agent chat sidekick, and virtual agent topic generation. There are more. Flow authoring assistance, code generation for scripted actions, playbook suggestion, and a growing set of domain-specific…

A COO of a European logistics company forwarded me a proposal last month. Two hundred and eighty pages. A well-known Big 4 firm quoted €1.4M for what she described as “a fairly standard ITSM implementation with HRSD in a second phase.” She had already paid €90K for the assessment that produced the proposal. Her question to me was simple: is this what ServiceNow actually costs, or am I being played? The answer is uncomfortable for the industry. She was being played, but not in the way she thought. The €1.4M number was not made up. It reflected real hours, real rates, real overhead. The problem was that roughly 40% of those hours would be spent on things that added no value to her instance, and she had no way to know which 40%. This is the conversation about servicenow consulting costs that partners avoid, because the moment you actually break the numbers apart, the pricing model that funds most of the industry stops making sense for anyone who is not a Fortune 500.

A COO signs a Statement of Work in January. The SI has quoted a 24-week ServiceNow implementation timeline, ITSM Pro plus a light ITOM footprint, go-live in early July. She circulates the plan internally. Marketing pencils in a launch webinar. Finance builds the licence spend into the Q3 forecast. HR schedules the change-comms rollout. By late April the delivery lead sends the first quietly worded status note. Discovery took longer than planned because the CMDB source data was worse than anyone admitted. Two integrations were re-scoped when the SAP team said their middleware team is booked until September. Change requests are stacking up. The July date is now “at risk”. By June it has slid to October. By October it is November with a phased approach. The webinar is cancelled. None of this is unusual. It is the average ServiceNow implementation timeline for a mid-market rollout done properly. The problem is that almost nobody quotes it that way at the sales stage, so every project starts with a plan that was already fiction on the day it was signed.

A COO at an 800-person specialty chemicals company rang me last month. Her IT director had spent six weeks on a Big 4 scoping exercise and come back with a €1.4M number, a nineteen-month plan, and an org chart showing four consultants on the account she had never met. She wanted to know if that was the price of entry for ServiceNow, or whether she was being priced like a Fortune 500. She was being priced like a Fortune 500. This is the pattern I see almost every week. Mid-market companies, roughly 200 to 2,000 employees, get quoted implementation programs designed for organisations five or ten times their size. The methodology is the same. The team structure is the same. The overhead is the same. What the client actually needs is different, and nobody bothers to redesign the delivery model around that fact. Then the CFO gets sticker shock, the project gets shelved, and the mid-market keeps running on a mix of Jira Service Management, spreadsheets, and shared inboxes for another eighteen months.

A platform lead at a European insurer asked me last month to look at their change process on ServiceNow. Their board had just been shown a slide with a 14 percent change failure rate and the CIO wanted to know whether it was a tooling problem or a people problem. He was hoping for tooling, because tooling is buyable. I spent two days pulling change records, listening in on a CAB, and sitting with the Change team. The tool was fine. The CAB was theatre. Every Wednesday at 15:00 a room of twelve people spent ninety minutes rubber-stamping fifty-plus normal changes, arguing about two of them, and running out of time before the standard change catalogue was even mentioned. Nobody was reading the change records before the meeting. The risk score was cargo-culted from the template. The implementation plans were three sentences long. The failure rate had nothing to do with the platform. It had everything to do with the fact that change management servicenow had become a compliance ritual instead of a control.

An infrastructure lead at a European insurer emailed me last month with a screenshot of their CMDB health dashboard. Completeness at 42%. Compliance at 61%. Correctness sitting somewhere between “we don’t know” and “please don’t ask.” Around it, four years of implementation partners, three Discovery relaunches, and a CMDB governance board that had not met in seven months. His question was not really about the numbers. It was: how do we stop this from being someone’s cleanup project every 18 months? That is the right question. And the answer is not another cleanup project. It is treating the CMDB as a product with an owner, a roadmap, and a working definition of “done” that is not a one-time percentage but a service level. That shift is what ServiceNow CMDB data quality services are actually selling when they are worth paying for, and it is the shift most enterprises never make.

A service desk manager pinged me last month with a screenshot of her Performance Analytics dashboard. Mean time to resolution on P2 incidents had drifted from 4.2 hours to 6.8 hours over two quarters. Nobody had shipped a bad release. Nobody had lost engineers. Ticket volume was flat. The number just kept climbing, quietly, the way these numbers do. Her CIO wanted a plan by Friday. We spent forty minutes on the call. The problem was not the tool. Her instance was a fairly clean Vancouver build, incident table lightly customised, assignment groups sane. The problem was the way people had been taught to use it. Every senior engineer had a private ritual for triaging tickets. Every team lead had their own definition of “in progress”. The routing rules had been extended eleven times in eighteen months, each extension solving one manager’s complaint and quietly slowing everything else down. What she needed was not a new module. She needed to strip the incident process back to what ITIL actually says and let the platform do its job.

A CFO at a 600-person distribution business emailed me in July with a spreadsheet. Two proposals for the same ITSM foundation project, both from tier-one partners. One was €480k, the other €1.1M. The scopes looked, on the surface, almost identical. Same modules, same integrations, same go-live window. She wanted to know whether the cheaper firm was cutting corners or the expensive one was gouging. The honest answer was neither. What she was looking at was two different ways of pricing the same uncertainty, and neither number was going to be the number she actually paid. That is roughly the tenth version of that conversation I have had this year. Buyers ask what ServiceNow consulting costs should be and the market gives them a range wide enough to drive a truck through. Some of that spread is real. A lot of it is theatre. This post is the honest breakdown of where the money actually goes, why the sticker price and the final invoice almost never match, and what a mid-market company can do to stop being surprised.