Blog

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.

A CIO at a European industrial group forwarded me a slide last week. Big four brand on the cover, twelve neat swimlanes, “Go-Live: Q1 2027” in bold across the bottom. Nine months, ITSM plus HRSD plus a CMDB refresh, three geographies, forty-two integrations, twelve thousand employees. He asked me one question: is this real. I told him what I tell everyone who shows me a plan like that. The dates are real. The scope is not. Something in that triangle is going to slip, and if nobody names which side before the kickoff, the project will name it for them at month seven. This is the conversation nobody wants to have during a pitch. Vendors sell aggressive dates because aggressive dates win RFPs. Buyers accept aggressive dates because they need a business case that clears the CFO. Nine months sounds decisive. Fourteen months sounds like the vendor is padding. So everybody signs, and then everybody spends the second half of the project renegotiating what “live” actually means. The honest number for a full mid-to-large ServiceNow implementation is not nine months. It’s twelve to eighteen, and the shape of those months matters more than the total.

An infrastructure lead at a European insurer called me last month with what he thought was a workflow problem. His team’s change request form on ServiceNow had grown to sixty-two fields. The approval routing had eleven conditional branches. Emergency changes were sitting in the queue for two days waiting for a rubber-stamp signature. His CIO had asked him to fix the form. The form was not the problem. The form was the last place anyone looked for a problem that started in the change advisory board eighteen months earlier. This is the pattern I see in most mid-market change management ServiceNow deployments. The platform is doing exactly what it was configured to do. The configuration reflects a set of decisions the CAB made, or failed to make, over years of drift. And by the time someone escalates, the diagnosis has already been misdirected at the tool.

A CIO at a 900-person specialty chemicals group phoned me on a Tuesday in June. His voice had that specific flatness you hear from people who have been in meetings since seven in the morning. The ServiceNow platform his team had been building for eleven months was going live in three weeks, and he had just been told by his own implementation partner that the CMDB was not going to be ready for wave two. Not “delayed by a sprint” not ready. Not populated, not governed, not integrated with the discovery tool they had already paid for. He wanted to know whether it was worth pausing the go-live or pushing through. I asked him when he had first suspected the CMDB was in trouble. He said month four. I asked why he had not called anyone in month four. He said he thought his internal team could handle it, and by the time he was sure they could not, it felt too late to bring anyone else in. That is the pattern. Mid-sized enterprises call for outside ServiceNow consulting services when they are already on fire, and the fire is usually something that started five months earlier as a small design decision nobody caught. If you are a CIO or a platform owner at a mid-market company running…

A logistics software vendor called me last spring. Their support was drowning. Sixty enterprise customers, an average of eight named contacts per customer, and a ticketing tool that treated every email as a fresh conversation with a fresh stranger. Agents were opening cases with no idea whether the person on the other end was a paying admin at the parent company, a subcontractor at a regional depot, or a warehouse temp who had been given a shared login by his manager. The renewal team was blind to any of it. When the account executive walked into a QBR she was reading the same PDF as the customer, hoping nothing awkward came up. They had bought a “customer service” tool. What they needed was a B2B service platform. Those are different products, even when the logo on the login screen is the same. This is the shape of most ServiceNow CSM problems I see in mid-market B2B. The tool is fine. The configuration is a consumer playbook wearing a B2B badge. If your customer is a company, not a person, you need the platform to know that from the first click.

An IT director at a Benelux logistics group phoned me last month with a question that has become uncomfortably common. She had shortlisted three small ServiceNow consultancies for a HRSD build after a bad experience with a Big 4 firm. Two of the three had polished decks, similar day rates, and near-identical LinkedIn profiles. She could not tell which of them would actually deliver, and which was two ex-Accenture managers with a Squarespace site and a subcontractor pool in Poland. She wanted a diligence framework she could run in a week that would give her a defensible answer. That question deserves a proper answer, because the market has quietly filled up with boutique ServiceNow consulting firms that look identical from the outside and diverge sharply the moment you scratch the surface. The good ones are the best value in the ecosystem. The bad ones are worse than the Big 4 they claim to replace, because they combine boutique pricing risk with none of the boutique operational depth. This post is the checklist I have watched work, refined over roughly forty introductory calls in the last year.

A CFO at a mid-market industrial group walked into a ServiceNow renewal meeting last spring with a printout and a red pen. He had the previous three years of platform spend on one side and the original business case on the other. He circled two numbers and asked the CIO a single question: which of these did we actually get. The IT team had a slide deck ready. Ninety-two percent CSAT. Sub-fifteen-minute MTTA. Four-thousand automated password resets a month. The CFO listened, put the printout down, and said the numbers were fine but none of them lived on his P&L. Then he asked what a fair renewal would look like if the platform stayed and what a fair one would look like if it went to their Big 4 partner’s homegrown tool for a third of the licence cost. The IT team lost that argument in the room. Not because the platform was underdelivering, but because for three years they had been selling the wrong benefits to the wrong buyer. When people ask about the servicenow itsm benefits, they usually mean the operational ones. Faster tickets. Better dashboards. Fewer angry users. Those matter, but they are not what keeps a platform funded through the third renewal cycle. What keeps it…

A programme director at a mid-cap European insurer called me at eight on a Sunday evening. Her Big 4 partner had just filed a fourth timeline slip on a fifteen-month HRSD and ITSM programme that was now approaching twenty-two months. The steering committee had voted on Friday to switch. Her question was not whether the decision was right. It was, “What do I actually do on Monday morning.” That is the conversation nobody in the sales cycle prepares you for. Everyone tells you how to build the business case to switch ServiceNow partner. Almost nobody tells you what the first ninety days after the switch actually look like, or how you avoid trading one broken programme for another one. Firing the incumbent is the easy part. The next thirteen weeks decide whether the switch was worth the fight. This post is the playbook I hand to clients in the first two weeks after they make the call. It is not a marketing framework. It is what has to happen, in what order, so the platform is stable, the client team is back in control, and the new partner can actually deliver against a plan that survives contact with the instance.

A procurement lead at a European retail chain sent me three quotes last month and asked me to explain why they were so different. All three vendors had been briefed against the same document. A Big Four systems integrator quoted €1.4 million for the ITSM and HRSD build. ServiceNow’s own professional services team quoted €980k. A boutique firm on my recommendation quoted €520k. She wanted to know whether the boutique had missed something, whether the Big Four had padded, or whether the vendor was quietly the best deal in the room. The honest answer took an afternoon of reading the small print and a call with each partner about how they staff a project. That is the conversation every buyer eventually has. The public rates people quote for ServiceNow consulting costs make the three delivery models look roughly comparable, and then the actual invoice arrives and they are not comparable at all. If you are running a competitive procurement right now, or trying to decide whether the price you are being quoted is fair, you need to understand what you are actually buying inside each of the three quotes. The rate card is the smallest part of it.

A CIO at a European medical devices group walked me through his eighteen-month plan last week. ITSM in wave one. HRSD and CMDB in parallel in wave two, four months later. SecOps and a customer portal in wave three, another six months after that. The board had already seen a Gantt chart with three neat rectangles stacked in sequence, each shorter than the one before. The programme sponsor had committed to the dates. The vendor had priced the whole thing at a discount if it landed inside the eighteen-month window. He asked me one question. Was any of it real. The honest answer is that a multi-module ServiceNow implementation timeline almost never survives contact with wave two, and the reason is not the platform. The reason is that the client organisation gets tired somewhere around month five, the vendor rotates the A-team off the account after go-live, and nobody wrote down what the interlock between waves actually costs in decision bandwidth. By the time wave two kicks off, the muscle that carried wave one is exhausted and the assumptions the plan was built on have quietly stopped being true. This post is about how to sequence a multi-year roadmap so that does not happen.

A COO at a 900-person medtech firm called me in early July. Their ServiceNow ITSM rollout had gone live in February. The partner shook hands, delivered the last training webinar, and demobilised the team. By June the platform owner had two hundred open change requests in her personal backlog, an incident queue that nobody trusted, and a steering committee that had stopped meeting because there was nothing left to steer. On paper the implementation was a success. In practice she was six months into what she now recognised was the real project, and she had no partner in the room to help her run it. That gap is the single most damaging feature of how ServiceNow consulting services for mid-sized enterprises are usually sold and delivered. The industry contracts, prices, and pitches around the implementation. It leaves the twelve months after go-live to be figured out later. In the enterprise segment that gap is filled by a large managed services contract with the same firm that built the platform. In the mid-market it usually gets filled by silence, and the silence has a cost.

A CIO at a €900m distribution business called me two weeks ago, three months before her Big 4 managed services contract came up for renewal. She was not angry. She was tired. Her team had lived through eighteen months of a ServiceNow rollout under a top-tier firm and the platform worked. Tickets flowed. Reports ran. The board was mostly satisfied. What she wanted to understand was why every meaningful decision felt slower than it should, and why the people she saw at kickoff had all rotated off the account by month four. I have had a version of this conversation four times this year. The pattern is consistent enough that it stopped being a coincidence and became a structural observation about how large firms sell ServiceNow work, and what that structure prevents them from delivering. The point of this post is not to argue that a Big 4 firm can never do good ServiceNow work. Plenty of them do. It is to be honest about the trade-offs baked into the Big 4 delivery model on the ServiceNow platform, and about the specific situations where a boutique ServiceNow consulting partner is not just cheaper but structurally better.

An operations director at a €600m industrial group called me last week. Two years into a ServiceNow ITSM programme. The board had approved the business case on the strength of a slide that promised 30 percent MTTR reduction, 20 percent fewer P1 incidents, and a payback under eighteen months. Now the CFO wanted to know why the finance team could not find those numbers anywhere in the actuals. I have had that conversation more times than I care to count. The answer is almost always the same. The ServiceNow ITSM benefits that make it into a business case are not the same benefits that show up on a P&L twelve months later. Some of the promised numbers are real but got captured in the wrong line item. Some were measured against a baseline nobody bothered to lock down before go-live. And a handful were pure fiction from the outset, borrowed from a vendor slide that nobody in operations ever validated. If you are a CFO, an ops director, or a service owner reading this because someone is about to ask you to defend or extend a ServiceNow investment, this post is for you. I am going to walk through which ITSM benefits actually land, which ones evaporate on contact with real reporting, and…

A CIO at a listed European retailer sent me a two-line email last month. “We know we need to switch ServiceNow partner. The CFO wants a business case. Can you help me build one that survives the audit committee?” That is the question I get most often now. Not “should we switch” but “how do we defend the switch in a boardroom where the incumbent has a fifteen-year relationship with the CEO and the audit chair remembers signing the master services agreement in 2019.” The technical case for switching is usually the easy part. Any competent platform owner can list the defects, the slippage and the OOTB literacy gaps. What breaks in the boardroom is the financial narrative. When the current partner is a globally recognised name, the CFO’s default position is that a switch introduces risk, not that staying does. Reversing that intuition requires numbers, not adjectives. This piece is the framework I use with clients who need to build the case for a switch that will hold up under adversarial scrutiny from a procurement director, a group auditor and a non-executive with a long memory.

The head of IT operations at a Central European bank called me last autumn with a complaint I have heard so often I now expect it. His team had spent nine months and roughly €180k building out ServiceNow Performance Analytics. Sixty-two dashboards, four hundred and eleven indicators, weekly scorecards emailed to the executive committee. The complaint was that nobody read any of it. The CFO admitted in a steering committee that he had not opened a single one. The COO opened them for the first fifteen seconds of the executive meeting and then asked her assistant to summarise. The CEO had never logged in. This is not a technology problem. Performance Analytics does everything it says on the tin. The problem is that most ServiceNow Performance Analytics deployments confuse producing metrics with producing decisions, and executives at the top of a business are only interested in the second one. If your dashboards are being ignored, the fix is not a nicer visualisation library or a bigger screen in the boardroom. The fix is admitting that the reports you built were designed for the analyst who built them, not for the person who was supposed to act on them.

A CIO at a Central European insurance group called me in April with a very short question. Her ServiceNow programme had been signed off at €1.2 million eighteen months earlier. The current actual spend was €2.1 million. The platform was live in ITSM only, roughly half the original scope, and her CFO wanted an explanation before he approved another cent. She wanted to know whether her partner had ripped her off, whether her team had failed her, or whether this was just what a ServiceNow build looks like in the real world. The honest answer, which took me three days of reading her contracts and change notes to give her, is that it was all three at once, and none of the individual causes were dramatic enough to notice while the project was running. That is the pattern I see in almost every conversation about ServiceNow consulting costs. The headline day rate and the signed statement of work almost never predict the final invoice, because the money that kills the budget is not on either document. It shows up quietly in change notes, environment fees, extension weeks, and the specific overtime the buyer pays their own people to compensate for the partner’s assumptions.

A programme director at a European insurance group called me on a Tuesday morning. Their ServiceNow ITSM rollout had been running for four months. The SOW said six months to production. Every weekly status report for the first three months had shown green. Then, in weeks fourteen and fifteen, three things happened in quick succession. The vendor’s lead architect rolled off to another project. UAT started and immediately surfaced eighty-seven defects the vendor said were “expected.” And the security team, brought in late, said the ACL model needed to be redesigned before go-live could be approved. The status report was still green when he opened it. He was calling because he already knew it was not. This is the conversation I have every few weeks now. Somebody halfway through a ServiceNow implementation timeline realises the plan they signed off in kickoff has quietly stopped being the plan they are on. The vendor has not raised a red flag. The steering committee has not asked hard questions. But the trajectory is wrong, and the person calling me can feel it in their bones before the numbers confirm it. This post is for them.

A CIO of a 1,200-person insurance broker sent me his RFP last week. Twenty-eight pages. Seventeen scoring dimensions. A weighted matrix that would not have looked out of place at a defence procurement office. He wanted an outside opinion before he sent it out to five shortlisted partners. I read it on the train home from Vienna and called him the next morning. I told him the RFP was excellent, thorough, and would almost certainly help him pick the wrong partner. He was quiet for a moment and then asked what I meant. What I meant is that the RFP was optimised for the wrong buyer. It was a scale-down of the RFP a Fortune 100 uses to buy from a Big 4. It scored partners on things that matter when you are running a hundred-million-euro programme with three parallel workstreams and a dedicated PMO. It scored almost none of the things that determine whether a mid-market ServiceNow implementation actually ships on time and gets adopted after go-live. If you sit in the 300 to 3,000 employee band and you are about to send a ServiceNow RFP into the market, the evaluation criteria you use to sort responses will decide the next two years of your platform’s life. This is not the same…

A CIO at a €300M industrial firm rang me last month. He’d just finished a bake-off between two Deloitte practices and one boutique shop, and he wanted a sanity check before signing. The Deloitte proposal came in at €1.4M for a phase-one ITSM and CMDB rollout across three regions. The boutique quote was €480k for the same scope, with fewer bodies but named senior architects on every workstream. His board was pushing him toward Deloitte. His gut said the boutique. He asked me to help him think it through honestly. I don’t sell against the Big 4 by default. I’ve watched boutique shops blow deadlines just as badly as Accenture, and I’ve watched Deloitte crews save a floundering programme that a specialist SI had already botched. The question “should I hire a big four firm or a specialist SI” doesn’t have a universal answer. It has a set of conditions, and the sensible thing is to walk through them before signing anything. There are scenarios where a Big 4 practice is genuinely the right call, and pretending otherwise is dishonest.