The New Trend in Customer Sensitivity Towards Customization on the ServiceNow Platform

[Jeff Benedict]

I started working with a new client this month and was intrigued by how tightly they controlled any customizations to the ServiceNow platform.  There does appear to be a trend sweeping through the ServiceNow community where customers have a newfound sensitivity to any customization, and I get it—ServiceNow has done a good job of communicating the impacts of modifying their out-of-the-box (OOB) offerings. But here’s the real crux of the matter: is any customization truly that bad? Spoiler alert: it’s not about avoiding customization altogether but making smart, informed customizations that add real business value.

First, let's clarify what we mean by "customization." Traditionally, customization refers to modifying the existing OOB code. That might include altering UI Policies, Business Rules, or even Client Scripts that come with your ServiceNow instance. Understandably, these changes can result in skipped records come upgrade time, potentially introducing bugs or elongating your upgrade cycle.

However, in our rush to avoid these pitfalls, we might be ignoring the bigger picture—the value that smart customization can bring to our business processes. In trying to dodge the so-called “dangers” of customization, are we also shying away from potential enhancements that could streamline workflows or deliver a more intuitive user experience?

What can we do about this? The answer, I believe, lies in how we evaluate our customization efforts. It’s not sufficient to veto all changes outright. Instead, we should be scoring and grading them based on a simple yet effective framework. Consider this: not all customizations are created equal. Some modifications are deeply embedded in well-established aspects of ServiceNow—areas that are stable, tried, and tested. Others might target areas that are new or evolving, perhaps even slated for adjustment in an upcoming ServiceNow release.

When assessing a potential customization, ask yourself the following:

1. Is it part of an established ServiceNow feature? Customizations to mature features might be less risky.  Further, simple updates like label changes are easy to review and skip during an upgrade.
2. Is this a new area of the platform? Innovations and new functionalities are usually on the ServiceNow radar, meaning changes here could collide with new releases.  Example: Workspace changes or customizations to new offerings such as procurement operations will likely be on the collision course in upcoming upgrades.
3. Does it align with the ServiceNow roadmap? It’s crucial to stay informed about where ServiceNow is headed strategically.  Am I creating something that will be an OOB feature in a future release?

So, how do you manage this delicate balancing act? The secret is to develop a comprehensive scoring system to grade whether the customization is worth pursuing. Here’s a quick guide on how to do this:

• Business Impact: Will the customization significantly benefit business operations or user satisfaction?
• Technical Feasibility: How complex is the customization from a development standpoint?
• Maintenance Overhead: What will be the long-term cost of maintaining this customization through future upgrades?
• Roadmap Alignment: Does this customization align well with ServiceNow's published roadmap?

When it's all said and done, platform governance becomes your best friend. Establishing a strong governance framework will enable you to manage these customizations effectively while minimizing technical debt. Deploy a governance model that is tailored to your organization’s specific needs.

I welcome your insights on how others have successfully navigated this balancing act, and I hope we can collectively shift the narrative to recognize that not all customizations are evil.