Managing website users: onboarding, offboarding and access reviews

Every website account has a life: it is created for someone, it changes as their job changes, and one day it should stop working. Most small businesses handle the first part and forget the rest, which is how a site ends up with thirty logins and a manager who can identify maybe twenty of them. Good website user management is simply a repeatable process for those three moments, written down so it happens the same way whoever is on duty.

None of this needs special software. A shared spreadsheet and two calendar reminders are enough for a team of under fifty people.

Keep one register of accounts

The foundation is a single list of who has an account, kept outside the website itself so you can read it even when the site is down. One row per account, with these columns:

• Full name and personal work email
• Username on the site
• Access level or role
• Start date and, where known, end date
• Who approved it
• Other systems they were added to, such as hosting, analytics or the payment gateway
• Date of last review

The last column is the one people skip and the one that makes reviews quick. Without it, every review starts from scratch.

Creating an account the right way

Provisioning is worth standardising because shortcuts taken here cause the mess later. A short routine for each new joiner:

1. Confirm which role they need from their manager, in writing, before creating anything.
2. Create the account with their own work email address. Avoid shared mailboxes, and avoid personal Gmail addresses for staff wherever possible.
3. Use a consistent username pattern so accounts are easy to match to people later.
4. Let the system send an invite so the person sets their own password. Never type a password for them and send it over WhatsApp.
5. Require two-factor authentication before they start work if the role can change anything important.
6. Add the row to your register, including the systems beyond the website.
7. Spend ten minutes showing them what their role can and cannot do, so they do not ask for more access out of confusion.

Resist the habit of copying an existing person's access as a template. Whatever extra rights that colleague accumulated get inherited silently, and the problem compounds with each new hire.

Keeping accounts current when jobs change

The middle of the lifecycle is where most drift happens. Someone moves from support to catalogue work and gains product rights while keeping the old ones. A year later they hold three roles' worth of access.

Make internal moves a trigger, not just joining and leaving. When a person changes team, the rule is replace, not add: the new role goes on, the old one comes off the same week. Handle long leave the same way if the absence is more than a month, by suspending the account rather than leaving it open.

Temporary elevations need an end date written in the register at the moment they are granted. "Just for this campaign" without a date almost always becomes permanent.

Running a quarterly access review

A review is a scheduled read of the register against reality. Put it in the calendar four times a year and keep it to under an hour.

1. Export the current user list from the website and put it beside your register.
2. Highlight any account in the system that is missing from the register, and find out where it came from before doing anything else.
3. Send each manager the rows for their team and ask them to confirm or flag each one. A one-line reply is fine.
4. Act on the flags: lower access, suspend, or close.
5. Look for accounts with no login for 90 days and ask whether they are still needed.
6. Count the accounts holding the highest access level and confirm each is justified.
7. Stamp the review date on every row you checked.

Keep the outcome of each review, even as a dated note in the sheet. If a question ever arises about who could have made a change, this record answers it far faster than memory.

Closing an account without losing work

When someone leaves the organisation or a project ends, the account should stop working the same day. A few things are worth doing in order so nothing is lost:

• Check what the account owns: draft posts, saved reports, scheduled content, automations that run under their name.
• Reassign that content to another user or a neutral account before closing.
• Prefer deactivating over deleting when records like orders or published articles reference the user, so history stays intact.
• End active sessions, not just the password, so an already-logged-in browser cannot keep working.
• Mark the row in the register as closed with the date, rather than deleting the row.

If the system offers a clear "deactivate" or "suspend" option, use it. Deleting a user in some platforms silently reassigns or removes their content, which is a nasty surprise to discover months later.

Automating the boring parts

Once the process is steady, a few small automations save real effort. Ask your developer whether your admin can show a last-login column on the user list, flag accounts unused for 90 days, email you when a new admin-level user is created, and require two-factor authentication for chosen roles. None of these are large pieces of work, and each removes a manual check from your quarterly review.

Start with the list you already have

Do not wait for a perfect process. Export your current user list this week, build the register from it, and mark anything you cannot immediately explain. Fixing those unknowns is usually the single biggest improvement, and everything afterwards is maintenance.

If your website's admin makes any of this awkward, such as no roles, no last-login information or no way to suspend a user, that is a software limitation worth fixing. Our team can review how your admin handles users; see our custom software and admin panel work.

Frequently asked questions

How many accounts is too many for a small business website?

There is no fixed number, but every account should map to a named person doing current work. If you cannot name the person behind a login, that is one account too many regardless of the total.

Should I remove an account immediately or wait a few days?

Disable access on the last working day. You can keep the disabled account for a while for reference, but the ability to log in should end immediately.

Can I use one account for a whole department?

It is a poor idea. Shared accounts break accountability, cannot be revoked for one person, and make logs useless. Individual accounts cost nothing on most platforms.

What records should I keep about user accounts?

Keep enough to answer who had access, at what level and when: the register rows, approval messages and review dates. Avoid storing passwords anywhere in these records.