A client who regularly hires staff should not need the agency owner’s password to request every mailbox. Give the responsible person a separate dashboard login and only the domain access their work requires. The handover is complete when they can follow an agreed task and know when to contact you.
Agree one task before sending the invitation
Use adding a new employee as the handover task. Record which domain the client may manage, who approves the address and what to do if a plan limit blocks creation. Ask the invited user to follow the process, then check that another client’s domain is outside their access. A branded dashboard changes appearance; role and domain assignments control authority. Keep mailbox sign-in instructions separate from the administrator’s guide, and remove management access when that responsibility changes.
Decide who needs a dashboard login
Suppose your agency manages email for a store and a law firm. The store owner wants to add employees independently. The law firm only needs to use email and asks the agency to handle changes.
The store owner needs permission to manage the store's domain. An ordinary email user needs to sign in to their own mailbox. Those are different accounts and different tasks. Inviting someone to the dashboard doesn't, by itself, create a mailbox or allow them to read everyone's correspondence.
Before sending an invitation, ask what the client needs to do: create addresses, help employees, inspect settings, or simply read their own mail. A clear task makes it easier to choose a role without granting unnecessary access.
Assign a role and specific domains
Start with a list of the client's domains. The store might use shop.example, and the law firm law.example. If the store also owns another brand, deliberately include that domain in its assigned list.
TrekMail offers client, domain administrator, mailbox operator, and other access roles. Choose the role that fits the person's responsibilities, then check the actions it permits. Client and domain-level roles need explicit domain assignments.
Do not grant broad access just because a client needs one additional action. First check whether the required permission can be provided within their existing scope. The client interface guide explains dashboard sign-in, webmail sign-in, and how available actions depend on the role.
Check the account from the client's perspective
Before handing over access, try the intended workflow as the invited user. Open the domain list, mailbox list, and available settings. Test the actions for which the access was created.
For the store owner, that might mean adding a test employee and managing their mailbox. A viewer may only need to inspect permitted information. If a required button is missing, check the role and domain assignment before expanding access to the entire account.
Check the boundaries at the same time. The law firm's domain should not appear in the store's working list. Account billing settings and management of other clients are outside the responsibilities of someone administering one client's domain.
Then send the correct link. An administrator needs the dashboard address; a mailbox user needs the webmail address. Label the links with plain descriptions such as “Manage company email” and “Read your email” so clients do not look for their inbox in the administration panel.
Give the client a handover they can repeat
Write a short procedure using the client's own domain and ordinary job titles. State who may request a new address, who approves the name and who tells the employee how to sign in. Include the correct management link, the agreed task and the support contact. Keep the procedure free of the agency owner's password and any other client's information.
Use the first hire as a practice run before relying on the process for a real deadline. Ask the client contact to explain which login they are using and which domain they are changing. A person who can complete the steps while you guide every click may still need clearer written instructions. Record any confusing labels and revise the handover so the next hire does not require the same conversation.
If creation stops at a resource limit, make that an explicit handover result. Tell the client who can review the plan and who can approve additional cost. Giving the client a broader role won't create more account capacity. Avoid promising that self-service means they can add an unlimited number of employees.
Plan for a departure as carefully as a new hire
Adding staff is only half of the responsibility. Agree how the client reports a departure, who decides what happens to business correspondence and who removes the relevant access. An employee's mailbox and their management login may need different actions. Check both if the person held both responsibilities.
Do not make a password spreadsheet the backup plan. Keep an up-to-date list of authorised administrators and a recovery contact who can act if the client's usual contact is absent. Record the account's supported recovery process so a replacement administrator can follow it.
Where a client asks for access beyond its assigned domains, review the business reason first. They may need a new domain assigned to their existing role, or they may be asking for an action that the agency should retain. Record the decision in plain language so a future agency employee does not interpret an old exception as permission to expose the whole account.
Set a clear acceptance point
The handover is ready when the client can identify the correct entry page, see the intended domains, perform the agreed action and explain where to ask for help. Also verify that another client's resources remain outside that scope. Keep a dated record of the checked role and assignments, without claiming that every possible management action has been tested.
Review this record when the agency changes its service arrangement or the client appoints a different administrator. A working invitation from last year does not tell you whether the present contact still has the right responsibilities.
Agree on support and future changes
Self-service access reduces repetitive requests, but you still need an agreement about support. Explain which changes the client handles and when they should contact the agency. For example, the client might add employees but discuss a provider or domain change with you first.
White Label keeps one billing relationship between the agency's account and TrekMail. Handle charges to your own clients in your own commercial system. The White Label overview explains the branding options and the limits of this arrangement.
Review invitations and domain assignments when the client's contact person changes. A former employee should not retain email management access simply because they helped with the original setup. A short record of domain owners, current administrators, and support contacts makes handovers easier without passing around other people's passwords.
Related reading
- White Label Client Access: Letting Clients Into the Dashboard Safely
- Set Up Mailboxes Without Ever Sharing a Password
- White label email: what to check before your first client
- Three brands in one email account: who should see what?
- Let a temporary contractor send without opening team mail
