A client calls after a website update and asks for the login to a service your business set up months ago. The account is attached to a former employee’s email address, the recovery phone belongs to someone else, and nobody is sure whose card renews it. The immediate task may be small, but the ownership confusion can turn it into a tense and expensive handoff.
Small service businesses often create accounts while trying to move a project along: a scheduling tool, email platform, domain account, analytics property, online store, booking system, or design workspace. The practical fix is to make account ownership a project decision, not a cleanup job. Establish one rule: accounts that are central to a client’s operations should be created in the client’s name and controlled by the client, while your business receives the access it needs to do the work.
This does not mean a client must do every technical step. It means the account’s identity, recovery path, billing authority, and final control do not depend on a vendor’s personal inbox or a single staff member.
Good client service is not making yourself impossible to replace. It is leaving the client with a working business asset and a clear, orderly way to keep working with you.
Why “we’ll sort out access later” creates avoidable trouble
Account access has several layers. A person may be able to sign in but lack billing permission. A business may pay for a tool but not control the recovery email. A client may own a domain name while an agency controls the website hosting. Calling all of this “the login” hides important differences.
When those layers are mixed together, ordinary events become difficult:
- A team member leaves and takes access history with them.
- A client changes its point of contact.
- A card expires and the billing alert goes to an unattended inbox.
- A project ends and the client needs another provider to take over.
- An account security check requires a recovery email or phone number no one can use.
The problem is not that your business helped create the account. In many projects, that is efficient and appropriate. The problem is creating a client’s core operating account under a personal or agency-controlled identity without recording the arrangement.
Decide which accounts are truly client-owned
Start with a plain distinction: does this account mainly run the client’s business, or does it mainly run your service business?
Accounts that usually belong to the client
These are accounts the client should be able to retain if they change employees or providers. They commonly include the client’s public-facing domain registration, business email administration, website hosting, e-commerce platform, booking or customer-management system, advertising account, payment service, analytics property, and social media business presence.
The exact setup varies by platform, but the ownership principle remains useful: the client’s authorized representative should be the primary owner or administrator where that role exists. Recovery details should lead to an address and phone number the client controls. Billing should be visible to the person responsible for approving it.
Accounts that usually belong to your business
Your internal project-management system, design software subscription, time tracker, proposal tool, and shared internal templates are ordinarily yours. A client may be invited into a project area, but they do not need ownership of the system that supports your operations.
There are gray areas. For example, an email-marketing platform might be part of your managed service at first and later become an account the client runs directly. Do not rely on assumptions in these cases. State what the client is getting, who pays, and what happens at the end of the engagement.
Use a four-part setup rule before creating an account
Before anyone clicks “create account,” answer four questions in a short internal record. This takes a few minutes and prevents a vague promise from becoming a permanent workaround.
- What is the account for?
Use a functional name, such as “online booking system” or “website hosting,” rather than a vague entry such as “client software.” - Who is the legal or practical owner?
Name the client organization or your organization. Avoid using an employee’s name as a substitute for an ownership decision. - Who holds the primary recovery path?
Record the client-controlled business email or authorized contact responsible for recovery. Do not put passwords, security answers, or codes in this record. - What access does your team need?
Specify a role where the service allows it: administrator, editor, billing viewer, contributor, or another defined permission. Give only the access needed for the work.
If a platform has only one owner role, agree in writing who will hold it and how a transfer would happen. The purpose is not to create a legal document. It is to make an operational arrangement visible before the project depends on it.
Make an ownership register that people will actually maintain
A spreadsheet, secure client record, or project page can work. The best format is the one your team will check during onboarding, monthly maintenance, and offboarding. Keep it separate from passwords and authentication codes. Passwords belong in an approved secure credential system, not in a project tracker, a shared note, or an email thread.
For each account, capture only useful operational details:
- Client name and project
- Service or account purpose
- Ownership: client or your business
- Primary client contact or role
- Agency/team access level and the people who have it
- Billing responsibility
- Recovery contact owner
- Date created or last reviewed
- Any important handoff note, such as “transfer requested” or “client has confirmed administrator access”
Use roles when possible instead of listing a private personal email as the only long-term point of contact. “Client operations lead” is more resilient than treating one individual as the permanent account owner. Still, the actual service may require named users, so note those users and review them when roles change.
Keep credentials out of the register
An ownership register is a map, not a key ring. It should tell a teammate where an account lives, who controls it, and which access arrangement applies. It should not expose passwords, backup codes, or answers to identity-verification questions. Separating these records limits the damage caused by an accidentally shared project document and makes routine account changes easier to manage.
Set up access without making the client do unnecessary technical work
“Client-owned” should not become “client left alone with unfamiliar setup screens.” Offer a guided process that preserves ownership.
For a new account, a workable sequence is:
- Ask the client to nominate an authorized contact and a business-controlled recovery email.
- Confirm who will approve recurring charges, if any.
- Have the client create the account, or join a screen-sharing session while they complete the ownership and recovery fields themselves.
- Ask the client to invite your business or designated team members using the platform’s normal permission tools.
- Confirm that both sides can reach the appropriate settings without sharing a master password.
- Record the arrangement in the ownership register and note the review date.
Sometimes a client reasonably asks your business to create the account on its behalf. In that case, use the client’s authorized business email and recovery details from the beginning where the service permits it. Then invite the client promptly, confirm their access, and document the result. Do not let a temporary agency inbox become the invisible permanent owner simply because it was convenient on launch day.
Handle existing mixed-up accounts with a calm cleanup plan
Many businesses already have accounts created under old staff addresses or a provider’s email. Treat this as a practical inventory exercise, not an accusation.
First, list accounts that affect the client’s ability to communicate, sell, collect money, publish, or preserve a public identity. Prioritize the accounts that would cause the most disruption if access disappeared. Then, for each account, determine whether the service offers an ownership transfer, additional administrators, updated recovery information, or a billing-contact change.
Some platforms make transfers straightforward; others have restrictions, separate billing profiles, or support processes. Do not promise a transfer before checking the account’s available settings and the client’s records. If an account cannot be cleanly transferred, document the current status, the available alternatives, and the next best protective step, such as adding a client-controlled administrator or exporting material the client is entitled to retain.
A hypothetical cleanup example
Imagine a two-person studio that manages a local retailer’s website. The hosting account was opened under the studio owner’s email, while the retailer pays the invoice. The studio could first add the retailer’s operations contact as an administrator, update the recovery email to a retailer-controlled address if the platform allows it, and confirm who receives billing notices. It would then record whether formal ownership transfer is available. The retailer gains visibility, while the studio still has the permissions needed to maintain the site.
That is more useful than emailing a password, because the client can retain access even after passwords change.
Build account ownership into your beginning and ending rituals
Ownership records decay when they are created once and never revisited. Add two small checkpoints to your workflow.
At kickoff: identify accounts likely to be created, identify the client contact authorized to own or approve them, and explain how your team will receive access.
At closeout: review the register with the client. Confirm that the client can access client-owned accounts, remove team members who no longer need entry, and provide a concise list of accounts your business will stop managing. For ongoing retainers, make the same review part of an annual account check.
Be especially careful when someone leaves your own business. Removing former staff from client systems protects both the client and your team. The ownership register gives you a reliable list of places to check instead of depending on memory.
Common mistakes that defeat the rule
- Using one agency email for every client account. It feels tidy until the inbox owner changes roles, misses a recovery request, or becomes a bottleneck.
- Equating payment with ownership. The payer may not have administrative or recovery control. Record those roles separately.
- Sending master passwords in email. This creates a long-lived, easily forwarded record and makes it hard to know who has access later.
- Giving everyone full administrator access. Broad permissions are easy at the start but complicate security, accountability, and offboarding.
- Skipping the review because the project is small. Small accounts can become essential once a client builds processes around them.
The goal is not paperwork for its own sake. It is a clean answer when someone asks: “Who owns this, who can recover it, who pays for it, and who currently has access?”
Your next action
Choose one active client this week. List the three accounts most essential to that client’s day-to-day operations. For each one, write down the owner, recovery contact, billing contact, and your team’s access level. Any blank field is a specific conversation to schedule before it becomes an urgent access problem.
Ad