Here is a question almost nobody asks on the sales call: Who owns your automations if you stop paying next month? Not the invoice. Not the strategy doc. The actual working parts. The workflow that texts every new lead within 90 seconds. The call handling flow. The reporting job that runs at 3 am. If your provider walked away tomorrow, what would still be running on Monday?
Most founders find out the answer the hard way, usually about a week after a relationship ends. The automation stops, the login does not work, and the person who built it is not replying.
This post covers what ownership actually means in practice, the four things you need to hold, the questions to ask before you sign, and how to fix it if you are already stuck.
Key Takeaways
- Who owns your automations comes down to four things: the accounts, the workflows, the data, and the documentation. Missing any one of them means you do not own it.
- Automation built inside a provider’s own sub-account or workspace usually stops working the day the contract ends, regardless of what you paid to build it.
- Ask for the account owner’s email on every platform before you sign. If it is not your domain, you are renting access, not owning a system.
- Exported workflow files are worthless without the credentials, so ownership of API keys and connected accounts matters as much as the logic itself.
- A build with no documentation is a single point of failure with a different name. Nobody can maintain what nobody can read.
- Ongoing support is a fair thing to pay for. Being locked out of your own operations is not, and the two are easy to tell apart in a contract.
- If you are already locked in, start by auditing every platform login and every place your business data currently sits.
What Ownership Actually Means
When a founder tells me they own their automations, I ask one question back: whose email address is on the account. Nine times out of ten, there is a pause.
Ownership is not a feeling, and it is not a line in a proposal. It comes down to four concrete things, and you either hold them or you do not.
The accounts
Every automation runs on platforms. A CRM, an automation tool, a voice provider, an email sender. Each one has an owner seat, and that seat is attached to an email address. If that email is [email protected], they own the account, and you are a user inside it. When the relationship ends, they close the seat or stop paying the bill, and everything inside it goes dark.
The workflows
The actual logic. The if-this-then-that. In some tools, this exports as a JSON file you can import elsewhere. In others, it is locked to the platform. Worth knowing which situation you are in before you need to move.
The data
Your contact list, your conversation history, your call recordings, your notes. This is the piece that is genuinely irreplaceable. Tools can be rebuilt in a fortnight. Four years of customer history cannot.
The documentation
What each automation does, why it was built that way, what breaks it, and how to change it. Without this, a new provider has to reverse-engineer the whole thing before they can touch it safely. That is billable hours you should not have to pay twice.
Hold all four, and you own the system. Hold three, and you have a problem you have not discovered yet.
The Three Ways Founders Get Locked Out
I have seen the same three patterns repeatedly, and none of them involves anyone acting maliciously. They happen because nobody asked the question at the start.
The sub-account trap. Most agencies build client systems inside their own platform account, as a sub-account or workspace. It is genuinely more efficient for them, and for the duration of the relationship it works fine. The problem is that the parent account holds the billing and the permissions. When the contract ends, the sub-account is theirs to switch off. Some providers will migrate it out for you. Some will charge for that. Some cannot, because the platform does not support it.
The credential black hole. The workflows are exported and handed over in a neat folder. Except the API keys inside them were generated on the builder’s accounts. The Twilio number is registered to them. The email sending domain is verified under their tenant. You have the recipe and none of the ingredients.
The undocumented build. Everything technically transfers. Accounts, exports, data. But nothing is written down. There are 40 workflows with names like “New Flow 3” and no explanation of which ones are live. Your new provider spends the first month working out what they inherited, and you pay for that month.
The pattern under all three is the same one that traps founders everywhere else in their business: critical knowledge sitting in one place that is not yours. It is the same problem as key-person dependency, except the key person is a company you no longer work with.
The Questions to Ask Before You Sign
None of these is hostile. Any provider worth working with will answer them straight away, in writing, and most will be quietly pleased you asked. A founder who cares about ownership is a founder who plans to keep the system running.
“Whose email is the owner account on every platform?” Get the list. CRM, automation platform, voice provider, email sender, phone numbers, cloud storage. If the answer is anything other than your own domain, ask what it takes to make it yours.
“If we part ways, what do I keep and what stops working?” Ask them to be specific per system. A good answer sounds like: “You keep the CRM and all contacts because it is your account, the workflows export as files, the voice agent config is yours, but you would need your own provider account to run it.” A bad answer is “everything transfers, no problem,” with no detail behind it.
“Who pays each platform subscription, and can I take that over?” If they bill you a bundled monthly figure that includes platform costs, find out what happens to those subscriptions when you leave. Some can be transferred with an email. Some cannot.
“How is this documented, and where does the documentation live?” The answer should name a location you can access today, not “we can put something together at the end.”
“Can I export my data at any time without asking?” Not “will you send it to me.” Can you go and get it yourself. Those are very different arrangements.
“Is there an exit clause covering handover?” A defined handover window, what is included, and any fee. Written down before there is a disagreement, not after.
Ask these six on the first call. It takes ten minutes and it tells you more about a provider than any case study will. If you want a fuller version of this covering scope and deliverables too, the AI automation contract checklist goes deeper.
What Fair Looks Like on the Other Side
To be clear: there is nothing wrong with paying a provider ongoing. I do exactly that with my clients, and it is the right structure for most businesses. Systems need training, adjusting, and extending as the business changes. A build that never gets touched again slowly stops matching reality.
The distinction is between paying for work and paying for access.
Paying for work means the system is yours, running in your accounts, and you pay someone to keep improving it. If you stopped tomorrow, everything would keep running exactly as it is. You would just stop getting improvements. That is a normal commercial relationship, and you can walk away from it cleanly whenever you like.
Paying for access means the system stops when the payments stop. Not because anyone flipped a switch out of spite, but because it never lived in your business in the first place. That is not a service agreement; it is a rental, and it should be priced and understood as one.
Here is how you tell which one you are in. Imagine cancelling at the end of this month, on good terms, with no drama at all. What is still running on the first of next month? If the honest answer is “not much,” you are renting.
The reason this matters beyond the contract is that automation is not a one-off purchase. The whole point is that it compounds. First you automate lead response, then follow-up, then reporting, then quoting. Each one builds on the context and connections the last one established. Two years in, that accumulated system is a genuine asset. It makes your next hire faster to onboard; it makes the business less dependent on your memory; and if you ever sell, it is part of what a buyer is buying.
An asset you cannot take with you is not an asset. It is a subscription with extra steps.
If You Are Already Locked In
Most people reading this already have automations running that somebody else built. Do not panic and do not start a fight. Work through it in order.
Audit what exists. List every platform your business touches, and for each one write down who the account owner is, who pays the bill, and whether you can log in independently right now. Not through a shared login someone set up for you. Your own credentials, with admin rights. This exercise usually takes an afternoon, and it is uncomfortable in a useful way.
Get your data out first. Before any conversation about ownership, export what is exportable. Contacts, conversation history, call logs, notes. Do it now, keep it somewhere you control, and repeat it monthly. Whatever else happens, you are not losing your customer history.
Then have the conversation. Most providers are not villains. They set things up the fast way because nobody asked for anything different. Go to them with a specific ask: “I want the accounts in my name and the documentation in a folder I own. What does that take?” Plenty will just do it. Some will want to charge for the migration work, which is fair enough if it is genuinely work. If someone refuses outright or gets defensive, you have learned something important early, while the system is still small.
Fix ownership before you build more. The worst version of this is discovering the problem after four years of accumulated automations. If you are two months in, sort it now. The migration cost only goes up from here.
Write down what you learn as you go. Even a rough document beats nothing. What each automation does, what triggers it, what it connects to. Keep it somewhere your team can read. This is the same discipline that gets a business out of the founder’s head generally, and it is worth doing whether or not you ever change providers. If you want a broader look at when to check in on an automation build, the 90-day checkpoint covers what to review and when.
The Bigger Pattern
Ownership questions about who owns your automations are really questions about dependency. Founder-led businesses tend to accumulate dependencies quietly: on one person’s memory, on one staff member who knows the client history, on one provider who holds the logins. Each one feels fine on its own. Together they are the reason a business cannot run without someone specific being available.
The fix is the same in every case. Get the important things out of individual heads and individual accounts, and into a system the business itself holds. That is what I mean when I talk about giving a business an AI brain and an AI workforce. The brain is the accumulated context, decisions, and knowledge, held somewhere the business owns. The workforce is the automations doing the work on top of it. Both need to sit in your accounts, under your control, or you have just moved the dependency rather than removing it.
The research backs the general point. MIT’s 2025 study on enterprise AI found around 95% of AI initiatives deliver no measurable return, and the ones that work start with process rather than tools. A system nobody in the business understands or controls is not a process. It is a black box someone else runs.
Automation is meant to make you less dependent, not differently dependent. Check whose name is on the account.
Where to Start
If you are unsure what you actually own right now, the fastest way to find out is to try logging in to every platform your business runs on, using your own credentials, without asking anyone for help. Whatever you cannot get into is the answer.
If you would rather talk it through, I run a 30-minute Discovery Call where we go over what you have got running, who holds what, and what it would take to bring it under your control. No pitch, no deck. Book one here: 30-minute Discovery Call.
Frequently Asked Questions
Who owns automations built by an agency?
It depends entirely on where they were built and whose accounts they run on, not on who paid for them. Paying for a build does not automatically give you ownership if it sits inside the provider’s platform account. Ownership comes down to whose email holds the owner seat on each platform, who controls the API credentials, and whether you can export the data and workflows independently.
What happens to my automations if I cancel my contract?
If the systems run in your own accounts, they keep running exactly as they are, and you simply stop receiving improvements and support. If they run inside the provider’s account or workspace, they typically stop working when the account is closed or the billing ends. Ask this specific question before signing, and get the answer per platform in writing.
Should I own the CRM account or should my provider?
You should own it. Your CRM holds your contact list and conversation history, which is the least replaceable asset in the whole setup. Have the account created under your own domain email, then invite your provider in as an admin user. They get everything they need to work, and you keep control of the account and the data if the relationship changes.
Can I take my workflows to a new provider?
Sometimes. Many automation platforms let you export workflow logic as a file that imports elsewhere, but the exported file usually references API keys and connected accounts that may not be yours. Even with a clean export, a new provider needs credentials and documentation to make it work. Ask about exportability and credential ownership together, because one without the other is not much use.
What should be in an AI automation contract about ownership?
At minimum: who holds the owner account on each platform, who owns the data and how you export it, whether workflows and configurations transfer on exit, where documentation lives and whether you can access it today, and a defined handover process with any associated fee. Get these written down before work starts, while everyone is still friendly and motivated to be reasonable.
Is it normal to pay monthly for automation support?
Yes, and it is usually the right structure. Systems need adjusting as the business changes, new tools appear, and processes shift. The test is what happens if you stop paying. If everything keeps running and you just stop getting improvements, that is a fair support arrangement. If everything switches off, you were renting access rather than paying for work.
How do I check who owns my accounts right now?
Log in to each platform and look at the billing or account settings page. It shows the account owner’s email and who the subscription is billed to. If you cannot get to that page, or you are logging in through credentials someone else created for you, that is your answer. Do this for every tool your automations touch, including phone numbers and email sending domains.
About Octavius
Titus Mulquiney is the founder of Octavius AI, where he builds AI brains and AI workforces for founder-led businesses stuck running everything out of their own head. Twenty years in marketing, ex-Sony product manager, ex-GM Zeal NZ. Based in Auckland, working with operators across NZ, Australia, and the US. Connect on LinkedIn.