Key takeaways
- Every engagement runs in three phases, build, operate and transfer, and the transfer is planned from the first week.
- We run the system with your team before we hand it over, so what changes hands is a working system with known numbers, not a handoff document.
- What moves to you is concrete. The tables, plays, accounts, rules, reports, documentation and change log, plus training for the person who takes it on.
- A system is ready to hand over when its numbers hold, not on a date. You can also keep us on to run it; there is no lock-in either way.
We hand a system over in three steps. We build it on your stack, we run it with your team until the numbers hold, and then we move every table, rule, document and number to a person you name, and train them. The handover is planned from the first week, not negotiated at the end.
This is how every engagement works for us, whether it is outbound, paid media, LinkedIn content or the CRM underneath. The details below are what that means in practice.
Why do we plan the handover from the first week?
Because a system nobody owns is the most common way growth work fails, and it fails slowly.
It usually goes like this. A contractor builds something clever. The Clay table, the routing rules or the ad audiences live in their head. Three tools end up doing overlapping jobs. Then the person who understood it leaves, and the next person starts again from scratch, losing months and the data from the last attempt.
So we build everything to be handed over. That changes small decisions every day: fields get written definitions, rules get written down before they run, and changes go in a log with the reason attached. A system built this way can be read by someone who was not there when it was made.
What happens in each phase?
Every engagement follows the same arc. The time it asks of your team is stated up front, because "how much work is this for me?" deserves a real answer.
Build
We design and ship the system on your stack and your data. Not a template, and not a deck about a system. For outbound, that is the intake, the model of who to go after, the signals, the lists and the first plays, live at the end of week four.
What you do: for outbound, one intake form and two one-hour calls. Other services ask for similar amounts, such as access to your ad accounts and CRM, or one sixty-minute voice interview.
Operate
For a time, we run what we built alongside your team. We handle the replies, read the numbers with you, and change what is not working on a fixed schedule.
What you do: a thirty-minute review every two weeks for outbound and RevOps, a monthly review for paid media, and the final say on every send.
Transfer
The system, the documentation and the playbooks move to your team, with training.
What you do: name who takes it over. We train them.
What exactly changes hands?
Everything we built, in a form your team can run. What that includes depends on the service:
- GTM engineering: the Clay tables, the plays, the documentation and the numbers.
- Paid media: the ad accounts, which are in your name from the start, plus the audiences, the tracking and the testing log.
- LinkedIn content: the voice guide, the topic bank and the tables that match engagers to accounts.
- RevOps: the documented fields, rules and reports, the change log, and training for the person who owns the CRM.
Nothing on that list lives in a tool of ours that you lose access to. We build inside your accounts so there is nothing to migrate when we step back. The reports you already run keep running, because every result was written to your CRM all along.
Why run it with you before handing it over?
Because a handoff document is not a system. A system is the tables, the rules and the habits that keep them working, and the habits only form by running it.
When we operate the system alongside your team, two things happen. The numbers settle, so you know what the system actually produces before anyone depends on it. And the person who will take it over sees the work done for real: the replies that needed judgment, the play that stopped working and why, the rule that had to change.
By the time we transfer it, nothing in it is a surprise. What changes hands is a working system with known numbers.
When is a system ready to hand over?
When it works, not when a date arrives. Each service has its own test:
- For outbound and paid media, when the numbers hold.
- For LinkedIn content, when the habit holds, meaning the interviews, drafts and approvals happen on schedule without us pushing them.
- For RevOps, when your admin can run the CRM without us.
We read those signs with you in the regular reviews, so the transfer is a decision you make with the numbers in front of you rather than a contract date that arrives on its own.
Who should take it over?
Someone on your team who will own it day to day. For outbound and paid media, that is often whoever runs pipeline or demand. For LinkedIn content, it is whoever takes the pen. For RevOps, it is your CRM admin, or the person you are about to hire for that job.
Many clients bring us in before they hire, so the new person starts on a system that already works instead of inheriting a mess. Either way, we train whoever you name, using the same documentation they will keep.
What if you want us to keep running it?
Then we keep running it. The last step of every engagement can go either way: the system moves to your team, or you keep us on to operate and improve it.
What matters is that the choice is yours. Because the system lives in your accounts and is documented as it goes, staying with us is a decision, never a dependency. There is no lock-in either way.
If you want to see the arc applied to a specific service, the GTM engineering page lays out the first 90 days week by week. For what GTM engineering is in the first place, start with What is GTM engineering?
Questions, answered.
Do we own the accounts and tools, or do you?
You do. Ad accounts are in your name from the start, the CRM is yours, and the Clay tables, sequences and documentation transfer to your team. We build inside your stack so there is nothing to untangle at the end.
How much of our team's time does the handover take?
Less than people expect, because the work is spread across the engagement. During the operate phase it is usually a thirty-minute review every two weeks. At transfer, you name who takes the system over, and we train them.
What happens if the person we trained leaves?
The next person starts from the record, not from memory. Every field, rule, play and change is documented, and the change log says what was done and why. That is the reason we write it all down while we work, not after.
Part of
GTM engineering. Outbound with a reason behind every send.