Implementation and Setup Essentials

[mmcdonnell]

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.

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, not through embedded catalogs that lose context on submission.
• Guide complex intake. For onboarding or claims, a conditional, multi step form shows a user only the fields their situation calls for. One dispute form with thirty plus fields drives abandonment; a guided version cuts it, and cleans up what an agent has to fix later.
• 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.

2. 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. Reserve cases for work that needs a workflow.
• Guide agents with playbooks. Task plan templates make a process repeatable and 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.

3. 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 people are not searching and copying.
• Treat internal requestors as real users. A banker submitting for a client should not have to restate what the platform already knows.

4. 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 base case types for different data; use service definitions for different process. Reaching for a new custom table each time leads to sprawl that fragments reporting. Grouping requests by category, users, process, and visibility usually shows many belong to one case type.
• Decide what to store versus read. Keep slow changing master records local; read fast moving data like balances remotely. Copying everything in just creates stale data and integration debt.
• Evolve from CSM, do not re platform. Much of an existing model is already FSO compatible. Keep what fits and adopt FSO core where it changes the game.

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:

• FSO's Layered Cake Architecture
• Streamlining Case Intake in FSO Workspace with Record Producer
• Getting Started with Banking Service Management
• Prepare Your Banking Data Model

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.