What happens when it gets something wrong.
Any vendor can tell you what their system does when it works. This page is about the other half.
Every vendor will tell you what their system does when it works. The harder question, and the one worth asking on a call, is what it does when it does not. Here is our answer, in the order it matters.
It tells you, in plain language
Every system we build checks itself every hour. On one firm’s live intake automation that is eight separate checks: the billing system, the e-signature service, the AI agent itself, the account’s ability to actually run, email delivery, whether the incoming webhooks are still registered, whether the scheduler is still ticking, and whether anything is stuck waiting to be reprocessed.
Silence means healthy. When a check fails you get an email that names the dependency that broke and the one action that clears it. Not a dashboard you have to remember to open, and not a stack trace.
It refuses rather than guesses
This is the design rule that matters most, and it is the one a general-purpose tool cannot follow, because it does not know what “wrong” means at your firm.
When an instruction is ambiguous, the system stops and flags it for a person. It does not produce its best guess and send it to your client. On one live build, a deposit split that does not clearly total one hundred percent issues no invoice at all. It does not guess what two parties owe each other.
Nothing is lost while it is down
Some services announce events once and never retry. If your automation were unavailable at that moment, the event would simply vanish, and nobody would ever know it had happened.
Anything that cannot be processed is written to disk, alerted on, and replayed once the dependency is back. An outage becomes a delay instead of a hole in your records.
We never test against your live account
Several of the systems firms rely on have no sandbox and no test mode. The answer is not to be careful on your live account. It is to build a complete mirror — a separate agent, a separate vault, a separate billing account — and run everything there first.
There is no undo that a real client will not see. So the rule is absolute: QA never runs against production.
When we get it wrong, you hear it from us first
In August 2026 a live system produced one joint invoice where it should have billed a single named payer. The firm’s administrator caught it within six minutes and corrected it by hand.
The cause was a branch in how payment splits were parsed that had been written for a case it already handled another way, and was wrong on the only case it actually caught. It was found, fixed, covered by sixty-three new tests, and redeployed to production the same day.
The uncomfortable part, which is the part worth telling you: there had been no test of split parsing anywhere in the suite. That is why it shipped, and it is why the first thing we now write for any branch that touches money is the test.
What a green check does not mean
A passing health check means eight dependencies answered when asked. It does not mean an intake will succeed end to end, and we will not tell you otherwise.
For that there is only one honest test: submit a real form against a non-production account and watch it the whole way through. We do that before go-live, and again after any change that touches the chain.
Every build is checked against the same list
Before anything is handed over it runs through a written set of checks that does not change from project to project: structural validation, functional testing, edge cases, and a user-acceptance script your team runs themselves. You get the results, including anything that failed and what was done about it.
Common questions
How will I know if something breaks?
By email, naming what failed and the one action that fixes it. Checks run every hour, and silence means healthy. You do not have to remember to look at anything.
What happens if the system is not sure what to do?
It stops and flags it for a person rather than guessing. Ambiguous input produces a flag, not a document sent to your client. This is a deliberate design rule on every build.
If it goes down, do we lose the inquiries that came in?
No. Anything that cannot be processed at the time is stored, alerted on, and replayed once the dependency is back. An outage becomes a delay rather than a gap in your records.
Do you test on our real client data?
Never. QA runs against a complete mirror with its own separate accounts. There is no undo that a real client will not see, so production is never a test environment.
What happens when you make a mistake?
You hear it from us, with what happened, what caused it, what we changed, and what test now stops it recurring. We have published a real example of exactly that on this page.