Interested in a ServiceNow event built for developers? Registration for now[dev]26 is officially open!

mmcdonnell
ServiceNow Employee

Implementation and Setup Essentials

 

Objective

This article covers the foundational principles and setup essentials for a healthy Financial Services Operations (FSO) implementation. It is written for implementers, solution consultants, partners, and customer teams who are standing up FSO or looking to strengthen an existing build. Rather than a step by step configuration guide, it lays out the patterns that keep an implementation scalable, maintainable, and ready for AI, organized around four areas that every FSO deployment touches.

 

Start With These Principles

A few principles apply across every part of an FSO build. Getting them right early saves significant rework later.

  • Favor out of the box over custom. OOTB capabilities are maintained, tested, and enhanced with every release. Custom work becomes a long term maintenance tax and can lock you out of future improvements.
  • Extend, do not reinvent. FSO ships base cases and data models built for financial services. Extend them rather than building parallel structures from scratch.
  • Build for AI readiness. A clean case model and a solid customer data foundation are what make generative and agentic AI useful. AI grounded in messy data disappoints.
  • Design for scale. Ask whether each design choice will still serve the business in five years, not just at go live.

 

mmcdonnell_0-1787511357258.png

 

  1. Intake and Routing

How work enters the platform and reaches the right person. A few things to get right:

  • Start work inside the Financial Services Workspace, work should start natively inside the workspace, not through a service catalog launched in an iframe that drops the agent on a success page and loses customer context when they navigate back.
  • Guide complex intake. For onboarding or claims, a conditional, multi step form shows a user only the fields their situation calls for. One intake form with thirty-plus fields on a single record producer
  • Capture data as fields, not variables. Fields are reportable, routable, and usable by AI. Variables trapped on a record producer are none of those.
  • Route by capacity and skill. Advanced Work Assignment sends work to the right person automatically. When someone is out, their queue does not sit idle.
  1. Case Management

How work actually gets done once it lands. The essentials:

  • Separate quick interactions from real cases. If every call and email opens a case, your handle time and resolution metrics lose meaning. Use interactions for live-channel and one-and-done contact; open a case when the work needs documentation, follow-up, and resolution.
  • Guide agents with playbooks and drive task creation with Task Plan Templates. Playbooks give a stage-based path through the case; Task Plan Templates make the underlying steps repeatable and configurable by a business user. Both help new hires ramp without relying on tribal knowledge.
  • Let the platform do the work. Flows, business rules, notifications, and SLAs execute the process rather than just tracking it. Configure fulfillment steps as templates, and a process owner can adapt to a regulatory change without a developer and a deployment.
  • Add AI where it earns its place: summarization, classification, guided next steps, all grounded in a clean case model.
  1. UX and People

Whether the platform helps people get their job done. What matters:

  • Standardize on the Financial Services Workspace. It is the gateway to Advanced Work Assignment, Agent Assist, Customer 360, playbooks, and AI.
  • One workspace, many personas. Role based landing pages give each team the right view from a single set of components. A custom workspace per line of business means everyone rebuilds the same pieces, and they drift apart over time.
  • Bring context to the agent. Surface knowledge, recommended actions, and response templates in the flow of work so new hires ramp faster and tenured and new staff stay consistent, instead of leaning on stale docs and DMs.
  • Treat internal requestors as real users. A banker submitting a request on a client's behalf through an SMF-based portal should not have to restate what the platform already knows.
  1. Platform Foundation

The data and modeling underneath everything else. This is worth getting right before you scale:

  • Model who you serve and who serves them. Use the customer data foundation for customers and the Service Model Foundation for stakeholders and locations. Model the products, accounts, and related parties agents need so they are not working blind.
  • Pick the right primitive for work. Extend FSO Base with a new case type when fields, users, or visibility differ; use a Service Definition inside an existing case type when only the process differs. Reaching for a new custom table each time leads to sprawl that fragments reporting. Run the Case Type Questionnaire per request type: when answers cluster on the same category, users, and visibility, those requests usually collapse into one case type with category as a field.
  • Decide what FSO persists versus reads. Store Local suits slow-changing master data like customers and accounts. Hybrid fits records that need audit history, such as the transaction under dispute. Fully Remote is for display-only, high-velocity data like balances. Replicating everything "in case we need it" just leaves you with stale data, refresh lag, and integration debt.

 

One thing to keep in mind: these four areas lean on each other. Good intake, case management, and user experience all rest on the data model, so it pays to get that foundation right before scaling out use cases.

 

A Quick Gut Check

If you recognize any of these on your build, it is worth a second look:

  • Custom work sitting on top of something FSO already ships.
  • A growing pile of one off case types instead of a few well modeled ones.
  • Intake living in variables that nobody can report on.
  • External data copied in wholesale, then slowly going stale.
  • A CSM migration scoped as a rebuild when much of it already fits.

 

What's Next

Explore these related resources to go deeper on the essentials above:

Have a setup essential of your own that has served your implementations well? Share it in the comments, we would love to hear how your team approaches building FSO for scale.

 

Version history
Last update:
2 weeks ago
Updated by:
Contributors