What Happens When Things Don't Go Perfectly

Here's what most automation demos won't show you: the exceptions.

The invoice with a missing PO number. The timesheet that comes in late. The approval that gets stuck. The data format that changed overnight.

Traditional automation breaks. You reprogram the bot. You update the script. You call support.

Autonomy learns.

That's the difference. And it's the difference that matters when you're running real operations, not demo environments.

The Exception Reality

Perfect conditions don't exist.

In 800+ implementations, we've never seen a workflow that runs exactly the same way twice. There are always variations. Always exceptions. Always edge cases.

The question isn't "Will exceptions happen?" The question is "How does the system handle them?"

Here are the three types of exceptions every autonomous workflow encounters:

1. Predictable VariationsFormat differences. Timing delays. Standard deviations from the norm.

Example: An invoice arrives without a PO number. Or with multiple POs. Or with a PO that hasn't been entered into the system yet.

2. New ScenariosSomething that hasn't happened before but follows logical patterns.

Example: A new cost code gets created. A vendor changes their invoice format. A project manager joins the team and starts routing approvals differently.

3. True OutliersGenuinely unusual situations that require human judgment.

Example: A disputed charge. A vendor billing error. A project that needs to be split across multiple cost codes for tax reasons.

Traditional automation can't tell the difference between these three. It treats everything as a break in the process.

Autonomy categorizes, learns, and adapts.

How Otto Handles Exceptions

Let's walk through what actually happens when things go wrong.

Scenario 1: The Missing Data Exception

A construction company processes hundreds of change orders every week. Each change order needs to be logged, approved, and entered into both the project management system and the accounting system.

Most change orders follow a standard format. But occasionally, someone forgets to include the cost code.

Traditional automation response:Process fails. Error message. Someone manually fixes it. Bot tries again.

Otto's response:Otto recognizes the missing data, checks if there's a logical default (is there only one active cost code for this project?), applies it if appropriate, or flags for review if judgment is needed.

More importantly, Otto learns the pattern. If the same project manager consistently forgets the cost code and it's always the same default, Otto starts applying it automatically and notifying the PM rather than blocking the process.

You teach Otto once. Otto remembers forever.

Scenario 2: The Format Change Exception

SphereNY, a construction technology consulting firm, needed to transfer data between DocuSign and CMiC automatically. Change orders would be signed in DocuSign and needed to update in CMiC.

The challenge? DocuSign formats change. Client systems vary. Projects have different data requirements.

Briq built automations that don't break when formats change. When a new field appears in DocuSign, Otto recognizes it as new data, determines if it maps to an existing CMiC field, and either applies the mapping or flags for review.

The key phrase: "You have to tell Otto once."

If there's a straightforward workflow and there's one alteration, you tell Otto how to handle it. Otto knows from then on. Any abnormal things that deviate from the standard norm, you teach it once, and it's good to go.

Scenario 3: The System Error Exception

Vantage Builders needed to produce their JCCM (Job Cost Cash Management) report daily. The report pulls data from Sage Intacct and Procore, reconciles it, and produces a current cost status for every job.

What happens when Sage is down for maintenance? Or Procore is running slow? Or a network connection drops mid-process?

Traditional automation:Fails silently. Or worse, produces an incomplete report that looks correct but contains partial data.

Otto's approach:Recognizes the system is unavailable, logs the exception, retries with exponential backoff, and notifies the team if the issue persists beyond normal parameters.

When systems come back online, Otto picks up where it left off. The team doesn't need to manually restart the process or figure out what completed and what didn't.

The Learning Loop

Here's what makes autonomy different from automation: the learning loop.

Every transaction Otto processes feeds back into the system. Not just successful transactions. Especially the exceptions.

How the learning loop works:

1. Pattern RecognitionOtto tracks every variation, every exception, every edge case. Over time, patterns emerge. "This vendor always sends invoices on the 15th but sometimes on the 16th." "This PM routes approvals through the superintendent on large projects but directly to the owner on small ones."

2. Confidence ScoringOtto assigns confidence scores to decisions. High confidence = execute automatically. Medium confidence = execute and notify. Low confidence = flag for review.

As Otto processes more transactions, confidence scores improve. What started as "flag for review" becomes "execute and notify" becomes "execute automatically."

3. Adaptation Without ReprogrammingWhen processes change, you don't reprogram Otto. You show Otto the new way once, and it adapts.

Catamount Constructors didn't stop at one forecast. They added custom curves. Then cash flow tracking. Then executive dashboards. Each addition built on what Otto already knew. No starting from scratch. No reimplementation.

Real Examples of Exception Handling

Elder Construction: The Textura Integration

Elder Construction needed to connect Textura (payment management) with ProContractor (accounting). Invoices would come into Textura, need review and approval, then had to be entered into ProContractor.

The process had dozens of exception scenarios:

• Invoices split across multiple projects
• Partial payments
• Retainage calculations
• Disputed amounts
• Missing documentation

Briq built bots that log into each system, collect data, and handle the exceptions. When something genuinely unusual happens, the bot flags it. When it's a known variation, the bot handles it.

The accounting team went from chasing down information to reviewing exceptions that actually need human judgment.

Bayley Construction: The System Transition

Bayley Construction was transitioning from a legacy accounting system to Acumatica. During the transition, they needed reports from both systems, reconciled and compared.

This is exception handling at scale. Different data structures. Different field names. Different calculation methods. Everything had to map correctly and produce accurate WIP reports throughout the transition.

Briq built the bridge. When discrepancies appeared (and they did), Otto would flag them with context: "These two numbers should match but don't. Here's where each came from."

The finance team could quickly identify whether it was a mapping issue, a timing difference, or a genuine data problem. What used to be hours of detective work became minutes of targeted review.

What You Actually Need to Worry About

After 800+ implementations, here's what actually causes problems:

Not a problem: Technical capabilityOtto can handle the exceptions. The technology works.

Actual problem: Unclear process ownershipIf three different people do the same process three different ways, Otto will learn all three. That's not an Otto problem. That's a process problem.

Not a problem: Legacy systemsOld software, niche platforms, systems without APIs. Otto works with all of them.

Actual problem: Undefined success criteriaIf you can't explain what "correct" looks like, Otto can't learn it. Define your validation rules clearly.

Not a problem: Volume variationsOtto handles 10 invoices or 10,000 invoices the same way. Scale isn't the issue.

Actual problem: Scope creep during implementationPick one workflow. Prove it. Then expand. Don't try to solve everything in the first 14 days.

The Confidence Threshold

Here's how to think about when Otto should execute versus when it should flag for review:

Execute automatically (95%+ confidence):Standard transactions following known patterns. High volume, clear rules, well-defined validation.

Execute and notify (80-95% confidence):Variations from the norm that follow logical patterns. Otto handles it but tells you what it did.

Flag for review (below 80% confidence):True outliers that need human judgment. Otto provides context and recommendations but doesn't execute.

Over time, the distribution shifts. What started as 60% automatic, 30% notify, 10% review becomes 85% automatic, 12% notify, 3% review.

That's the learning loop in action.

What This Means for Your Operations

Real autonomy isn't about eliminating exceptions. It's about handling them intelligently.

The difference between automation and autonomy isn't perfection. It's resilience.

Automation breaks when conditions change. Autonomy adapts.

Automation requires reprogramming. Autonomy learns.

Automation needs perfect data. Autonomy handles messy reality.

If you're evaluating autonomous workforce solutions and the vendor only shows you perfect-condition demos, ask about exceptions. Ask about edge cases. Ask what happens when things don't go according to plan.

Because that's where autonomy proves its value. Not in the perfect scenario. In the messy, complicated, real-world operations you actually run every day.