Starting Without A Proper Access Review
The most common mistake is rolling out single sign-on before checking who needs access to what. When every staff member gets broad access to every app, the setup looks simple at first but it quickly becomes messy. A small business in Woodstock or Sandton can end up with former staff still able to open systems, or new hires waiting for access they should already have on day one.
Before any rollout, list each application, the people who use it, and the minimum level of access each role needs. That sounds basic, but it is the part many teams skip when they are busy. In South African offices where one person often handles sales, admin and accounts, role clarity matters even more because one account mistake can affect several departments.
- Map every app to a staff role, not to a person
- Remove old accounts before moving anything live
- Decide who approves access changes and how quickly
- Check which tools are used by remote staff and which are office only
A proper review also helps with compliance. If a client, supplier or auditor asks who can open a file sharing app or finance platform, you want a clear answer not a guess.
Using One Permission Structure For Everyone
Another error is creating one shared setup for the whole company and hoping it will suit everyone. A five person team in Durban will not use access the same way as a 40 person office in Pretoria with admin, operations and field staff. If permissions are too loose, staff see too many apps. If they are too strict, they start working around the system and sending passwords by message, which defeats the point.
Good permission mapping keeps access simple without making it open-ended. It should reflect how your team actually works, including temporary staff, contractors and part-time help during busy periods. If someone only needs access for one project or one month, their permissions should reflect that from the start.
Keep these points in mind when setting permissions:
- Separate admin access from daily user access
- Create groups for departments, not individual people
- Set a process for temporary access and removal dates
- Review shared accounts and replace them where possible
In smaller businesses, the biggest risk is not the software itself, it is letting old habits continue inside a new system.
Rushing The Password Migration
Moving passwords from spreadsheets, notebooks or memory into a secure vault can be straightforward, but only if it is planned properly. A rushed migration often leads to missing logins, duplicated entries and staff who still keep private copies on their phones or in WhatsApp chats. That creates confusion and support calls that could have been avoided.
The better approach is to sort the password list before moving anything. Remove duplicate entries, confirm which accounts are still active and decide which passwords should be changed after migration. For teams working across Johannesburg, Cape Town and remote home offices, the process should also consider internet reliability and load-shedding interruptions so people know what to do if the switch happens mid-day.
Useful migration steps include:
- Clean old password lists before import
- Update weak or reused passwords during the move
- Test access on a small group first
- Confirm all staff know how to find shared logins
Do not assume that everyone will remember where everything is stored. If the vault structure is unclear, the team will keep asking the same questions for weeks.
Skipping Real User Training
Many rollouts fail because the technical work is done but nobody has shown staff how to use the system properly. A tool can be secure and still be ignored if people find it awkward. That is especially true in small teams where everyone is under pressure to keep moving and does not have time to read a long instruction sheet.
Training should be practical and role-based. An owner, an office manager and a new starter do not need the same level of detail. Show staff how to log in, how to save a password, how to use shared access and what to do when they change devices. For remote teams in Gqeberha, Stellenbosch or further afield, make sure the process works well over a normal home connection, not only in a strong office network.
Training that works usually includes:
- Short live sessions for staff and admins
- Simple examples using the apps they use every day
- Clear steps for password resets and device changes
- A contact path for support after go-live
When staff understand the system early, adoption improves and the rollout feels lighter from the start.
Leaving Offboarding Until Someone Resigns
Offboarding is one of the areas businesses leave too late. If an employee leaves and access is not removed quickly, you are relying on goodwill rather than process. That is a risk for any company, whether the team is based in Century City or spread between Durban and Pretoria.
A solid offboarding process should be part of the rollout, not an afterthought. It should cover who disables accounts, who checks shared logins and who updates the vault when a person exits. If the departing staff member managed supplier systems, finance tools or a social account, those passwords and permissions need to be reassigned immediately.
To keep exits clean, make sure you have:
- A checklist for disabling access on the final working day
- A process for handing over shared credentials
- Named owners for each business system
- A record of which access changes were completed
This is one of the simplest ways to reduce risk and avoid awkward follow up after someone leaves.
Treating Support As A Once-Off Task
Even a well planned rollout will need support after launch. Staff forget steps, new apps get added, and permissions need adjusting when teams grow. If a business treats the rollout as a once-off project, the system soon becomes patchy and people start finding their own workarounds.
Ongoing support does not need to be complicated. It just needs a clear contact point, a basic review cycle and someone who knows how the setup should work. Quarterly access reviews are particularly useful for South African small businesses because teams change quickly and one role often covers more than one function. A short review every few months can catch inactive accounts, role changes and unnecessary access before they become a problem.
A practical support rhythm might include:
- Monthly checks for new staff and removed staff
- Quarterly access reviews for all active users
- Admin refreshers when new tools are added
- Support for staff who change devices or locations
When support is steady, the system stays useful. That is what keeps adoption high and keeps password chaos from creeping back in.
