Blog

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.

A COO at a 900-person logistics company forwarded me a proposal last month. Fifty pages, three modules, six weeks from kickoff to go-live. Fixed price, “accelerator-driven”, “pre-configured for logistics”. She wanted to know if the number was real. It was not. What she was looking at was a sales artifact, not a plan. The team that wrote it had never actually delivered a working ITSM instance in six weeks and would not this time either. But it looked clean on a slide, and someone in her CFO’s office had already circled the price. That conversation is roughly the fifteenth version of the same conversation I have had this year. Buyers ask “how long does it take to implement ServiceNow” and get back a number that has nothing to do with the work sitting in front of them. So this post is the honest version. If you are budgeting a ServiceNow implementation timeline, or trying to sanity-check one you have been handed, this is what you actually need to plan for and where the weeks go. For a mid-market company doing a genuine ITSM foundation, meaning Incident, Problem, Change, Knowledge, Service Catalog with maybe a dozen real items, a working CMDB with Discovery pointed at production,…

An IT director at a 650-person industrial equipment maker sent me a scoping document last month. Forty-two pages. Written by a Big 4 partner she was evaluating. It proposed an eight-month ITSM implementation with a fifteen-person delivery team, a three-tier governance model with a steering committee that met fortnightly, a full CMDB build using Common Service Data Model 5, a Service Portfolio Management module she had never asked for, and a change advisory board structure copied verbatim from the same firm’s engagement with a European bank. She asked me one question. “Does this look right for a company our size?” It did not. The document was a Fortune 500 implementation plan with the client name changed. Every mid-market company that has bought servicenow consulting services for mid-sized enterprises from a large SI has seen a version of this document. The plan is not wrong because it is bad. It is wrong because it is not built for a mid-sized enterprise. It is built for a large one, scaled down badly, and priced to keep a fifteen-person team busy.

A finance director at a 900-person specialty chemicals company rang me on a Wednesday afternoon last month. He had just signed a Statement of Work with a tier-one global SI for what should have been a straightforward ITSM plus HRSD build. The number on the SoW was €1.4 million for a fifteen-month program. He wasn’t calling to celebrate. He was calling because he had spent the previous evening reading through the resource plan and noticed that of the eleven people billed against the project, only two had ServiceNow certifications, and none of them were the two people who had presented in the sales cycle. He wanted a second opinion before the kickoff meeting the following Monday. I’ve had a version of that call maybe fifteen times in the last three years. The pattern is so consistent it has stopped being surprising. A mid-market company (say 300 to 2,500 employees, one instance, no offshore captive, budget of €300k to €1.5m for the initial build) buys ServiceNow. They put the implementation out to tender. The Big 4 or a tier-one global SI wins because their name is on the shortlist and the procurement team feels safer signing with someone they’ve heard of. Six to nine months in,…

A CIO at a regional insurer called me in June, twenty months after their ITSM go-live. The steering committee had voted to cut the ServiceNow budget by eighteen percent. Not because the platform had failed. Because nobody could point at what it was still doing. The year-one deck had been beautiful. Twenty-three slides of before-and-after: incident volume down, MTTR down, first-call resolution up, CSAT up. The programme director who ran the implementation had left in month fourteen. His replacement inherited the platform, not the story. When the CFO asked in the June review “so what are we still getting for the licence renewal”, nobody in the room could answer with a number that came out of the platform itself. They answered with adjectives. This is the pattern I see in almost every year-two ITSM conversation. The benefits case that justified the buy is not the benefits case that justifies the renewal. And most of the numbers a partner puts on the go-live scorecard evaporate by month eighteen because the operational discipline that produced them was never handed over. If you are looking at ServiceNow ITSM benefits with a two-year lens rather than a launch-week lens, three things…

An IT director at a mid-cap logistics group called me on a Monday. His board had already signed off on ending the managed-services contract with a Big 4 firm. The rate card was eye-watering, the tickets were closed with three-word resolution notes, and the last upgrade had left three custom applications sitting in a broken half-migrated state. His question was not “should we switch”. That was decided. His question was the one every buyer at this point in the story asks: “how do we do this without the wheels coming off the platform for six months”. That is the real problem when you switch ServiceNow partner. Everyone talks about the commercial exit, the notice period, the transition clause. Almost nobody talks about the two things that actually determine whether the change goes well or turns into an eighteen-month regret. Those two things are the state of the instance you are inheriting from yourself, and the handover the outgoing partner is contractually obliged to do but rarely does properly.

A head of platform at a European insurer calls me on a Tuesday. They have bought Now Assist as part of a Pro Plus bundle. The executive sponsor wants a demo in six weeks. Sales has been shown a video with a chat window that resolves incidents in one sentence, and the CIO has already told the board that AI will cut ticket handling time by forty percent. The head of platform reads the release notes, opens the Now Assist configuration, and realises he has no idea which of the twenty-plus skills to enable, in which order, or whether any of them will survive contact with the messy reality of his instance. That call is the reason I am writing this. There is a large gap between the marketing story around Now Assist and what actually lands in production. After a year of watching real Now Assist deployments across mid-market and enterprise customers, I can tell you which capabilities are genuinely worth turning on this quarter, which ones need six months of data cleanup first, and which ones you should quietly skip until the next release.

A CIO at a mid-market insurer emailed me on a Tuesday morning last month. Subject line: “second opinion.” She had a signed SOW from one of the Big 4 for a Now Assist rollout across ITSM and CSM. The headline number was €780,000 over nine months. Reasonable, on paper. Six months in, the run rate was tracking to €1.4 million and the go-live date had slipped twice. She wanted to know two things. Was she being taken for a ride, and what would a boutique shop have quoted for the same scope. I get some version of that email about every three weeks now. The gap between what buyers think they are signing up for and what they end up paying is the biggest source of pain in ServiceNow programmes right now, and it is almost entirely avoidable if you know where to look before you sign. Every ServiceNow implementation has three cost lines. The one on the SOW. The one that hits your budget. And the one your finance director will actually approve when the change request lands on their desk in month five.