ServiceNow: Platform first, platform forever

My journey with ServiceNow didn’t start with a grand plan; it started with a near miss— literally. In 2004, I almost ran over Fred Luddy. I was driving through our shared hometown when he stepped into the crosswalk in front of me. Thankfully, I saw him. We recognised each other, as I’d worked for him at a previous company.

One thing led to another, and he invited me to check out what he was working on. A few days later, he showed me a very early build of what he called the Glide platform (which is now the ServiceNow AI Platform). It was missing all sorts of features, functions, and capabilities it has now, but the core concepts, from the metadata-driven user interface to the intrinsic relational model built into the data structures, were present even then.

I didn’t really get it in that first demo. My mind immediately thought of all the things I could not do with Fred’s platform rather than all the things that could be done more simply. Still, I was intrigued by the idea of working on something new with somebody I respected, so I decided to join.

Fred Luddy’s key insights

When Fred founded ServiceNow in 2004, he had a very specific vision. He wanted to build a platform that would allow anyone to create meaningful business applications. We may not have reached the point back then where my mother (who’s a very smart but nontechnical human) could have created an app, but we did succeed in radically reducing the complexity of the process.

Although we ended up going to market with our IT Service Management (ITSM) applications, the platform vision remained and evolved. And it’s still relevant today as we look at industry developments such as agentic AI.

In hindsight, Fred really had three distinct insights about the market and technology’s ability to solve them. Part of his genius was being able to apply new technology to old problems.

1. Platform: Fred believed that simplification was a feature. If he simplified the acts of creating, modifying, and updating an application sufficiently, that would more than offset the value lost by restricting what a user could do. By making it dramatically easier to perform frequent activities, people wouldn’t stress about not being able to do some of the more obscure things they could do with other technologies of that era.

2. Browser: In 2004, the idea of delivering software via a browser was novel. The default at that time was to ship desktop application-based “fat” clients, and it wasn’t unusual for a knowledge worker to have dozens of unique client apps on their workstation. By switching to browser-based apps, Fred was ahead of the curve, in that he already saw the browser as the new Universal Client.

3. Delivery model: Fred had experienced all the downsides of traditional software delivery firsthand, since he’d been in the industry for nearly 30 years at that point. He knew the value he could offer with an evergreen software as a service (SaaS) application the customer wouldn’t have to support, manage, or operate.

Overcoming early challenges

Although we got the big things right, we had some rather significant business challenges to deal with. The simplest of those challenges was selling an enterprise platform. When your company is basically half a dozen people working in the basement of your venture capital firm, it’s kind of an awkward sales discussion.

We ended up in a number of pitch meetings where we demonstrated all the power of the platform only to hear the customer ask, “Yes, but what can you do with it?” We tried to turn the question around by asking, “Well, what do you want it to do?”

We wrote the original set of ITSM applications that helped drive our initial public offering to show off the power of the platform. Back then, people were much more interested in buying apps than in the platform itself, so that became our default sales motion.

Another challenge was that the public cloud infrastructure we take for granted today didn’t exist then. If we wanted to deliver software via a SaaS model, we needed to buy servers, lease data center space and cable racks, lay out networking, and do all the physical infrastructure stuff a cloud requires.

Getting the cloud right was, in many ways, harder than getting the product and platform right. We’re good cloud operators now, but we weren’t in 2004. We needed lots of on-the-job training because there weren’t many people with that skill set back then.

The platform was the goal

Regardless, we stuck to the original product vision of a platform an average person could use to build business applications. Although we were going to market as an apps company, we kept architecting the technology stack with a platform lens.

The apps we sold to our customers were pure play platform apps. Every single one could have been written by a customer who had access to the platform.

Some customers figured this out and started building their own apps on the platform to do all sorts of interesting stuff. For example, CERN, a European scientific research center, built an entire site management suite on top of ServiceNow. This enabled a visiting researcher to use our Service Catalogue to manage everything from desk lamps to access to the Large Hadron Collider.

We’ve stuck with that model through the years, and it’s one of the reasons we’ve been able to expand the breadth of our product area so easily into other areas, such as HR, customer relationship management, security, and legal.

If you want to model a business process—and it has structured data, multiple steps, approvals, notifications, and assignments—the ServiceNow Platform remains one of the most productive ways to do so.

Key milestones and lessons learned

When I look back at how ServiceNow grew as a company, there were a few pivotal points where we faced unexpected circumstances and made the right decisions.

First was deciding to whom we wanted to sell. The original business concept included the idea that SaaS was going to be a midmarket play and we’d have many small and midsize customers. Early in our journey, though, we started landing big, enterprise customers, such as Edmunds.com, TIAA-CREF, and Deutsche Bank.

We had to make a call at that point as to whether we wanted to invest in the kind of features major enterprises needed or stay focused on our core, midmarket play. Ultimately, we did both. And by adding a lot of enterprise-grade functionality, we pivoted and moved the platform and applications upmarket.

A second inflection point occurred during the Great Recession in 2008. It hit the economy like a freight train and disrupted the software industry. People’s budgets and behaviors changed dramatically.

The Great Recession was a tail wind for us, because one of our core value propositions was that ServiceNow was better than the competition and, from a total cost of ownership standpoint, cheaper. We were in the right place at the right time, and our newly minted enterprise credibility enabled us to have conversations with buyers about saving money, one of their top priorities.

We could scale up to enterprise workloads because we’d designed the platform with a tenancy model and clustering structure that allowed us to run the operations of big customers. Similarly, we could save customers money because of our SaaS and deployment model.

From AI to agentic AI

We’ve been offering some form of AI tooling on the platform for at least a decade. We started off using supervised machine learning to solve simple tasks such as assigning and prioritising cases. Given time and good training data, we could deploy AI that helped save customers time and money.

That same platform architecture continues to bear fruit for ServiceNow in the agentic AI era. When new tech comes along, we have to add it only once. Then it’s available to all our customers across all our products.

Agentic AI systems built on large language models (LLM) are far more sophisticated than those early machine learning solutions, and far more generalisable in how they can be applied. Today we don’t need to train a model to prioritise cases. We can just have it tell us how to prioritise a list of customer requests. And it’s at least as good as an average human would be if given the same task.

Additionally, agentic AI systems can perform more sophisticated reasoning tasks that previous generations of AI couldn’t even conceptualise. For example, an AI agent running on the ServiceNow AI Platform can figure out that Mary’s email account is locked because she hasn’t completed the mandatory security training.

That’s an ITSM use case, but AI agents can address similar challenges across every business function. For example, AI agents can walk you through the process of modifying your healthcare enrollment because you just had a baby (an HR use case).

Calculated risks for continuous improvement

As I look back at the history of the company, I’m struck by how much the agentic AI revolution feels like those early days of ServiceNow. AI technology is evolving incredibly rapidly. We don’t yet have clearly defined models, rules, or approaches to help us solve problems—or even to identify which problems are worth solving.

Managing velocity is a significant challenge when you have 8,400 customers. When we were smaller, with just 84 customers, shipping a bug that affected one customer wasn't a big deal. Now, the stakes are much higher.

Fortunately, our platform has come to the rescue, enabling us to track our development efficiently. We release agentic AI updates frequently and embrace innovation as technology evolves, ensuring we deliver the best features and functionality as quickly as possible.

However, for our core platform services—from the user interface to workflows to business applications—we use a traditional release model. This approach helps us maintain the quality required for these mission-critical systems.

The platform's underlying separation of concerns model allows us to achieve this in a way that wouldn't be technically feasible with many other architectures.

It’s always a bit reductive to try to summarise something as complex as a company’s history down to one point. But if I had to, it would be this: The best decision we ever made was to build a platform-centric product rather than an application-centric one.

It’s a decision that’s helped us at various points throughout the years and continues to help us—and our customers—today.

Find out more about the benefits of the ServiceNow AI Platform for business transformation.