Why the team asked for a cleaner access process
The client was a training centre admin team based in Stellenbosch, working with lecturers, front office staff, finance support, and part-time co-ordinators. They were using a mix of saved browser passwords, shared notes, and a few staff-held login details that were hard to track when someone left or changed roles. For a team handling learner records, schedules, invoices, and cloud services, that created avoidable risk and a fair amount of admin pressure.
The brief was straightforward: centralise access, reduce the time spent resetting passwords, and put proper offboarding steps in place. They also wanted a system that would work for staff in the office and for remote support users joining from other towns. In practical terms, the team needed something simple enough for daily use but structured enough to meet internal controls and school governance expectations.
Constraints on site and what mattered most
The main constraint was time. Admin staff could not spend long in training sessions, and there were peak periods during registration and term changes when the office was already busy. The team also needed a setup that would work well on mixed devices, including laptops used at reception and at home, with a steady process for handling staff turnover.
Because the office is in the Cape Winelands and some team members commute from surrounding areas, remote onboarding had to be reliable even when internet quality varied. The system also had to work during load-shedding, so we kept the rollout light on admin complexity and easy to pick up after a power interruption. Permissions needed to be clear for each role, not shared loosely between departments. A clean structure mattered more than bells and whistles, and the client was clear about that from day one.
- Small admin team with multiple roles and changing access needs
- Remote onboarding required for support staff outside Stellenbosch
- Offboarding had to be quick and auditable
- Minimal downtime during the registration period
What we supplied and how the rollout worked
We started with an initial security review and mapped the existing login points used by the admin team. That included cloud folders, learner admin tools, finance systems, internal communications, and a few shared utilities used by more than one person. From there, we built a vault structure that matched the actual working groups, rather than forcing everyone into one broad folder. That made it easier to control who could see what, and reduced the risk of staff using the wrong credential by mistake.
We then handled SSO configuration for the main applications so staff could sign in with fewer repeated passwords. After that, we set up permission mapping for permanent staff, temporary support users, and management access. The implementation included password migration, admin training, and user onboarding training, with clear steps for new starters and leavers. Revasha handled the support side and Kgosi worked through the technical setup with the team, while Zinhle ran the training sessions in short blocks so people did not lose half a working day.
- Initial Security Review
- Platform Setup
- SSO Configuration
- Vault Structure Design
- Permission Mapping
- Password Migration
- User Onboarding Training
- Admin Training
Offboarding steps that the admin team could actually follow
The biggest improvement came from the offboarding process. Before the project, access removal depended too much on memory and handover notes. If someone left suddenly or moved to another department, there was a chance that one or two accounts might stay active longer than they should. We redesigned that process so the team had a clear sequence to follow, including account review, role change checks, shared login reassignment, and final access removal. It sounds basic, but it removed a lot of guesswork.
Ruan checked the security settings and made sure the permissions matched the client’s internal control needs. Zaheer helped the admin team understand what to do when a staff member changes role, not just when someone leaves. That distinction matters in schools and training centres because access often changes before employment does. With the new process in place, the client had a way to handle staff movement without relying on ad hoc messages and memory. The difference was not just security, it was calmer admin work too.
Timeline from first review to handover
The full rollout took three weeks. Week one covered the security review, access mapping, and the vault structure plan. Week two covered platform setup, SSO configuration, and password migration for the first group of users. Week three focused on training, testing, and the offboarding workflow, with a final handover session for the admin leads. The project moved quickly because the client had a clear internal contact and the team kept decision-making tight.
We kept the sequence practical so the staff could continue working while the new setup went live. A few small changes were made after the first round of testing, mainly around naming rules and who could approve access changes. Nothing major, just the sort of detail that usually only shows up once real people start using the system. By the end of the third week, the admin team had a documented process and a simpler daily routine.
- Week 1: review and planning
- Week 2: setup, SSO, migration
- Week 3: training, testing, handover
Results for the Stellenbosch admin team
After the rollout, the team had centralised access for the main systems, clearer ownership of shared credentials, and a more controlled offboarding flow. Staff no longer had to chase passwords across notes, messages, or individual browsers. New starters could be brought in with a repeatable process, and the admin leads had one place to manage access instead of several loose methods. The reduction in back-and-forth was immediate.
The client also reported better confidence around staff changes because permissions were now mapped by role. That helped with accountability, especially when part-time support people came and went across the term. In a school-style admin environment, a small delay can snowball into a bigger issue by afternoon, so the value was not only security but time saved. The team could focus on learner admin and reporting rather than password wrangling. It made the office feel a lot less fragile, which was the point.
What we would do again for a similar school team
For a similar client, we would use the same approach: start with a clear access review, build the vault structure around actual roles, and keep the training short and specific. That worked well here because the team was busy and did not need a long change programme. We would also keep offboarding as a separate, documented step rather than folding it into general admin tasks. That makes it easier to follow when staff change quickly.
If we were doing this again for another Stellenbosch school, college, or training centre, we would still prioritise role-based permissions, remote onboarding support, and a practical handover plan. Those are the parts that save time long after the setup is finished. The right system should reduce admin work, not create another layer of it, and this project showed that a tidy structure can do exactly that.
Key facts
| Client type | Training centre admin team |
|---|---|
| Town | Stellenbosch, Western Cape |
| Project length | 3 weeks |
| Core services | Initial Security Review, Platform Setup, SSO Configuration, Vault Structure Design, Permission Mapping |
| Training included | User Onboarding Training and Admin Training |
| Key outcome | Centralised access with clearer offboarding and fewer password-related delays |
