Customer.io agency onboarding: what to hand over in week one
You have signed a Customer.io agency, or you are about to. The proposal is agreed, the kick-off is in the diary, and everyone expects the first emails soon. Then three weeks pass and nothing has sent.
That gap is rarely the agency's build time. It is an invite nobody sent, a DNS record nobody added, or an event list that lives in one developer's head. Most advice on agency onboarding is about the agency's process: the kick-off deck, the questionnaire, the welcome pack. The things that decide your start date sit on your side of the table.
TL;DR: Customer.io agency onboarding stalls on the client's side, not the agency's. Hand over five things in week one. They are an Account Admin invite for a named agency login, a DNS contact, your event and data documents, one approver and a named warm-up owner. With those in place, setup can finish within two weeks and the first automation can go live inside the first month. Miss them and a monthly retainer bills you to wait. Customer.io's own rules show why each one blocks: only Account Admins can add team members, invite links expire after seven days, and every new sending setup starts cold. In one agency data set, 85.2% of more than 16,000 onboarding tasks were assigned to the client.
Where onboarding stalls
LaunchBay, which sells onboarding software to agencies, analysed the tasks in its own system. Of more than 16,000 onboarding tasks across agency projects, 85.2% were client-assigned and 14.8% were handled by agency teams (LaunchBay, September 2025). It is a vendor's data set, not an independent survey, and its tasks are the ones agencies send to clients through LaunchBay's client portals.
Customer.io makes the split sharper, because so much of setup needs rights the agency does not have yet. Someone has to own the account to invite us, own your DNS to authenticate the domain, and know your data to say which events exist.
At NerveCentral we aim to finish setup within two weeks of signing: access, the sending domain, the data checks and a 90-day plan sent for your sign-off. The target holds only if the five hand-overs below arrive in week one.
The week-one hand-over
| What to hand over | Who on your side | Why it blocks |
|---|---|---|
| An Account Admin invite for a named agency login, with an authenticator app for two-factor authentication | Whoever owns your Customer.io account | Only Account Admins can add team members, and the invite link expires after seven days |
| A DNS contact who can add records this week | IT, a developer, or whoever manages your domain | Email cannot reach your audience until the sending domain is authenticated |
| Your event and attribute documents, or a developer who can explain the data | Product or engineering | Automations trigger on events and attributes, so a trigger needs data that already arrives |
| One approver for copy, the plan and go-live | Founder, head of marketing or CRM lead | Nothing should send without a yes, and two approvers mean extra rounds of edits |
| A named owner for deliverability and warm-up | You, the agency, or split, but written down | Every new Customer.io sending setup starts cold and has to ramp up slowly |
Brand assets and any legal wording that must appear word for word belong on the list too. They rarely block the start, because copy can be drafted around placeholders.
Access: one named login
Every Customer.io team member is either an Account Admin or a Member. Account Admins "have all permissions available across your account and every workspace", including billing, team members, API credentials and integrations (Customer.io docs). Members get partial access, plus a role in each workspace: Workspace Admin, Author or Viewer.
We ask for Account Admin, for three reasons in the docs. API credentials sit with Account Admins unless a Member is granted "Manage API credentials". The account's US or EU region is shown only to Account Admins (Customer.io docs). And only Account Admins can add team members. If Account Admin is a step too far, the workable alternative is a Member with "Manage API credentials" and Workspace Admin on the workspaces the agency builds in. Once setup is done, you can move the agency down to Member on a no-send role.
Region matters more than it looks. It is chosen when the account is created and every workspace sits in it. Customer.io does not support data centre migrations "except in extenuating circumstances", and a wrong-region App API request fails with a 401. Tell the agency your region in week one.
A named login, never a shared one
Do not share a login. Customer.io requires two-factor authentication for everyone who signs in with a Customer.io password rather than SSO. By default that is a magic link by email, which must be clicked "on the same device and browser" that submitted the password (Customer.io docs). A shared login means your marketing manager forwarding sign-in links at night, and an audit log that cannot tell who changed what.
Everyone at the agency gets their own invite. Customer.io does not charge for team members, and an account can have up to 300, so sharing saves nothing.
Since 12 July 2026 there is a second route: guest access. An agency signs in with its own Customer.io login and switches to any account that has added it as a guest (Customer.io release note). Permissions stay per account, and everything a guest does is recorded in that account's audit log. Removing a guest later keeps the resources they created and their audit history (Customer.io docs). The docs present guest access as the replacement for separate logins and a model that suits partners. If your agency already has its own Customer.io account, guest access is the cleaner route. Otherwise, invite a dedicated agency address as Account Admin.
Team-member invitations expire after seven days. Send yours when the agency is ready to accept, and chase it if the Team Members page still shows "Invite sent" the next day.
If you will not hand over sending rights
Some teams want the agency to build but not press send. Since 10 July 2026, custom roles can let team members "build and edit automations and content without letting them send things" (Customer.io release note). Starting, scheduling and stopping automations needs the Execute permission (Customer.io docs). The agency must also be a Member, not an Account Admin, because Account Admins get full access to every workspace whatever role you assign. Keep "Manage API credentials" off too: an API key reaches the whole API regardless of the role. A build-only role also cannot edit an automation once it is live, because the docs say editing live automations needs Execute too.
There are two catches. Custom roles are a Premium and Enterprise feature. And roles created before that release keep their old permissions unless you edit them. Our post on the Customer.io Execute permission shows how to split building from sending. If you keep Execute, you become the go-live step, so name the person who holds it and give them a date for each launch.
DNS: one person who can add records
Domain authentication is often the slowest hand-over, because the person who can change DNS is rarely on the kick-off call. Customer.io needs four records for each sending domain: MX, SPF, DKIM and DMARC (Customer.io docs). The minimum DMARC record is v=DMARC1; p=none.
Three details from the same page save a round of back and forth:
- The records go in an account-specific subdomain such as
cio#####.yourdomain.com. In the docs' own words, "We will not take over your root domain". - Nobody should delete your existing records while adding these, or you stop receiving email.
- DMARC sits on the root domain only, and one record there covers your sending subdomains.
Automatic setup through Entri still needs someone to log in to your DNS provider. Verification "can take up to 72 hours", though the docs say it usually happens much faster.
These records are not a Customer.io quirk. Google requires SPF or DKIM from every sender to personal Gmail accounts. Senders of more than 5,000 messages a day need SPF, DKIM and DMARC, plus one-click unsubscribe on marketing messages (Google). Those rules have applied since 1 February 2024.
Two more gates sit beside DNS. Until a Customer.io account is verified, automations send to your test delivery address, not your audience (Customer.io docs). And since 10 July 2024, test emails can go to a team member before the domain is verified (Customer.io release note). So the agency can build and test while DNS propagates. Our rule is that nothing sends to customers before the domain is verified. If you want marketing and transactional email on separate subdomains, decide before the records go in: our sending subdomains post covers the split.
Warm-up: a named owner
Here is the detail most teams miss. Customer.io sends from a managed subdomain that inbox providers treat as new, even when your root domain has years of sending history (Customer.io docs). So every new setup raises volume in stages over several weeks. Our domain warming post has the schedule and the numbers.
Somebody has to read the signals at every stage and decide whether to advance or hold: spam rate, bounces, deferrals and Postmaster Tools. That person is the warm-up owner. It can be the agency, you, or split, but one named person holds it in writing. The owner also guards two rules from the docs: commit to one sending domain before the first stage, because switching mid-warm-up resets progress, and hold off on a newly registered domain.
Warm-up does not hold back the first automation. The docs say some senders use automations with low volumes during the warming period, and either method works if you follow the plan. A welcome or abandoned checkout flow sends only to people who trigger it, so its daily volume is usually small. Before it goes live, check the flow's expected daily volume against the warm-up stage you are on.
Data: documents before triggers
An automation can only start as early as its data. Customer.io's docs say events let you "start automations" and segment people by what they do (Customer.io docs). If the trigger event never arrives, the automation has nothing to react to.
So the third hand-over is whatever describes your data: a tracking plan, an event list, a spreadsheet of attributes or a sample payload. If none exists, an hour with a developer will do. The agency needs four answers in week one.
- Which events you send today, with their exact names and data.
- Which attributes sit on each profile, and which identifier you use.
- Where the data comes from: website, app, server or warehouse.
- What is missing for the first automations in the plan.
The gap list is the useful output. Our event schema guide covers naming, and attributes vs events covers which to use for what. To try changes away from live data, see our test workspace post.
Data is where our AIRE Health engagement started, as they moved from an internal email system to Customer.io. We wrote a data plan with a standardised naming schema across existing and new events, then built segments and campaigns on it. Campaign conversion rate went from 7.0% to 17.8%, a 154% increase (AIRE Health case study). Every trigger and segment depended on that plan, so it came first.
One approver
The fourth hand-over is a person, not a file. Name one approver for copy, the plan and go-live. Two approvers who disagree add extra rounds of edits.
We send a project questionnaire before the kick-off call, so the call is spent on decisions rather than facts. On the call we agree one priority metric with its baseline and target. Then the client signs off a 90-day plan before any build starts. Our retainer post covers what that plan and the monthly report should contain.
The approver's job in the first fortnight is speed. A plan that waits a week for sign-off pushes every build behind it back by a week. Ask them to block an hour in week two for the plan review.
What the first month looks like
When the five hand-overs arrive in week one, the month usually runs like this. It is the order we plan for, not a promise.
| Week | What happens | What it needs from you |
|---|---|---|
| 1 | Invite accepted, region confirmed, DNS records sent, data documents read | The invite, the DNS contact, the documents |
| 2 | Domain verified, warm-up starts, data gaps listed, 90-day plan sent | Records added, an hour from the approver |
| 3 | Plan signed off, first automation built and tested on real profiles | Sign-off, and any missing events from your developer |
| 4 | First automation live at warm-up volume | The approver's yes to go live |
Now picture the late version. The invite goes out in week two, the DNS records in week four, the data documents never. The agency spends the month on meetings and drafts, and the retainer fails the month-three test before it starts.
When a first-month launch is the wrong target
The first-month mark assumes a fairly clean start. Some starts are not, and it is better to say so on the first call.
- No developer access. If nobody can add or rename events, the first automation has to use data that already arrives. That means a simpler first flow, or a wait.
- A migration with years of history. Importing people, matching subscription status and rebuilding live automations all come before the old system switches off. Then the warm-up has to reach your full volume. Plan the cutover in months; our implementation cost guide covers what drives that work.
- A newly registered domain. The docs say to wait until it is at least 30 days old where you can.
- A security review for every login. Start that process before signing, not after.
If several apply, a first-month launch is the wrong promise, and a fixed-scope build with a longer runway is more honest. Our agency vs freelancer vs in-house guide helps decide the shape of help. If your workspace already runs automations, a Customer.io audit is a better first purchase than a retainer.
What the agency owes you
Hand-overs run both ways. A good agency sends its week-one list before the kick-off, so your team can start on the DNS and the invite straight away. When something is blocked, it names the item and the person on your side who can clear it, the same day. And it does not quietly bill a month of hours against a workspace it could not get into.
If you are comparing agencies, ask each one for its week-one list on the first call. A vague answer tells you more than a partner badge does. Our Customer.io agency page sets out how we work, and you can book a call with David to go through the list for your account.
Frequently asked questions
What should I give a Customer.io agency in the first week?
Give a Customer.io agency five things in week one: an Account Admin invite for a named agency login, a DNS contact, your event and data documents, one approver and a named warm-up owner. Each blocks a different part of setup.
Should I give my Customer.io agency Admin access?
Account Admin is the simplest role for an agency doing setup, because API credentials, team members and the account region sit with Account Admins. The alternative is a Member with "Manage API credentials" and Workspace Admin on the workspaces it builds in.
Can a Customer.io agency use one login for all its clients?
Yes, since 12 July 2026 an agency can use guest access to reach every client account from its own Customer.io login. You invite it as a guest, set its permissions for your account, and its actions appear in your audit log.
How long does Customer.io domain verification take?
Customer.io says domain verification can take up to 72 hours, though it usually completes much faster. The clock only starts once someone adds the four DNS records, so the real delay is usually finding that person.
Do I need to warm up my domain if we have sent email for years?
Yes, every new Customer.io sending setup needs a warm-up, because Customer.io sends from a managed subdomain that inbox providers see as new, whatever your root domain's history.
Can my agency build automations without being able to send them?
Yes, on Premium and Enterprise plans a custom role can let an agency, invited as a Member, build and edit automations without starting them. Since 10 July 2026, starting, scheduling and stopping automations needs the Execute permission.
How long does Customer.io agency onboarding take?
We aim to finish Customer.io setup within two weeks of signing, with the first automation live inside the first month. That holds when the week-one hand-overs arrive on time; a migration with years of history takes longer.
Sources
- Customer.io, How to add team members to your account, read 30 October 2026.
- Customer.io, Create & assign custom roles, read 30 October 2026.
- Customer.io release note, Custom roles: determine who can send messages, 10 July 2026.
- Customer.io release note, Manage all your accounts with a single login, 12 July 2026.
- Customer.io, Access multiple accounts, read 30 October 2026.
- Customer.io, Two-factor authentication, read 30 October 2026.
- Customer.io, Account regions (US and EU), read 30 October 2026.
- Customer.io, Domain authentication, read 30 October 2026.
- Customer.io, Safely warm up your sending domain, read 30 October 2026.
- Customer.io, Account verification, read 30 October 2026.
- Customer.io release note, Test emails before verifying your domain, 10 July 2024.
- Customer.io, Events: track activities for people, read 30 October 2026.
- Google, Email sender guidelines, read 30 October 2026.
- LaunchBay, Client onboarding statistics for marketing agencies, 1 September 2025.
- NerveCentral, AIRE Health case study.
Want this working in your Customer.io workspace?
It's what we do all day for SMBs—strategy, automations, deliverability and hands-on execution.
See how we work as a Customer.io agency →
