Service Portal vs Employee Service Center - 2026

[MrCheck]

We're about to stand up a new instance of ServiceNow, most likely Zurich.  We're using a different product altogether right now so we're basically starting from scratch.  We will have customers who will have accounts in our instance, but they will be from numerous other companies, not just our own.  They will need to create incidents, select things from the service catalog, search knowledge articles, and other things related to service desk operations.  

Some of what I'm seeing suggests we should go with a legacy /sp Service Portal approach for this since it's more geared for handling external users (this could certainly be wrong/outdated info).

Some of what I'm seeing suggests we shoiuld go with an /esc Employee Service Center approach for this since it's the way of the future.  But other things I see say certain /sp capability doesn't exist in /esc

So... since everything I'm reading is from the past (since I don't have a time machine), in May of 2026, what is the recommended approach for setting up a new instance as described above?  /sp or /esc?

Any advice would be appreciated.

[Dr Atul G- LNG · Accepted solution]

Hi @MrCheck 

Go for Employee Center (ESC), as it is now recommended by ServiceNow as the standard approach.

The ESC portal comes with many new features, and the best part is that it is taxonomy-based, making configuration much easier and more structured.

[AshishArch]

You described external customers from multiple companies creating incidents, using a service catalog, and searching knowledge — that is a Customer Service Management (CSM) scenario, not an Employee Service Center scenario. As this would be external customer facing and follow the CSM data model. 

If your use cases is B2B (Business to Business) consider reviwing the "Business Portal" capabiltiites to best align with your enterprise Architecture. 

 If your use case is B2C (Business to Consumer) consider reviwing the "Consumer Service Portal " the fitment with your Enterprise architecture. 

Out of the box in CSM, an external user raises a Case — not an Incident. The Case is then triaged by first-line support, and if needed, an internal Incident or Request is created and linked to the Case.

What customers can do from Business Portal / Consumer Portal

Yes, all of the following work natively:

• Submit cases (what they'll think of as "raising an incident")
• Browse and submit service catalog requests — catalog is surfaced in the portal
• Search knowledge articles — KB is integrated and searchable
• Track status of their open cases and requests

[Peter Hansen1]

How are you treating your customers in terms of roles? Are they purely snc_internal? Do you segregate access / data through DENY-Unless ACLs? The point I’m trying to make is that the esc portal is like name suggest the employee portal. Have you talked with your account teams in terms of utilizing the CSM module instead or getting the required license/subscription need for this instead? Your customers would then raise cases instead that your first line could deal with. Some of these cases might require “additional work” like incidents or request fulfillment.

[Tanushree Maiti]

Hi @MrCheck 

When to Select Employee Center (EC/EC Pro) - Recommended

Choose Employee Center for a modern, unified employee experience that spans across departments. It is the future-ready, out-of-the-box (OOTB) standard. 

•  You need a single portal for HR, IT, Legal, Facilities, and Finance (not just IT).
•  You want to organize content by topic (e.g., "Onboarding," "Benefits") rather than by department.
•  You want a consumer-grade, modern UI, AI-powered search, and personalized content without building it from scratch.
• You plan to expand the portal to new departments later and need a scalable structure.
• You want seamless integration with the ServiceNow "Now Mobile" app

When to Go for Service Portal (/sp) - Legacy/Specialized

Use the traditional Service Portal for simple, heavily customized, or IT-centric use cases where the overhead of an enterprise portal is not required. 

• Your organization requires a unique, custom-coded look-and-feel that departs completely from standard frameworks.
• You only need a basic page for employees to submit incidents or request hardware.
• You have already built extensive, tailored functionality on/sp and migrating is not currently feasible.
• You have complex, existing widgets that rely on the old Angular JS framework and cannot be easily ported to the new theme engine.