How we work
Systems you can inherit from us.
Most automation work is undocumented, lives in one person's head, and runs on a platform the agency controls. That is fine until the day it is not. Here is how we build instead, and what you hold at the end of it.
The system is written down, including the bugs we have not fixed
Most automation work exists only in the builder's head, which makes the builder a hostage and the client a bigger one. Every system we run is documented in a versioned technical document covering the workflows, the tables, and the known defects. The document for one of our larger builds is at version 1.10, with 45 appendix sections and 23 tables, and each version records what changed against the one before it. Defects are written down with the fix described, including the ones still open. That last part is unusual and deliberate: a list of problems you know about is worth more than a document that implies there are none.
We audit before we change, not after
Before a structural change ships, we review every live workflow and classify each one: needs a change, already correct, or unaffected. On a recent identity-model rollout that meant twelve workflows needed changes, twenty two were unaffected, and three that looked broken turned out to be correct on inspection and were deliberately left alone. Those three are the point. Without the review they would have been fixed into breakage by someone confident and wrong. The same pass caught a node that looked like existing coverage and was in fact disabled and disconnected from the flow.
You own the accounts
We build on standard tools in your own accounts: a voice agent service, a workflow engine, a relational CRM, a scheduling service, carrier APIs, and a team chat app. There is no GenInfos platform in the middle, so there is no version of this where leaving us means losing your operations. If you want the workflow files, they are yours, because they already are.
Changes arrive as files you can review
Patched workflows are delivered as a change summary, the complete patched file, and a diff-style listing of exactly which nodes moved. You import them after review rather than discovering on Monday that something shifted on Friday. During a change pass we do not touch credentials, webhook IDs, node IDs, or logic unrelated to the change, because the fastest way to break a working system is to tidy it while fixing something else.
The people who run it get guides written for them
Documentation written for engineers does not get read by the office manager who actually runs the thing. So the operator guides are separate, written in the language the operators speak, and they describe observable signals rather than architecture. One guide explains that a cleared rep assignment is how you know a cancellation reached the calendar. That is the kind of sentence that decides whether a system gets used or worked around.
We copy patterns, not one-offs
Forty five workflows built forty five different ways is not a system, it is a pile. Correct implementations get designated as reference patterns and copied, so identity resolution behaves the same way everywhere. One of ours is explicitly marked as containing a defect not to copy, so the pattern gets inherited without the bug travelling with it.
Why this matters more than the stack
Tools are easy to compare and mostly interchangeable. What separates an automation build that is still running in three years from one that quietly decays is whether anyone can tell what it does, whether a change can be made without a gamble, and whether the person who built it is required for it to keep working.
We write about the failure modes behind these practices in the articles, including the three wrong assumptions that sink automation projects and why automations break silently rather than loudly. The practices on this page exist because we hit those first.
Frequently Asked Questions
Inherited a system nobody can explain?
That is a common starting point, and the first deliverable is usually an audit that tells you what you actually have. Tell us what is running and who built it.
Request a Workflow Review