Automate the Work Only After the Exception Path Is Clear

The demo is usually the easiest case

A new lead enters the CRM. The system creates a task, assigns an advisor, drafts the first email, and schedules a reminder. Nice. Then the contact already exists under another company, the account owner left last week, the referral partner promised a response the same day, and the draft mentions the wrong client relationship.

That is when the automation becomes an operating problem.

Small advisory firms are right to automate repetitive work. There is too much follow-up, research, data entry, routing, reporting, and task creation to handle everything by hand. But speed is useful only when the process knows when to stop.

Do not judge a workflow by its cleanest run. Judge it by what happens when the input is incomplete, the record conflicts with another source, the owner is unavailable, or the system cannot prove whether an outside action happened.

Choose a workflow with a stable decision

The best first candidate is not necessarily the task your team hates most. It is a recurring process with a clear trigger, reliable inputs, limited decision paths, an identifiable owner, and an output you can verify.

Good early candidates may include creating an internal renewal-review task from a confirmed contract date, routing a complete intake record to the assigned advisor, preparing a meeting brief from approved account data, or reminding an owner about a dated client commitment.

Be careful with work that depends on relationship judgment, changing commercial terms, unclear authority, or data scattered across several systems. You may still automate part of it. Start with collection, preparation, or notification instead of letting the workflow make the whole decision.

Run the candidate through your SOP loss test. If a capable person cannot explain the trigger, allowed decision, required evidence, and finish state, software will not fix the ambiguity.

Map the stops before you build the route

Take ten recent examples of the work. Include easy cases and the annoying ones people handled through email, Slack, or a private workaround. For each step, ask what must be true before the workflow may continue.

A useful automation map should identify:

• The event that starts the workflow and the evidence that the event is real.
• The source record and required fields.
• The action the system may take without approval.
• The conditions that pause, reroute, or end the run.
• The person who owns each stopped case.
• The evidence that proves the final action succeeded.

Do not use "send to manual review" as the whole exception plan. Which person receives it? What will they see? What can they decide? How long can the item wait? What happens if that person is out? What returns the item to the normal path?

The answers are part of the process design. They are not cleanup details for whoever builds the automation.

Separate business exceptions from temporary failures

A timeout and a missing client approval are different problems. Retrying may help the first one. It will not create the approval.

Microsoft's current guidance for transient faults says retries should be used when a failure is temporary and another attempt has a reasonable chance of succeeding. It also warns against retrying invalid operations, such as writing to a record that does not exist or using permissions the caller does not have.

Give failures a small set of operating treatments:

• Retry: The problem appears temporary, the action is safe to repeat, and attempts have a firm limit.
• Ask for information: A required client, supplier, or internal fact is missing.
• Route for a decision: The facts exist, but an authorized person must approve, correct, reject, or redirect the action.
• Reconcile: The workflow cannot prove whether a message, update, or other outside action already happened.
• Stop: The request violates a rule, lacks authority, no longer fits the process, or cannot continue safely.

That distinction matters. Blindly retrying a CRM update can create duplicate records. Repeating an email step can send the same client message twice. Continuing after a failed owner lookup can assign work to nobody while the run still looks successful.

Give the human a decision, not an alarm

An alert that says "workflow failed" creates another research project. The owner now has to find the run, locate the client, reconstruct the input, guess what already happened, and decide what can be repeated.

The handoff should include the client or prospect, source event, blocked action, last completed step, exception reason, affected records, prior attempts, timing, and the specific decision required. If there may have been an outside write or message, show the evidence needed to confirm it before anybody presses retry.

Then give the reviewer defined choices. Approve. Correct. Request information. Reassign. Reject. Stop. A vague comment box is not a decision path.

Microsoft's current Power Automate error-handling guidance separates alternative paths, retries, termination, logging, and notifications. The product mechanics will vary, but the operating lesson is useful: catching a failure, deciding whether to repeat it, stopping downstream action, and telling an owner are separate controls.

Protect the point where the workflow changes reality

Reading a record and changing a record do not carry the same risk. Drafting an email and sending it are different actions. Preparing a proposal summary and changing the commercial terms are not the same job.

Mark every step that changes a system of record, communicates with a client or partner, commits money, changes ownership, alters a deadline, closes work, or removes access. Those steps deserve stronger validation and a clear answer to one question: can this action be safely reversed or repeated?

If the answer is no, place the approval and final checks before the action. If the result is uncertain afterward, stop and reconcile against the destination system. Do not rerun the whole workflow because one status page says failed.

This is also where your client exception rules matter. Automation may route an unusual pricing, service, or ownership request to the right person. It should not quietly turn that exception into the new standard.

Name two owners

Every production workflow needs a process owner and an exception owner.

The process owner decides what the workflow is allowed to do, reviews performance, approves changes, and makes sure the automation still matches the firm's operating rules. The exception owner handles a stopped item now. Sometimes that is the same person. Often it should not be.

An account owner may resolve missing client context. Operations may repair a failed task assignment. Finance may reconcile an uncertain commission update. The firm owner may approve a commercial exception. One shared inbox called "automation errors" does not create ownership.

Define backup coverage too. An automated process that waits indefinitely for one person has moved the bottleneck. It has not removed it.

Pilot with a scorecard that can tell you to stop

Run the first version on a narrow slice of work. Keep the manual path available. Review every exception and sample successful runs instead of assuming a green status means the business result was correct.

Track the number of eligible cases, successful completions, stopped cases by reason, retries, duplicate-prevention events, human corrections, time to resolution, and downstream errors found later. Also track whether the workflow created work your team would not have done otherwise.

Set exit rules before the pilot. Expand when the inputs stay reliable, exceptions are owned, successful runs produce verified outcomes, and the team can recover without calling the builder. Pause when cases disappear, owners cannot resolve the queue, duplicate or incorrect actions appear, or manual cleanup costs more than the automation saves.

That last outcome is useful. A failed pilot can expose a weak process before you spread it across every client.

Start with one recurring workflow this week

Pick a workflow your firm runs at least a few times each month. Pull ten real examples. Write the normal path, then write the missing-data path, wrong-owner path, failed-dependency path, uncertain-write path, and stop path.

Assign the process owner, exception owners, backup coverage, response times, and recovery evidence. Test one case that should complete, one that should pause, one that should retry, and one that should stop. If all four behave as expected, you have something worth piloting.

Advisor OS CRM connects organizations, contacts, opportunities, activities, tasks, suppliers, owners, and reporting. That shared record gives automation a cleaner operating context and gives your team somewhere to see the work, ownership, and history around an exception.

Use the free Advisor OS agency scorecard if your recurring work still depends on disconnected tools, inboxes, and memory.