MadeLogic blog

A healthcare technology provider resolves customer cases 20% faster with MadeLogic.

info@madelogic.com (MadeLogic) — Sat, 03 Oct 2026 17:52:14 GMT

A healthcare technology provider cut mean time to resolve by 20%, increased case deflection by 30%, and shortened customer onboarding by 40% after moving its customer support onto ServiceNow Customer Service Management with MadeLogic.

20%

faster mean time to resolve

30%

more cases deflected to self-service

40%

shorter customer onboarding

The customer.

The company builds technology that hospitals and health systems rely on every day. Its support organization is responsible for more than answering questions: it brings new customers live, keeps installed systems running, and is the first call when something at a customer site stops working.

For this business, support quality is part of the product. A slow answer is felt by clinical and operations teams on the other end.

The challenge.

As the customer base grew, the support model did not scale with it. Requests arrived by phone and email, and agents pieced together the customer's history from more than one system before they could begin work. Cases were routed by hand, so the right specialist was often the second or third person to see an issue.

Customers had little visibility. There was no single place to open a case, check its status, or find an answer without calling. Onboarding a new customer depended on manual coordination between teams, which made timelines hard to predict.

The goal was specific: resolve cases faster, let customers help themselves where they could, and make onboarding a repeatable process rather than a one-off effort each time.

What MadeLogic delivered.

MadeLogic designed and implemented ServiceNow Customer Service Management as the single system for customer support. Six capabilities were in scope:

CSM Configurable Workspace. One screen for agents, with the customer, their history, and the open case side by side.
Case management. A consistent case lifecycle for support and onboarding work, with clear ownership and service-level tracking.
Knowledge management. Articles written from resolved cases, available to agents in the workspace and to customers in the portal.
Advanced Work Assignment. Cases routed automatically by skill, availability, and workload, so they reach the right agent first.
Business Portal. A self-service front door where customers open cases, track status, and search knowledge.
IVR integration. Phone calls connected to the platform, so the caller is identified and the agent starts with context instead of questions.

The approach.

The work started with the support process, not the product. MadeLogic mapped how cases and onboarding actually moved through the organization, removed the handoffs that added delay, and then configured the platform to match the simpler version.

The implementation stayed close to out-of-the-box. Standard CSM capabilities were configured rather than customized, which keeps the platform straightforward to upgrade and easy for the customer's own team to run.

The results.

Mean time to resolve fell by 20%. Agents work from one workspace with the full customer record in front of them, Advanced Work Assignment puts each case with the right person at the start, and the IVR integration means phone cases arrive with the caller already identified.

Case deflection rose by 30%. Customers now find answers in the Business Portal before they open a case, drawing on a knowledge base built from the issues the support team resolves most often.

Customer onboarding time dropped by 40%. Onboarding runs as structured case work with defined steps and owners, and new customers can follow progress in the portal instead of waiting for an update.

The support team now runs on a single platform, with one view of every customer and a process that holds up as volume grows.

ServiceNow is winning the CRM race. The reasons are architectural.

info@madelogic.com (MadeLogic) — Wed, 23 Sep 2026 14:45:04 GMT

For most of the last twenty years, “which CRM” was not really a question. You bought Salesforce, you hired a Salesforce team, and you spent the next decade integrating everything else around it. That assumption is now breaking, and it is breaking for a reason most CRM comparisons miss entirely. The decision is no longer about which vendor has the better opportunity object. It is about which platform can carry a customer record from the first quote through the sale, the install, the field visit, the support case, the security incident, and the project that fixes the root cause, without a single hand-off to another system.

Only one of the two platforms was built to do that, and it was not built as a CRM. That turns out to be the point.

One data model, one instance.

Strip away the marketing and the architectural difference is simple. ServiceNow runs every application, from ITSM to CRM to project management, on a single relational data model in a single instance. Nearly every piece of work on the platform, whether it is a case, a work order, an incident, a project task, or a change, inherits from the same base table. That is why a customer case can spawn a change request, a change can spawn a field work order, and a work order can roll up into a project, with reporting and SLAs that span all of them, and no integration layer in between.

Salesforce grew the other way. Sales Cloud, Service Cloud, Field Service, Marketing Cloud, Industries, Data 360, MuleSoft, Slack, Tableau, and now Informatica and Contentful came from different codebases and different acquisitions, each with its own data model and, in most cases, its own licence. Data 360's “zero copy” architecture is a clever answer to a problem ServiceNow customers do not have: the data was never in one place to begin with. In Salesforce's most recent quarter, Data 360 ingested 104 trillion records, 82 trillion of them via Zero Copy. That is an impressive number for a data layer. It is also an admission of how much of the customer picture lives somewhere other than the CRM.

For an executive, the plain-language version is this: on ServiceNow, your customer, their products, the equipment you installed at their site, the technician who serviced it, and the ticket they opened last Tuesday are rows in one database that already know about each other. On Salesforce, making those things know about each other is a project, and usually an ongoing one.

The CMDB, and why a CRM needs one.

The configuration management database is the most underrated asset in the CRM argument, because most CRM buyers have never thought of it as a CRM asset at all.

The CMDB is a graph of every thing your company operates, discovered automatically, with the relationships between them: this server runs this application, which supports this business service, which is sold to this customer under this contract. ServiceNow's Common Service Data Model extends that graph outward to the customer through sold products and install base records, so “what did we sell this account” and “what is running at this account” are the same query.

Salesforce has an Asset object. It is a flat record with a name, a serial number, and a lookup to the account. It has no discovery, no dependency mapping, no health, and no concept of a service being composed of other things. If a product you sold has a firmware vulnerability, a ServiceNow customer can run one query to find every affected install base item, every account that owns one, every open case tied to those items, and the field technician nearest each site. A Salesforce customer opens a spreadsheet.

This matters more every year, because the customer relationship is increasingly a relationship with the things you have installed, not just the people you sold them to.

Field service management.

Nowhere is the architecture more visible than in field service management. On ServiceNow, a work order is a task record. It links directly to the configuration item or install base item being serviced, to the case that triggered it, to the parts in a specific stockroom, to the technician's skills and schedule, and to the contractor or crew if the work is outsourced. Dispatcher Workspace, dynamic scheduling, appointment booking, crew operations, offline mobile, and inventory transfer orders are all native features reading the same tables. When the technician closes the task, the CI is updated, the case can auto-resolve, and the time and parts flow into cost reporting without anyone re-keying anything.

Salesforce Field Service is a capable scheduling engine, and the platform's own comparison guides position it as best for CRM-native enterprise service, which is exactly right: it is built around the service appointment and the case, with the asset as an attachment. It does not know what the asset depends on, what else is at the site, or whether IT is already working the same failure as an incident. For companies whose revenue depends on equipment uptime, in manufacturing, medical devices, telecom, utilities, and managed services, that is not a feature gap. It is the difference between a field tool and an operating model.

Building and configuring on the platform.

Ask a Salesforce developer how much of a typical implementation ends up in Apex, and watch their expression. Custom triggers, Lightning Web Components, governor limits, managed-package conflicts, and the eternal question of which org a given piece of logic lives in are the daily reality of a mature Salesforce estate. The platform is extensible, but extension means code, and code means a permanent development team.

ServiceNow's default mode is configuration. Flow Designer, IntegrationHub spokes, App Engine Studio, scoped applications, and a UI framework that reads the same schema mean that the majority of a CRM implementation is done by administrators and architects rather than engineers. When code is needed, it runs in the same instance against the same tables as everything else, with no cross-cloud plumbing. The platform's twice-yearly family releases upgrade the whole estate at once, because it is one estate. Gartner has named ServiceNow a Leader for the sixth time in its Magic Quadrant for Low-Code Application Platforms, and ranked it first for the building-and-managing-AI-agents use case in the companion Critical Capabilities report. That is a low-code ranking earned by a platform that also happens to be a CRM. Salesforce's equivalent story requires Flow, Apex, OmniStudio, and MuleSoft, sold and skilled separately.

Sales, CPQ, and the Logik acquisition.

The honest criticism of ServiceNow's CRM two years ago was that it was a service platform wearing a sales badge. Sales and Order Management was real, but configure-price-quote was thin. On May 30, 2025, ServiceNow acquired Logik.io for $506 million, and it did not buy a lightweight quoting tool. Logik.ai is an API-first, composable CPQ platform with a proprietary configuration and solving engine, built for companies selling products complex enough that the quote itself is an engineering exercise. The technology is especially relevant in manufacturing, high tech, and medical devices, which are, not coincidentally, the same industries where the CMDB and field service arguments land hardest.

The result is a lead-to-cash path that runs from opportunity, through a constraint-solved quote, to an order, to fulfilment tasks, to an install base record, to the service and field workflows that record was born to trigger. On the Q2 2026 earnings call, ServiceNow said CRM and industry workflows appeared in 16 of its top 20 deals, with 15 over $1 million. CRM, Industry, and Core Business Workflows now make up 32% of net new annual contract value, up from 30% a year earlier, on a base that is growing more than 20% a year. That is not a company dabbling.

AI agents, and the security acquisitions behind them.

Both vendors are selling AI agents, and both are reporting large numbers. Salesforce says Agentforce ARR exceeded $1.5 billion, up over 240% year on year, though that figure now includes its AI offerings, Slackbot, and Headless 360. ServiceNow's AI ACV crossed $1 billion in Q2 2026, ahead of its own $1.5 billion target for the year.

The more useful comparison is what the agents are doing. An agent is only as capable as the actions available to it, and on ServiceNow the actions are the platform: create the change, dispatch the technician, reserve the part, open the project, update the CI. ServiceNow reports that more than 40 customers running Level 1 ITSM automation are seeing request closure rates near 80 to 85% without human interaction, and CEO Bill McDermott described a large airline running its customer service voice calls on ServiceNow's voice AI CRM agents, live and handling 5 million calls in year one. Those are vendor-reported figures, but they describe agents executing work, not summarising it.

Salesforce's constraint is structural. Anything living outside Salesforce is invisible to the agent unless you build the pipe yourself or invest in Data 360. And the pricing has moved from per-conversation, to Flex Credits, to per-user add-ons, to seat-based editions in roughly eighteen months. IBM's own survey of Salesforce customers found 64% say unclear total cost of ownership makes it hard to know whether AI agents will save money. ServiceNow, meanwhile, launched Otto at Knowledge 2026 as a unified AI experience combining Now Assist, Moveworks, and AI Experience, and an AI Control Tower that governs every AI system, agent, and workflow regardless of where it runs, including agents that are not ServiceNow's.

The security side of this is easy to miss. In 2026, ServiceNow acquired Veza, an AI identity security company, for approximately $1.2 billion, and then completed its roughly $7.75 billion acquisition of Armis, which brings real-time cyber asset discovery, prioritization, and protection across IT, OT, IoT, medical devices, critical infrastructure, code, and cloud.

Read that list again with a CRM hat on. Medical devices. OT. Critical infrastructure. Those are the installed products of a medical device manufacturer, an industrial OEM, and a utility. Armis feeds the CMDB with the security posture of the things a company has sold and services, and Veza governs who and what, including AI agents, is allowed to touch the record. The vendor that knows your customer's install base is now also the vendor that knows whether it is exposed, and can route the fix through the same field and case workflows. Salesforce has no equivalent, and no obvious path to one.

Projects, resources, and time.

Every CRM evaluation has a moment where someone asks the question the vendor did not prepare for. Ours tend to sound like these: a services firm needs a signed order to become a delivery project with resourced consultants and billable time. A managed service provider needs a customer escalation to become a remediation project with a budget. A manufacturer needs warranty work tracked against the install base and rolled into cost of quality.

On ServiceNow, Strategic Portfolio Management, Resource Management, and Time Card Management are native applications on the same task hierarchy as CRM. Resource plans allocate the same users and groups who work the cases. Time cards post actuals to the project and, through IntegrationHub, to the ERP. There is no integration to build because there is nothing to integrate; a project task and a customer case are siblings in the schema. Salesforce customers solve this with a PSA product from the AppExchange, a separate contract, and a synchronisation job that someone owns forever.

Industry data models.

Both vendors sell industry editions. The architectural difference is that ServiceNow's are extensions of one model rather than separate products layered on top. Financial Services Operations adds accounts, households, consumers, and regulated case types to the core CRM tables. Healthcare and Life Sciences Service Management adds patient, provider, and device relationships on the same install base and CMDB. Manufacturing Commercial Operations connects dealer and distributor accounts to sold products, warranty, and field service. Telecom uses TM Forum-aligned order and service models. ServiceNow has said it will keep evolving vertical-specific Autonomous CRM features across financial services, telecommunications, healthcare, manufacturing, government, and retail.

Because the vertical models inherit from the core, a customer can start in one industry and extend into another without re-platforming, and everything Flow Designer, the CMDB, and the AI agents know about the base tables applies automatically. Salesforce Industries, which began life as Vlocity, still carries its own OmniStudio toolset and data patterns, so the industry cloud is in practice a second platform to learn.

Where Salesforce is right now.

None of this is to say Salesforce is failing. It reported record revenue in its latest quarter, with cRPO accelerating to 14% growth. The concern is focus. In under a year the company has closed an $8 billion Informatica deal, bought Regrello, Qualified, and Contentful, and agreed to acquire Fin, formerly Intercom, for roughly $3.6 billion, a customer-service AI agent that overlaps directly with Agentforce Service. It is building an ITSM offering inside Slack. It is executing a $25 billion accelerated share repurchase funded with debt. Each move is defensible in isolation. Together they describe a company assembling, by acquisition, the connected platform that ServiceNow already has, while asking customers to absorb a new pricing model every few quarters. Futurum's analysts have started using the phrase platform fatigue and warning of a new wave of CRM churn if the ROI does not show up.

ServiceNow's acquisitions, by contrast, all point the same direction: Logik for the quote, Moveworks for the front door, Veza and Armis for identity and asset security, every one of them landing on the same instance and the same schema. It expects $1.5 billion in AI revenue in 2026, it maintained a 98% renewal rate and ended the quarter with 658 customers over $5 million in ACV, and the strategic message has not changed in three years.

Josh Brostoff Joins MadeLogic as Co-Founder

info@madelogic.com (MadeLogic) — Fri, 18 Sep 2026 03:40:32 GMT

Former GlideFast leaders reunite to build an architect-led ServiceNow partner with customer relationships at its core

BOSTON, MA — September 18, 2026 — MadeLogic, an architect-led ServiceNow consultancy, today announced that Josh Brostoff has joined founder Top Tanti as Co-Founder and Principal Architect. The appointment reunites two of the early leaders behind GlideFast Consulting, one of North America's most successful ServiceNow partners.

Together, Brostoff and Tanti are building MadeLogic around a simple premise: start with the customer's business problem, and measure success by what is actually delivered in production.

The two first worked together at GlideFast Consulting, where they helped grow a boutique practice into one of the leading ServiceNow partners in North America. GlideFast was acquired in 2022 by ASGN Incorporated, the parent company of Apex Systems, for $350 million.

Tanti is a ServiceNow Certified Technical Architect (CTA) with more than 12 years of experience on the platform. Brostoff most recently led the ServiceNow practice at Slalom and previously served as Vice President of CRM at GlideFast. Both began their careers in engineering and in-house roles at ServiceNow customer organizations, giving them firsthand experience running the platform, not just implementing it. Having sat on the customer side of consulting engagements themselves, they understand what separates a vendor from a true partner, and what it takes to make that partnership work.

Between them, they have led large, multi-year ServiceNow programs for highly regulated organizations across the public and private sectors, from Fortune 100 technology companies to government and defense agencies.

Architect-led, from design to delivery

Every MadeLogic engagement is led by a senior architect who remains accountable from initial design through go-live. The people who scope the work are the same people who deliver it, so nothing is handed off after the sale closes and nothing is lost in translation. Customers work with a team that understands their goals from day one and is ready to move quickly. Every project starts with the business problem rather than the technology, and success is measured in working, quantifiable results.

CRM is MadeLogic's core focus, an area where its architects bring some of their deepest experience and where ServiceNow continues to invest heavily. The same architecture-first approach extends across the broader ServiceNow platform.

Growth built on repeat customers

Since its founding, MadeLogic has grown primarily through referrals and repeat business, with more than 90 percent of revenue coming from returning customers.

Brostoff's arrival expands MadeLogic's senior architecture capacity and advances the firm's vision for a different kind of ServiceNow partner: one where experienced architects stay close to customers, delivery teams understand the business behind what they build, and long-term relationships matter more than any single project.

“Josh and I have delivered together for more than a decade, and there's no one I'd rather build this with. We want MadeLogic to be a place where talented people love coming to work and customers feel that energy in the way we deliver. We're building a team that works side-by-side with customers to solve the right problems.”
— Top Tanti, Co-Founder and Principal Architect, MadeLogic

“Top and I have spent the better part of the last decade implementing ServiceNow across hundreds of companies. We have always shared the same vision for what a ServiceNow partner should be: an architect-led company where the people leading the business understand the work firsthand and where exceptional delivery is at the center of everything we do.”
— Josh Brostoff, Co-Founder and Principal Architect, MadeLogic

About MadeLogic

MadeLogic is an architect-led ServiceNow consultancy with a core focus on CRM. Founded by senior platform architects who built their careers inside ServiceNow customer organizations, MadeLogic helps public and private sector organizations design, implement, and scale solutions across the ServiceNow platform.

The firm measures its work by business results, long-term adoption, and the quality of what customers are left with after go-live.

Learn more at madelogic.com.

Now Assist and Agentic AI in ServiceNow: The Implementation Sequence That Actually Holds Up

info@madelogic.com (MadeLogic) — Thu, 10 Sep 2026 02:58:14 GMT

Most Now Assist programs we get called into aren't failing because the models are bad. They're failing because the sequence was wrong. Somebody bought Pro Plus, turned on every skill the Now Assist Admin console would let them, pointed it at a knowledge base nobody has curated since 2019, and then wondered why the summaries were wrong and the agents didn't trust it.

Sequence is the whole game. Generative AI on the Now Platform is a mirror: it reflects the quality of your data, your process discipline, and your governance back at you, at scale, in front of every user. If those are good, Now Assist looks like magic. If they're not, it looks like a liability. And once you move into AI Agents, that mirror starts taking actions.

This is the order we recommend, and why. It's written for platform owners, service owners, and the architects who have to defend the roadmap in a steering committee. It assumes you're on Zurich or Australia. If you're older than that, the upgrade is item zero, not item one.

The short version of this whole post. Skip a layer and the one above it will look broken. It isn't; it's reporting on the gap underneath.

Baseline: Earn the right to turn it on

Nothing in this phase is AI. All of it decides whether AI works.

Platform currency and posture

You need Zurich at minimum, and Australia if you intend to run AI Agents seriously this year. The AI Agent Studio, AI Control Tower, and the Guardian controls have moved fast release over release, and being N-1 on this specific capability set means missing real functionality, not just patches. Get the upgrade done, get Instance Scan clean on the AI-relevant findings, and confirm your Now Assist Store apps are pinned to the family you're actually on. We've seen more than one program lose a month because the Now Assist ITSM app was two versions behind the platform.

Data quality, specifically the data the models will read

Be precise about this. Now Assist for ITSM doesn't need your whole instance to be clean. It needs:

Incident and case short descriptions, descriptions, work notes, and close notes. Summarization and resolution-note generation read these. If your agents have been closing tickets with "fixed" for five years, summarization will faithfully tell you the ticket was fixed.
Knowledge articles. Both Now Assist Q&A in Virtual Agent and AI Search Genius Results are grounded in KB content. Run a knowledge audit before anything else: article age, ownership, view-to-helpfulness ratio, duplicates, and whether the article actually contains steps or is a stub pointing to a wiki nobody can reach. Retire ruthlessly. A 400-article knowledge base that's accurate beats a 4,000-article one that isn't.
Categorization and assignment data. Not for the LLM directly, but for the classic Predictive Intelligence models you should still be running. PI classification and similarity are cheaper, faster, and more predictable than a generative skill for routing. Don't rip them out because something newer showed up.
CMDB and CSDM alignment, if you plan to go anywhere near ITOM alert analysis or change risk. The models will describe the topology you have, not the one you wish you had.

Security and privacy controls

This is where legal, security, and the platform team need to be in the same room before a single skill is enabled:

Now Assist Guardian configuration: sensitive data handling, offensiveness filtering, and prompt injection protection. Decide what "sensitive" means for your organization and configure the data classifications accordingly. The default is a reasonable start; it is not your policy.
Vault (or your existing encryption and data classification approach) for fields that should never reach a model. Know which fields those are before you find out in a summary.
Domain separation implications if you're an MSP or run a separated instance. Skill availability and data scoping behave differently, and you want to test this explicitly.
Which provider you're using. Now LLM versus bring-your-own model through the Generative AI Controller has legal and residency implications. Decide once, document it, and put it in the AI governance charter.

Licensing and metering

Now Assist consumption is metered in assists. Understand your entitlement, what counts as an assist for each skill, and how consumption gets reported. Set up the Now Assist analytics dashboards on day one so you have usage and adoption data from the first hour of go-live. You will need this data for the business case for the next phase, and you can't reconstruct it later.

Governance and measurement baseline

Stand up an AI governance group now, while the stakes are low. It should own the skill catalog, approve new skills and agents, own the Guardian policy, and review the AI Control Tower inventory once that's in play. Keep it small: platform owner, a service owner or two, security, and someone from legal or compliance who returns emails.

Then capture the baseline numbers you'll be asked to move: mean time to resolve, average handle time, first-contact resolution, self-service deflection, KB creation rate, and agent time on documentation. If you can't say what those were before Now Assist, you won't be able to say what Now Assist did.

Lesson learned:

The single most common cause of a stalled program is skipping this phase because the license clock is running. Four weeks of baseline work here is the difference between a pilot that expands and a pilot that quietly gets turned off.

Crawl: Assistive skills, human always in control

The goal of Crawl is not ROI. It's trust, telemetry, and operational muscle memory. Pick skills that are read-only from the platform's point of view, that produce text a human reviews before anything happens, and that are hard to get catastrophically wrong.

Where to start

Now Assist for ITSM, agent-facing skills:

Incident summarization in the Now Assist panel. Highest adoption, lowest risk, immediately visible value on handoffs and escalations.
Resolution notes generation. Agents review and edit before saving. This also starts fixing your close-notes data problem going forward, which pays off in later phases.
Knowledge article generation from resolved incidents, routed through your existing KB approval workflow. Do not let this publish directly. Ever.
Chat and interaction summarization for agents handling Virtual Agent or live chat handoffs.

Now Assist for Creator, for the platform team:

Code generation and flow generation in the IDE and Workflow Studio. Low external risk, keeps your own team learning the tooling before they have to support it for others.

AI Search Genius Results for end users, if your KB audit came back clean. If it didn't, hold this until Walk. A bad answer in a search result is a bad answer in front of everyone.

What to hold

Now Assist Q&A in Virtual Agent is tempting, and it's fine if your knowledge is solid, but it's the first place a stale article becomes a customer-visible problem. Treat it as a late-Crawl or early-Walk item gated on KB health, not a day-one item.

Process, not just configuration

Roll out by assignment group, not by instance. Turn on skills for two or three high-volume groups, get their feedback, tune, and expand. The Now Assist Admin console makes this easy to do and easy to skip.
Tell agents what changed and why. A panel appearing with no explanation gets ignored or mistrusted. A fifteen-minute walkthrough with the group lead who volunteered gets used.
Review the outputs. Sample summaries and resolution notes weekly for the first six weeks. You're looking for hallucinated details, tone problems, and sensitive data leaking into notes. The Guardian catches some of this; humans catch the rest.
Report assists and adoption monthly. Skill usage by group, thumbs up and down feedback, and the trend line. This is the data that funds Walk.

Lesson learned:

Summarization quality tracks ticket data quality almost one to one. Teams that see poor summaries usually discover the problem is their own work notes. That's a useful discovery, but it's better to have it in Baseline than to have it in front of a skeptical service desk lead.

Second lesson: Don't enable every skill because it's included. Every skill you turn on is a skill you have to explain, monitor, and defend. Five well-adopted skills beat twenty half-used ones.

Walk: Extend, ground, and customize

You've got trust and data. Walk is about breadth across workflows, grounding the models in your own context, and building the custom skills that generic ones can't cover.

Broaden across products

Now Assist for CSM: case summarization, agent response generation, and Q&A grounded in your customer-facing knowledge. Same discipline as ITSM, with more attention to Guardian tone and sensitive-data controls because the output can be customer-visible.
Now Assist for HRSD: case summarization and knowledge Q&A. HR has the strictest data sensitivity of anything you'll touch; involve the HR data owner from the start, not after the first complaint.
Now Assist for ITOM: alert analysis and grouping explanations. Only worthwhile if your CMDB and service mapping are credible.
Now Assist in Virtual Agent with LLM-based topic discovery and Q&A, now that the knowledge base has been through a cycle of scrutiny.
Dynamic translation across VA and agent workspace if you support multiple languages. Underrated and often a quicker win than anything else in this list for global orgs.

Ground the models in your data

This is where Workflow Data Fabric and the zero-copy connectors earn their keep. Skills and agents are only as useful as what they can see, and a lot of what matters lives in Snowflake, Databricks, a data warehouse, or a SaaS system that isn't ServiceNow. Bringing that context in without ETL means the summarization of a customer case can actually reference the customer's contract state, or a change can be assessed against real deployment history.

Build custom skills

Now Assist Skill Kit is the tool. Use it when a generic skill is close but not right: a summarization that needs to follow your major incident communication template, a generation skill that needs to reference a specific set of fields, a classification that needs your taxonomy. A few rules that have served us well:

Write the prompt like a spec. Inputs, expected output structure, what to do when information is missing. Vague prompts produce vague skills.
Test against real records from your instance, not synthetic examples. Keep the test set and re-run it after every platform or model update.
Version and document every custom skill in the governance catalog. In six months nobody will remember why it was built the way it was.
Prefer a custom skill over hacking a UI Action to call the Generative AI Controller directly. The Skill Kit gives you metering, Guardian integration, and analytics for free. Direct calls give you none of that.

By this point you'll have people asking for "an agent" for everything. This is the decision we walk teams through before anything gets built:

Harden governance

Tune Guardian based on what you saw in Crawl. You have real data on false positives and misses now.
Get AI Control Tower running so you have an inventory of every skill, custom skill, and (soon) agent on the platform, who owns it, and what data it touches. This becomes non-negotiable in Run; it's much easier to establish here.
Formalize a skill lifecycle: request, review, build, test, approve, monitor, retire. It sounds bureaucratic. It's the reason you'll still have control in a year.

Lesson learned:

The hardest part of Walk is almost never technical. It's that each new workflow brings a new business owner with a different risk appetite and a different definition of "good enough." The governance group exists so those conversations happen once, in one place, with a shared standard, rather than in every steering committee.

Run: Agentic AI, with a human deciding how much rope

Everything up to now has been generating text for a human to act on. Agents act. That changes the risk profile completely, and the architecture and governance need to reflect it.

The building blocks

AI Agent Studio for defining agents: their role, instructions, tools, and the guardrails around them.
Tools are what agents can do: Flow Designer flows and subflows, scripts, record operations, retrieval over your knowledge and data, and integrations exposed through Integration Hub or Agent Fabric and MCP-style connections to external systems. The tool set defines the blast radius.
AI Agent Orchestrator coordinates multiple agents against a goal. This is where cross-functional work happens, and where the failure modes get interesting.
Agentic playbooks in Zurich and Australia embed agents into your existing playbooks with human checkpoints. For most organizations this is the right on-ramp: the process stays visible, the human stays in the loop, and the agent handles the steps that are tedious and well-defined.
AI Control Tower for monitoring, auditing, and inventory across everything above.

Sequence inside Run

Read-only agents first. Triage agents that gather context, check similar incidents, pull CI health, and post a recommendation as a work note. They never change a record state. You get to evaluate their judgment with zero operational risk.
Bounded write agents with approval. Agents that draft a change, populate a case, or propose a resolution, with a human approving before anything commits. Agentic playbooks are the natural home for this.
Autonomous agents for narrow, reversible, high-volume work. Password resets with verification, access provisioning within pre-approved entitlements, alert enrichment and correlation, routine catalog fulfillment. Reversible is the key word. If the action can't be undone cleanly, it stays behind an approval.
Orchestrated, multi-agent workflows only after you've seen single agents behave in production for a meaningful period and you have evaluation data to back the expansion.

Engineering discipline that matters more here

Tool design is the real work. A well-scoped subflow with clear inputs and outputs makes a reliable agent. A tool that can "update any record" makes an unpredictable one. Give agents the smallest tool set that gets the job done.
Write evaluation sets before you build. Fifty representative scenarios with expected outcomes. Run them on every change to instructions, tools, or the underlying model. Agents drift; the eval set tells you when.
Instrument everything. Every agent run should be traceable in Control Tower: what it was asked, what tools it called, what it decided, and why. When something goes wrong, and it will, this is how you find out whether it was the instructions, the tool, the data, or the model.
Set explicit supervision levels per agent and treat moving an agent from supervised to autonomous as a governance decision with evidence attached, not a checkbox a developer flips.
Don't build an agent where a flow will do. If the logic is deterministic, Flow Designer is cheaper, faster, and auditable by anyone. Agents earn their cost when the work requires judgment, context gathering, or handling variation a flow can't express.

Lesson learned:

The organizations that get value from agents fastest are the ones that were rigorous in Walk. They have clean tools because they built custom skills properly, they have governance because Control Tower is already populated, and they have baseline data so they can prove what changed. The organizations that jump straight to Run typically spend the first quarter rebuilding the foundation they skipped, except now with an executive who was promised autonomy watching.

What the timeline actually looks like

Every steering committee asks the same question: how long? The honest answer is that it depends almost entirely on the state of your knowledge base and your close notes, not on the AI. But "it depends" doesn't get a program funded, so here's a reference timeline and three variations we've seen play out.

Reference: mid-size enterprise, ITSM-led, Pro Plus

A few things to notice in that picture:

Phases overlap. Control Tower and the skill lifecycle start while Crawl is still expanding. Read-only agents start while custom skills are still being built. Waiting for each phase to fully close is how an 8-month program becomes a 12-month one.
The checkpoints are governance events, not project milestones. The go/no-go at week four is a real decision. We've recommended "no" at that point more than once, and every time it was the right call.
Run doesn't finish. The arrow past month 8 is deliberate. Agents are an operating model, not a deliverable.

Three variations on that timeline

Profile	What's different	Baseline	Crawl	Walk	First autonomous agent	Total to Run
Mature platform — Zurich or Australia, KB governed, CSDM done, existing PI models in use	Baseline is mostly verification. Crawl can roll out to all ITSM groups in one wave.	2–3 weeks	4–5 weeks	2–3 months	Month 5	~5–6 months
Reference — healthy instance, some KB debt, ITSM-first	The timeline above.	4 weeks	6 weeks	3.5 months	Month 7–8	~8 months
Data debt — N-2 or older, 8k+ articles nobody owns, close notes say "resolved"	Upgrade plus a real knowledge program before anything visible ships. Expect executive pressure to skip this. Don't.	2–3 months	2 months	4 months	Month 11+	11–13 months
Multi-workflow from day one — ITSM, CSM and HRSD all funded, three business owners	Baseline is per-workflow: three KB audits, three sensitivity reviews, one governance body. Crawl runs in parallel with ITSM two to four weeks ahead.	6 weeks	2.5 months	4 months	Month 9	9–10 months

The number to watch isn't total duration; it's time to the first adoption report with real numbers in it. In the reference timeline that's month two. If you're past month three without one, something in Baseline was skipped and the program is about to find out which thing.

What compresses the timeline, and what doesn't

Compresses it: a knowledge base someone actually owns, a platform team that's already on Zurich or Australia, an existing governance body you can extend rather than create, and a service desk lead who wants this to work.

Doesn't compress it: buying more licenses, adding more developers to Baseline, or starting with agents "because that's where the value is." The value is where the data is.

Outcomes by phase

Phase	Core features	What you should be able to show
Baseline	Zurich/Australia upgrade, KB audit, Guardian and Vault config, assists entitlement, Now Assist analytics, governance charter	Clean KB metrics, documented AI policy, captured MTTR/AHT/deflection baselines
Crawl	Now Assist ITSM summarization and resolution notes, KB generation with approval, Creator code/flow gen, AI Search Genius Results	Adoption by group, reduced documentation time, agent feedback scores, assist consumption trend
Walk	CSM/HRSD/ITOM skills, Now Assist in VA, dynamic translation, Workflow Data Fabric, Skill Kit custom skills, Control Tower inventory	Measurable MTTR and AHT movement, deflection lift, custom skills in a governed catalog
Run	AI Agent Studio, agentic playbooks, Orchestrator, Agent Fabric integrations, Control Tower monitoring	Autonomous resolution rate for targeted use cases, audited agent runs, evaluation pass rates, cost per resolution

The point of view

There is real pressure to move fast on this, and the platform makes moving fast easy. That's exactly why sequence matters. Every phase above builds an asset the next one depends on: the data that grounds the models, the telemetry that funds the expansion, the governance that lets you say yes safely, the tools that make agents predictable.

You can compress the timeline. You can't skip the steps. The organizations we've watched succeed treated Now Assist as a platform capability with a lifecycle, not a feature to be switched on. The ones that struggled treated it as a procurement event.

If you're trying to figure out where your instance sits on this sequence, or you've already turned things on and want to know what to fix first, that's a conversation we have often. Get in touch with MadeLogic.

ServiceNow CSM Best Practices: Lessons from 100+ Implementations

info@madelogic.com (MadeLogic) — Tue, 18 Aug 2026 17:30:00 GMT

Each project has brought its own unique challenges, but some lessons have consistently stood out. Like any product that's relatively new to the market, CSM hasn't always come with a clear-cut "best practice" playbook. Over time, we've developed our own set of best practices—shaped by successes, setbacks, and everything in between. With CSM now the fastest-growing product line in ServiceNow, we're sharing some of the key insights we've gained, hoping they'll help others navigate their own implementations more effectively.

1. Maintaining data quality

Ensuring the data integrity of customers is critical for a successful and scalable Customer Service Management (CSM) implementation. Allowing cases to be created for contacts or consumers without an associated account can lead to poor data quality, security risks, and duplicate records. Requiring account association also mitigates security risks by enforcing authentication and identity validation before case creation.

Key considerations:

Registration requirement: Contacts or consumers should register through the CSM/CSP portal to establish an account before cases can be created. Allowing anyone to email in and creating a "shell" consumer/contact record is a fast track to bad data.
Identity provider integration: Leverage an identity provider (e.g., Okta, Azure AD) to provision and authenticate accounts securely.
Email restrictions: Cases should not be created from emails that are not linked to a registered and verified account, ensuring that only authenticated users can interact with the system.
Data quality assurance: Validate that all required account and contact fields are completed during the registration process to maintain data integrity.
Security compliance: Implement controls to ensure compliance with security and privacy standards, such as verifying the identity of users creating cases.
Required fields: Ensure that First Name, Last Name, Email, and Account (if on contact) are mandatory fields during registration or case creation to maintain data integrity and completeness.

2. Case types

When to use case types

Case types should be used when the organization has distinct processes that vary significantly based on different work types, business units, or products, each necessitating unique workflows and UI experiences. If there are significant variations in state models, attributes, or back-end systems across these processes, creating separate case types is essential. This ensures tailored management, improved efficiency, and better access control for each specific process.

Considerations for case types

When starting a new implementation, evaluate some key questions:

Are there different processes based on work types or business units?
Are there different processes based on products and services that are being supported?
Do the different processes have different state models?
Are there a large number of attributes captured for each process that are very different from each other?
Is each business unit or team interacting with a different set of back-end systems to resolve the case?
Are there different support teams working on different case types, thereby making it necessary to restrict access to cases?
Do the agents working on these issues need a different experience and guidance for each issue type?

If the answer to these questions is yes, then it is best to extend the case table to create new case types for each discrete process. [1]

Application scopes

When creating new case types in ServiceNow, it's considered a best practice to place each case type in its own scope. This practice ensures better organization, modularity, and security of your configurations. By isolating each case type within a separate scope, you can avoid cross-scope access issues, which enhances the maintainability and scalability of your case management system.

Placing a case type in a scope allows you to manage and encapsulate all the related artifacts—such as business rules, client scripts, UI policies, and workflows—within a defined boundary. This modular approach not only helps in organizing the components related to a specific case type but also makes it easier to apply updates, troubleshoot issues, and maintain the system over time. Each scope can have its own set of permissions and access controls, ensuring that only authorized users can modify or access the configurations within that scope.

CSM case types example:

3. Service Level Agreements

Running SLAs between Case and Incident

When using Service Level Agreements (SLAs) in an environment where the CSM with ITSM plugin is activated, it is important to clearly define where SLAs should be applied to ensure clarity and accountability.

SLAs for customer support: SLAs for the customer support team should be run on the Case table. These SLAs are designed to track and ensure timely resolution of customer-facing issues, focusing on the commitments made to the customer.
OLAs for internal teams: If a Case requires the creation of an Incident to address internal issues (e.g., a developer needs to resolve a bug in the codebase), the Incident should have a separate SLA. This SLA governs the internal agreement between teams within the organization and ensures the necessary work is completed to support the customer issue without directly impacting the customer-facing SLA.
Separation of responsibility:
- The Case SLA represents the organization's commitment to the customer.
- The Incident OLA reflects the internal operational agreement, ensuring collaboration and resolution within agreed timeframes.

By maintaining this separation, organizations can effectively manage both external customer expectations and internal team responsibilities, ensuring a seamless and scalable approach to SLA management.

4. Shared tables

ServiceNow Customer Service Management (CSM) utilizes several shared tables that are pivotal in managing customer and vendor information. These tables include the Account [customer_account], Consumer [csm_consumer], and Contact [customer_contact] tables. Proper management and configuration of these tables ensure data integrity, appropriate access control, and efficient data display tailored to different stakeholder groups.

Customer accounts

In ServiceNow Customer Service Management (CSM), the shared Account [customer_account] table is a crucial component for managing customer and vendor information. To ensure data integrity and appropriate access control, it is essential to separate account data based on specific stakeholder groups without relying on access controls or before queries. The best practice for achieving this separation is to leverage the out-of-the-box Vendor Type field and create new choice values for each stakeholder group.

Leveraging the Vendor Type field

Step 1: Understanding the Vendor Type field. The Vendor Type on the Customer table is a choice field designed to categorize accounts. By default, this field includes various vendor types, which can be extended to include new stakeholder groups. This allows for dynamic filtering and display of account data based on the selected vendor type.

Step 2: Creating new choice values. To separate data for different stakeholder groups, you need to create new choice values in the Vendor Type field. Each choice value will represent a specific stakeholder group:

Navigate to the Vendor Type field: Go to Accounts > Vendor Type > Configure Dictionary.
Add new choice values: Click New to create a new choice. Enter the Label and Value for each new stakeholder group (e.g., "Retail Customers," "Wholesale Vendors," "Partners"). Save the new choice values.

Step 3: Updating existing records. Ensure that all existing records on the Account table are updated to reflect the correct Vendor Type. This may involve bulk updating records through a fix script.

Dynamically displaying account data

Configuring module conditions. To dynamically show account data to each stakeholder group, add conditions to the modules that display account records. This can be done by configuring the module's conditions based on the Vendor Type field:

Navigate to the module: Go to the application navigator and locate the module you wish to configure (e.g., Accounts).
Add conditions: Click on the module to edit its properties. In the Link type, select List of Records. In the Condition field, add a condition to filter records based on the Vendor Type (e.g., Vendor Type is "Retail Customers").
Save the module configuration: Save the changes to apply the condition.

Contacts

For the Contact [customer_contact] table, you can leverage dot-walking to dynamically show contacts based on the parent Vendor Type. This allows you to filter contacts by the Vendor Type of their associated account or consumer:

Navigate to the module: Go to the application navigator and locate the Contacts module you wish to configure.
Add dot-walk conditions: Click on the module to edit its properties. In the Link type, select List of Records. In the Condition field, add a dot-walk condition to filter contacts based on the parent Vendor Type (e.g., Account.Vendor Type is "Retail Customers" or Consumer.Vendor Type is "Wholesale Vendors").

Shared CSM data model example:

5. Authentication

Avoid local authentication, leverage SSO

Leverage Single Sign-On (SSO): Single Sign-On (SSO) authentication should always be utilized for consumers and contacts to streamline and secure the authentication process. SSO enables users to log in with a single set of credentials across multiple platforms, enhancing security by enforcing centralized password policies and reducing the risk of password-related breaches. For consumers and contacts, this also means a smoother and more efficient login experience, reducing friction and improving satisfaction.

Avoid local authentication: In the context of Customer Service Management (CSM), it's best practice to avoid using local authentication for consumers and contacts due to security risks and management complexities. Local authentication can result in inconsistent password policies, higher chances of unauthorized access, and increased administrative overhead in managing user credentials.

Provisioning best practices: Implement automated user provisioning through SSO to ensure that consumer and contact accounts are consistently and securely managed. This includes automatic creation, updating, and deactivation of user accounts based on their status in the identity provider. Automated provisioning reduces the risk of orphaned accounts, ensures compliance with access policies, and simplifies user account management, particularly for large and dynamic consumer bases.

Planning a CSM implementation, or trying to get more from one that's already live? These are the conversations we have every week. Get in touch with MadeLogic.

Securing Customer Data in ServiceNow CSM: Access Control, Authentication, and Encryption Best Practices

info@madelogic.com (MadeLogic) — Wed, 15 Jul 2026 19:00:00 GMT

When exposing data externally to customers, the risk of security breaches and data leakage increases, especially on a platform that houses both internal and customer data. ServiceNow operates as a shared responsibility platform, meaning that while the platform provides built-in security features, organizations are responsible for configuring and managing access controls, authentication policies, and data protection measures.

Over the years, I've compiled a set of best practices for securing CSM data, helping organizations mitigate risks and avoid common pitfalls. By following these guidelines, you can ensure a secure implementation while minimizing the chances of costly security incidents.

The platform ships the controls. Every practice below is about the half of the model that belongs to you.

Access control

Application scopes

Creating ACLs for all case types

Implementing ACLs: It's a best practice to create Access Control Lists (ACLs) for all case types in ServiceNow Customer Service Management (CSM). ACLs define the permissions required to access and modify case records, ensuring that only authorized users can perform specific actions such as create, read, update, or delete.

Best practices for ACLs:

Role-based access: Define ACLs based on user roles to ensure that permissions are appropriately granted.
Condition-based controls: Use conditions within ACLs to apply access rules dynamically based on specific criteria.
Regular reviews: Periodically review and update ACLs to adapt to changes in user roles and organizational requirements.

Utilizing CSM query rules

Implementing Customer Service Management (CSM) query rules in ServiceNow is a best practice for managing data visibility and access efficiently. Query rules allow you to define and enforce conditions that control which records are displayed to users based on their roles and specific criteria.

Authentication

Avoid local authentication, leverage SSO

Restricting case creation to users with consumer or contact records

Restrict case creation: It's a best practice to restrict case creation in ServiceNow Customer Service Management (CSM) to only those users who have valid consumer or contact records. Allowing case creation for users without these records can lead to data inconsistencies, unauthorized access, and difficulties in managing and resolving cases effectively.

Ensure data integrity: By restricting case creation to users with established consumer or contact records, you ensure that all cases are associated with verified and identifiable individuals. This practice maintains the integrity of your case data, making it easier to track, manage, and resolve cases efficiently. It also helps in maintaining accurate records of interactions and communications with consumers and contacts.

Enhanced security: Restricting case creation helps prevent unauthorized users from submitting cases, thereby protecting your instance from potential abuse and ensuring that only authenticated and validated users can interact with your CSM platform. This security measure reduces the risk of fraudulent activities and ensures that only legitimate issues are addressed.

Requiring authentication before case creation

Mandatory authentication: Requiring users to authenticate before creating cases in ServiceNow Customer Service Management (CSM) is a critical best practice. This ensures that only authorized individuals can submit cases, maintaining the integrity and security of your case management system. Authentication helps verify the identity of the user, ensuring that all submitted cases are legitimate and associated with verified consumer or contact records.

Security issues with public case submission: Allowing public, unauthenticated case submissions poses significant security risks. Unauthenticated submissions can lead to spam, fraudulent cases, and potential abuse, overwhelming your instance (e.g. denial of service attacks) and making it difficult to manage and resolve legitimate issues. Public case submission also increases the risk of exposing sensitive information to unauthorized individuals, which can compromise the security and confidentiality of your data.

Adaptive authentication

Adaptive authentication enhances security by dynamically enforcing access controls based on user context, such as role, IP address, and location. Adaptive Auth evaluates authentication requests against predefined policies, granting or denying access based on risk factors. For example, a user logging in from an untrusted location may require multi-factor authentication (MFA), while a trusted user on a corporate network experiences seamless access.

This approach is a best practice because it strengthens security without disrupting user experience. By enforcing stricter authentication only when needed, organizations reduce friction for trusted users while blocking unauthorized access. It also extends to REST API access control and supports domain separation, ensuring tailored security across business units. Adaptive authentication helps ServiceNow customers balance security and usability, reducing breach risks while maintaining smooth access.

Credit: ServiceNow documentation on adaptive authentication.

PII/PHI customer data

Encrypting sensitive data in ServiceNow Customer Service Management (CSM) is a critical best practice to protect confidential information from unauthorized access and breaches. Encryption transforms data into a secure format that can only be accessed by individuals with the correct decryption key, ensuring that sensitive information remains confidential even if it is intercepted or accessed by unauthorized users.

Best practices for data encryption:

Identify sensitive data: Determine which data needs to be encrypted based on its sensitivity and regulatory requirements.
Encrypt data at rest and in transit: Ensure that sensitive data is encrypted both when stored (at rest) and when transmitted over networks (in transit).
Regular audits: Conduct regular security audits to verify that encryption methods are properly implemented and up to date.

Methods of encrypting sensitive data:

Column Level Encryption: Column Level Encryption (CLE), formerly Encryption Support, permits and denies access to encrypted data based on user role.
Cloud Encryption: Uses a ServiceNow-generated key or a customer-created key to protect sensitive data at rest in ServiceNow datacenters. It employs FIPS 140-2 Level 3 validated hardware security modules (HSM) and AES 256-bit encryption.
Full Disk Encryption (FDE): Encrypts the entire storage system within the database server. This method is suitable for customers with legal obligations to protect data.
Edge Encryption: Encrypts sensitive data on a company's premises before sending it to a ServiceNow instance over the internet. Edge Encryption includes tokenization, which masks specific data patterns within a field, and mass key rotation, which automatically encrypts data with new keys to protect historical records.
Database Encryption (DBE): Another method for customers with legal obligations to protect data.

Sensitive data handling in Agent Chat and Virtual Agent

Detect and mask sensitive information: In ServiceNow, it's a best practice to configure the Sensitive Data Handler to automatically detect and mask sensitive information shared in Agent Chat or Virtual Agent conversations. This involves setting up rules to identify sensitive data such as personal identifiers, financial details, or proprietary information, and then masking this data to prevent exposure. This approach enhances data security, ensures compliance with privacy regulations, and protects sensitive information from unauthorized access during conversational interactions.

The short version

Scope every case type. Write ACLs and query rules for all of them. Never let an anonymous or locally-authenticated user create a case. Encrypt what regulation or common sense says to encrypt, and mask what customers type into chat. None of it is exotic; all of it is your responsibility, not the platform's.

If you're exposing CSM to customers and want a second set of eyes on how it's secured, that's a review we do often. Get in touch with MadeLogic.