How To People-Proof Your Workflows

You've written an SOP. You've emailed it to the team. You've pinned it to the top of your shared drive and may have even held a training session. And yet — somehow — every person on your staff seems to have their own interpretation of how client onboarding should actually get done. One person sends the welcome email on day one; another waits until the transfer paperwork is sent for signature. A digital workflow is initiated for some clients, but DocuSign packets are sent for others, depending on who's handling it that week. The CRM notes don't capture the same information each time a client is onboarded, and the downstream consequences of that hit weeks later.

Sound familiar?

The problem may not be your team – and it probably isn't a training issue, either. Most SOPs fail because they were written to document what should happen in theory, not created as an executable workflow that will be completed by real people. The SOP became an aspirational record of good intentions rather than a system that guides real-world behavior. Kind of like the way I buy fruit and vegetables each week – only to find myself standing in the pantry eating Cheez-Its straight out of the box. It's not that I don't know what I should do – it's just that I get busy and wolfing down a handful of crackers is easier than peeling an orange.

So today I'm going to deep-dive into how to build effective SOPs that consider the behavior of the user. Workflows that make it easy for a real human being to do the right thing in a consistent manner every single time. In other words, how to build workflows that actually work – both in theory and in the real world.

How to Approach the Build: The Rider, The Elephant, and the Path

In their book Switch: How to Change Things When Change is Hard, Chip and Dan Heath describe human behavior through a vivid three-part metaphor: a rider sitting on an elephant, traveling down a path. The rider represents our rational, deliberate mind: the part that reads instruction manuals, follows onboarding checklists, and tries to do things the "right" way. The elephant represents our emotional, instinctive side: powerful, habit-driven, and prone to shortcuts when the terrain gets difficult. And the path is the environment around them: the systems, structures, and conditions that either make the right behavior easy or the wrong behavior inevitable.

Most SOP failures happen because firm owners spend all of their energy training the rider — writing detailed procedures, hosting team meetings, and tracking employee KPIs. They make the assumption that the rider is capable of handling the elephant in any situation, and they ignore the path entirely. But here's what behavioral science tells us: the rider is easily exhausted, the elephant wants to take the easy way when possible, and the only control you have as the owner – is how the path is designed.

The single most important question to ask about any SOP is not "Did I document this correctly?" It is: "Have I built a path that makes the right behavior easier than the wrong one?" Your SOP should be so well-designed that whether your employee is having a great day, a horrible day, or their very first day, they can't help but follow it correctly. Here's how to build workflows that keep the riders on the path.

Step 1: Break It Down into Manageable and Reusable Parts

Start by breaking down your behemoth firm-level documentation bible into smaller, reusable components. This comes from Herbert Simon's work on the architecture of complexity. This framework posits that a hierarchical system enables the creation of large, complex systems by using modular subassemblies that can be triggered independently. Imagine a camera with a separate lens. You want to adjust your focus you simply swap out your wide lens for a zoom, but the body of the camera doesn't need to be replaced.

For example, instead of building a large onboarding workflow that covers every single task from the first prospect touch to the one-year anniversary gift, separate the steps into individual workflows. Consider this: Can the account opening steps of the workflow exist as a standalone subassembly so that it can be triggered as part of an onboarding workflow and as part of an existing client's wish to simply add another account?

This modular design will save you from having to update many different workflows when you switch custodians, or a regulation changes. Instead, you only need to modify a single subassembly of the larger system. By designing modular workflows, you get reusability and scalability.

Step 2: Establish Parameters for Every Task

Every task should answer three questions without ambiguity:

• Who does it? (A specific role, not "the team")
• When does it need to be done? (A specific timeframe, not "as soon as possible")
• What triggers it? (A prior completed task, a calendar event, a client action)

There have been some interesting studies done on the organizational diffusion of responsibility – also known as the bystander effect. When more people are present, people are less likely to respond to an emergency. In fact, when alone, roughly 85% of test subjects were likely to assist in an emergency, but if there are five people present? A paltry 31% jump in to lend a hand. This demonstrates that inaction is often not apathy or bad character – it's actually a predictable social phenomenon driven by group size.

The bystander effect isn't limited to emergency response though, it also affects how employees view shared tasks. Which is why this step is so critically important to understand – no matter how big, collaborative, or helpful your team members are, a single individual must be accountable for every single task.

And while you're assigning roles, there are two other items that should always be defined – a trigger and a relative due date. These define the sequence of events and the timeframe for completion. By ensuring these fields have defaults for every task within a workflow, you not only clarify expectations, you also create a benchmark by which you can measure success.

---

Step 3: Build In Sequential Steps

A great SOP is not a list of suggestions - it is a sequence of carefully placed steppingstones. One where each footfall leads naturally and inevitably to the next and skipping or reordering becomes harder than just doing it right.

In practice, this means building your workflows so that a later task cannot be initiated until the earlier one is marked complete. If your CRM supports dependent tasks — where Task 2 doesn't appear in the queue until Task 1 is checked off — use that feature. If it does not, consider breaking the workflow out into separate modules that are triggered sequentially through automation.

An important design principle to remember is this: If your SOP can be completed out of order without immediate consequence, it isn't structured tightly enough. Each step should act as a checkpoint confirming that the previous step happened before the next one begins.

Step 4: Embed the Answer Before They Have to Ask

Even well-trained employees hit moments of uncertainty. The onboarding workflow references a form they've never seen. A step involves a system they only use once a quarter. A new team member doesn't know the firm's naming conventions yet.

When those moments happen, the path is obscured — and the elephant will look for an alternate route: skip it, swag it, or interrupt someone else to ask. The fix to ambiguity is simple and structural: embed the answer directly in the SOP so the rider doesn't have to go looking for it.

Every task that requires specialized knowledge should include:

• A direct link to the relevant training video, reference document, or recorded walkthrough — not a link to a folder, but a link to the exact answer.
• A brief "why this matters" note for steps where the reason isn't obvious, so that team members understand the intent, not just the instruction.
• Examples or guidance where the step may involve a judgment call (e.g., "If the account is over $1M, complete the high-net-worth addendum").

The fewer clicks between confusion and clarity, the more likely your team stays on the path. Think of each embedded link as one less fork in the road.

Step 5: Automate and Template Where It Makes Sense

The best version of an SOP is not one that relies entirely on human memory and discipline. Wherever possible, build automations and templates directly into the workflow so that the "right way" is also the easiest way. This doesn't mean you should automate everything indiscriminately. Use automation where it saves time and prevents errors, but never at the cost of client relationships. No client wants to feel like they're being served by a robot.

Practical examples for advisory firms include:

• Email templates that auto-populate with client data from the CRM, so the right language and correct details get used every time — eliminating both the friction of drafting from scratch and the error risk of manual entry
• Triggers that automatically launch the next workflow when the previous one is marked complete, including auto-assignment to the correct team member and a pre-populated due date
• Document generation tools that pull client information directly from your records, eliminating transcription errors
• Recurring workflow templates for predictable, repeating processes that automatically launch on a predetermined date or regular cadence (think annual reviews, RMD reminders, rebalancing tasks)
• Automated confirmation emails to clients when key milestones are completed, reducing inbound "just checking in" calls and reinforcing the client's sense of a well-managed process

Automations reduce cognitive load, minimize the chance of human error, and make the client experience more consistent - regardless of which team member is handling a given task that day. They also free your team up to focus on the work that actually requires a human touch.

Step 6: Treat Your SOPs as Living Systems, Not Stone Tablets

One of the most common mistakes in SOP design is treating the procedure as finished once it's written. In reality, an SOP is only as good as its last revision. Processes change. Systems are updated. Regulations shift. New team members bring new questions that reveal old gaps.

Review your workflows when something goes wrong. Don't assign blame to the rider or elephant until you've checked that the path was clear. When a process breaks down, treat it as an investigation: Where did things break down? Was the step incorrect, ambiguous, unassigned, or structurally impossible to complete given what preceded it? Was the training link outdated? Was a trigger missing?

Harvard professor Amy Edmondson, in The Right Kind of Wrong: The Science of Failing Well, distinguishes between what she calls 'basic failures' – preventable errors in familiar territory caused by gaps in process or oversight; and 'intelligent failures' – which expose new knowledge in novel situations. An SOP breakdown is almost always a basic failure. That means it wasn't inevitable – it was a signal. And the only wasteful response is to skip the investigation and simply remind people to "try harder next time" or "be more aware". Instead, take that feedback for the gold it is and use it to update your SOP so that same mistake won't be repeated.

Step 7: Build an Intentional Feedback Loop

A big part of systems theory is ensuring you have a feedback loop to help guide decisions. In workflows, this feedback loop may help you gauge capacity. You have due dates and assignees, but dates are consistently being missed? That's feedback you can use to investigate and find out why. Is the timeframe too aggressive? Does the individual have too much work? Do adjustments need to be made? Does the path need to be restructured?

And feedback doesn't come just from the system metrics. Your best source of feedback will often be the users of a workflow. A team that has psychological safety and feels ownership over the SOPs they use is far more likely to follow them and, just as important, to flag when something isn't working. Consider involving your team in periodic SOP reviews. They are the ones closest to the path, and they will notice potholes before you do.

The firms that improve their operations are the ones where a team member can say "this step doesn't make sense" or "this link is broken" without bracing for a reaction. If your SOP review depends on your team volunteering that information, the culture around the procedure matters just as much as the procedure itself.

The Bottom Line

A well-designed SOP is one of the highest-leverage investments you can make in a small advisory firm. It protects the client experience, reduces your dependence on any single person's memory or institutional knowledge, and creates the operational foundation your firm needs to grow sustainably.

But it only produces those results if people actually follow it. And that requires more than good documentation; it requires a well-designed path built on a solid foundation of proven organizational and behavioral research. One that is sequenced, assigned, and time-bound; structurally enforced; and embedded with the resources your team needs—while leveraging automation where it adds value.