What You Own When the Agency Leaves

There is a specific moment, usually around month eleven, when a founder sits down to review an agency renewal and works out that they cannot actually say no.

Not because the work was bad. Usually the work was fine. It is because the workflows were built under the agency's seat, the data sync runs on an API key nobody internal has ever seen, and the one person who knew why the lead scoring model weights a demo request at 40 points left that agency in March.

That is not a pricing problem. It is an ownership problem, and it was settled in month one, not month eleven.

The only question that matters

If you fired your agency on a Friday, could your team run the system on Monday?

Not build. Run. Route the leads, close the quarter, produce the pipeline report, and fix a workflow when it breaks at 9pm on the last day of the month.

Most agencies would fail that test. Most clients never ask it, because it feels rude to plan your exit during a kickoff call, and because the honest version of the answer is uncomfortable for the person you are asking.

Worth saying plainly before going further: an agency that passes this test has made itself easier to fire. That is a real cost and we will come back to it.

Four things that should be yours from week one

1. Admin access in your name

Your CRM, your instance, your super admin seat, your billing relationship with the vendor. The agency should be a user on your system, not the other way around.

The same goes for the plumbing, and this is the part people miss. API keys and service accounts should be created in your account and shared with the agency. Reverse that and every integration they built for you has a switch in someone else's hand. It does not even take a falling out. An agency reorganising its own tooling can break your lead routing on a Tuesday for reasons nobody thinks to tell you about.

You can check this in about four minutes. Open the user list in your CRM, filter to accounts with admin rights, and read the email domains. Then do the same for whatever runs your integrations.

2. A decision log, not just documentation

Documentation tells you what a field does. A decision log tells you why it exists, what it replaced, and what breaks if you remove it.

The second one is what you need fourteen months later, when a new ops hire finds a field that looks unused and has to decide whether to delete it. Without the reasoning, they do one of two things. They leave it alone, and the clutter compounds until nobody trusts the object at all. Or they delete it, and something quietly stops working in a way nobody connects back to that Tuesday for another quarter.

It does not need to be elaborate. Date, what was decided, why, and what was considered and rejected. Four columns. The value is entirely in it being written at the time, by the person holding the context, rather than reconstructed later by someone guessing.

3. Documentation written for your business, not your schema

A field dictionary that reads deal_stage_2__c = picklist, 7 values is not documentation. It is an export. Your CRM could generate it without anyone thinking.

What you actually need is the layer above that: which fields the forecast depends on, which automations fire off which values, who is allowed to change them, and what the intended behaviour is when something is blank.

There is a simple test. Hand it to someone who joined last month and ask them to work out why a particular lead did not get routed. If they can, it is documentation. If they need to ask the agency, it is an export with a nicer cover page.

4. The backlog, including what was deliberately not done

The list of what got built is the least interesting artefact of an engagement. You already know what got built, you watched it happen and you paid for it.

The valuable list is what was found, ranked, and consciously skipped, with the reason. Without it, the next person to hold the system re-opens decisions that were already made carefully, with far more context than they have, and burns a quarter arriving at the same answer.

The tells, and you can spot them before you sign

Almost all of this is knowable during the sales process, if you ask.

Custom code with no stated home. Ask where it will live. If the answer is the agency's private repository, you are renting. The fix is trivial when raised in week one and awkward in month eleven.

Middleware on their subscription. Whatever runs your integrations, someone pays for it. If that account is theirs, your integrations have an off switch you do not control.

"We will handle documentation at the end." Documentation written at the end is written from memory, under deadline, by whoever is already half-staffed onto the next client. It becomes a deliverable rather than a record. Real documentation is a by-product of the work, produced while the reasoning is still in someone's head.

No named owner on your side. This one is on you rather than them. If nobody internal is accountable for the system, you have not filled a gap, you have outsourced a function, and there is no one for the agency to hand back to even if they want to.

Three questions worth asking on the call

Ask these before you sign, when they cost nothing.

1. Can you show me a decision log from an engagement you finished a year ago? Redacted is fine.
2. Whose name sits on the super admin seat during the engagement, and whose is on the API keys?
3. On your last engagement, what did you rank and then deliberately not do, and why?

The third one separates people. Anyone can recite what they built. Far fewer can tell you what they found, judged not worth the money, and talked a client out of.

What this costs the agency, honestly

Everything above makes an agency easier to leave. That is not a side effect, it is the point, and it is worth being straight about the trade rather than pretending it does not exist.

An agency that holds the keys does have better retention numbers. That is true. It is also a bad reason to structure a relationship, because a client who cannot leave has stopped being a client and started being a hostage, and hostages do not refer anyone. The retention you get from lock-in is the kind that shows up in a renewal rate and nowhere else.

Ask the exit question in month one, while it is still a cheap question. By month eleven it is a negotiation, and you will be conducting it from the weaker side.

Frequently asked questions

Does owning all of this mean I need someone in-house to maintain it?

Eventually, but not immediately, and not at the level you would need if the system were undocumented. That is rather the point. A documented system with a decision log can be maintained by a capable generalist or a RevOps manager. An undocumented one needs someone senior enough to reverse-engineer it, which is a more expensive hire and a harder search.

Is it reasonable to ask a RevOps agency for admin access on day one?

Yes, and the reaction tells you a lot. It is your system. An agency that needs to own the top-level seat to do its job is describing a process problem, not a security requirement. Agencies should hold admin rights as users on your instance, which is normal and necessary, rather than holding the instance itself.

What if I have already signed and things are sitting on the agency's side?

It is recoverable and it is mostly administrative. Migrate the subscriptions into your own accounts, rotate every shared credential, get the code moved into a repository you control, and ask for the decision log to be written retrospectively while the people who did the work are still reachable. Do it at a calm moment rather than during a renewal negotiation, because the leverage is completely different.

Related reading: fractional RevOps vs a full-time hire, how much RevOps consulting costs, and when to hire a RevOps consultant.