An agency builds a funnel for a client. The client shares a login, the operator does the work, and months later nobody is sure who controls the domain, payment settings, email list, or automations. That arrangement may feel quick at first, but it leaves a messy handover and too much dependence on shared credentials.
Systeme.io offers sub-accounts for managing client or project workspaces from a main account. Its help center describes creating sub-accounts, switching between them, viewing separate statistics, and inviting an assistant or customer with an access level. It also notes that resource limits depend on the current plan. Those capabilities can support an agency workflow, but the sub-account structure alone does not settle ownership, permissions, billing, data export, or what happens at contract end. (Systeme.io Help Center: How to create a sub-account)
Systeme.io’s current help center says sub-accounts are available on every plan, with each sub-account receiving the same resource limits as the main plan and no additional sub-account charge. It also warns that publicly selling access as a lifetime deal or below the platform’s official subscription prices violates its terms and can lead to account suspension. Agencies that package platform access into a service should check the current terms and explain the billing arrangement accurately. (Systeme.io Help Center: How to create a sub-account).
The reliable approach is to treat account structure as one part of the service agreement and operating process.
First choose the account model
An agency can use a sub-account under its main workspace or work inside an account established and controlled by the client, with access granted to the agency. The right setup depends on the client’s requirements, the current platform options, and how the parties want billing and ownership to work.
A sub-account under the agency’s main account can make it easier for the agency to switch between projects from one dashboard. It can also create dependency: the agency controls the main workspace that contains those sub-accounts. If the client must retain direct control independent of the agency, confirm the platform’s supported transfer, access, and migration path before choosing this structure.
A client-controlled account can make ownership clearer, while still allowing the agency to perform work through a named user or role where the platform supports it. This requires the client to participate in setup and keep their own account, billing, and recovery details current.
Neither model should be described as “the client owns everything” or “the agency can transfer everything later” until the relevant account settings and platform terms support that exact statement. Put the intended ownership and exit route in writing.
Define four kinds of control
Before inviting anyone, identify who controls each layer:
- Workspace: the main account and any sub-accounts, including who can create, access, or remove them.
- Business assets: domains, pages, funnels, email sequences, course materials, brand files, and templates.
- Money and customer relationships: payment connections, billing details, customer records, refunds, and payout settings.
- Decision rights: who approves the offer, claims, prices, emails, course content, and changes that affect customers.
Systeme.io separates assistant and administrator roles, but even the assistant role can create, edit, and delete much of the workspace’s content. Administrators can also see sensitive information such as revenue and transaction history. Some controls—including payment gateways and custom domains—remain reserved for the account owner. Treat these roles as meaningful access, not fine-grained permissions: invite named people, choose the narrower role when it is sufficient, and confirm the current access list before granting it. (Systeme.io Help Center: How to invite an assistant)
Name the people responsible for each layer. If the agency needs administrator access for a build, specify why and whether it will be removed or changed when the task ends. Do not share a client’s password when an individual invitation is available.
Agree on control before work begins
The contract should identify deliverables, support, approval deadlines, fees, ongoing expenses, data handling, access, and the offboarding process. State which account model the project will use and who pays platform charges. If payment or revenue-share terms are part of the engagement, define the calculation, reporting source, timing, deductions, and treatment of refunds.
Use the client’s existing account if that is the agreed model. If the agency creates a sub-account under its main workspace, tell the client clearly how that structure works and what access they will receive. Check plan limits for contacts, funnels, courses, email, or other resources used by the project before promising capacity.
Invite each person through the platform’s supported workspace member process. Select assistant or administrator access according to actual duties, not convenience. Confirm the invitation works, and record who retains recovery access. Never put passwords or API secrets in the project notes or shared handover document.
Verify the setup together
The client should be involved in connecting domains, payment gateways, and other sensitive business accounts. The agency can provide instructions or guide the setup, but the client should retain control of credentials, recovery details, and the underlying service agreements. Confirm DNS changes and email authentication with the domain owner before publishing.
List the material already in use: contacts, products, pages, automations, course files, domains, integrations, and payment settings. Record what will be migrated, rebuilt, or left in place. Test the customer journey from opt-in or purchase through confirmation, access, follow-up, and support. A page rendering correctly does not confirm that payment, email, and course access work together.
Before launch, show the client where to review sales and customer questions, who handles refunds, and how to request a change. The agency remains responsible for its contracted tasks, but the client should understand the routine decisions they own.
Plan for the exit before the project starts
A good onboarding plan includes the offboarding plan. At the beginning, record what the client expects to retain and how the project will deliver it if the relationship ends.
- Access: identify which users and permissions will be removed, changed, or retained.
- Assets: list pages, funnels, automations, emails, course materials, and creative files the client should receive or control.
- Data: check the platform’s current export options for contacts, transactions, and other relevant records. Export format and completeness should be tested before it becomes urgent.
- Connected services: confirm what happens to domains, payment gateways, email sending, integrations, and API credentials.
- Routine operations: have the client practice common tasks such as updating a page, reviewing an order, or adding a lesson if those tasks are part of their role.
- Open obligations: settle invoices, commissions, refunds, support requests, and any agreed continuing work.
If the sub-account remains under the agency’s main account, do not promise an automatic transfer unless the platform provides and the parties have tested that route. Depending on the setup, the handover may require exporting assets, sharing supported content, rebuilding elements in a client-controlled account, or another documented process. Confirm the path early, estimate the work, and include it in the contract.
What this structure can and cannot do
Sub-accounts can help an agency keep project workspaces separate and navigate multiple client setups from a main account. The platform’s help documentation also describes separate statistics for each sub-account and access for assistants or customers. These are useful operating capabilities, not substitutes for a data policy, security practice, or legal agreement.
The structure does not automatically guarantee that each client owns the sub-account, can remove the agency, has access to every setting, or can export every record in the required format. Nor does separating workspaces remove the need to check who can view customer information, manage payments, or change a published offer. Verify those details in the current product and account plan.
As the agency grows, review capacity and access periodically. Remove users who no longer need entry, rotate credentials where appropriate, and check that every project has a current owner and exit plan. A centralized dashboard is useful only when the agency can explain what it controls and when that control ends.
Make the exit part of the setup
Use the account structure that matches the ownership agreement and customer workflow. A sub-account may be convenient for an agency managing several client projects. A client-owned workspace may be a better fit when direct client control and independent continuity are priorities. Test the platform’s supported access and transfer steps before making a promise.
The professional offer is not “we will hold the keys.” It is “we will do the agreed work, document the system, and make the control boundaries clear.” That approach protects the client, gives the operator a manageable workflow, and makes the end of an engagement a planned transition rather than a recovery exercise.
