Designing customer-centred systems that help people succeed.

Context

When I became Head of Learner Success at AltSchool Africa, Customer Support was performing an essential operational function: responding to learner questions and resolving issues as they arose.

As the organisation scaled, I saw an opportunity to make better use of the conversations already happening in Support. Learners were repeatedly telling us where they were getting stuck, what was confusing them, and where our processes were creating unnecessary friction.

The challenge was not simply responding faster. It was creating a support operation that could resolve learner problems well while also helping the organisation understand why those problems were happening.

Approach

I started by strengthening the way the Support function operated: documenting standard operating procedures, giving the team clearer context on the learner journey, and creating structured escalation pathways with Programme Managers and Academic teams.

I also asked the team to look beyond individual tickets. Recurring questions, repeated points of confusion, and common learner blockers could tell us something about the wider experience. I documented those patterns and surfaced them to the teams that could act on them.

Outcome

A more consistent and proactive support operation, with clearer escalation paths and better visibility into recurring learner challenges. Average human response time improved from 45 minutes 39 seconds to 36 minutes 03 seconds within one month, roughly 21%. More importantly, learner insights began informing operational decisions beyond the Support team itself.

Context

One of the challenges I was trying to solve at AltSchool Africa was retention. As I thought more about the role Community could play, I became increasingly intentional about understanding the business and finding ways for Community to contribute to business goals while still creating value for learners.

Revenue was one of the metrics that mattered, which led me to think about tuition payments differently. I introduced payment reminders as one way to contribute, but I also knew what happened when a learner fell behind: some would eventually ask to defer or wait for another intake and start again.

So the payment reminder became more than a payment reminder. I used the communication to encourage learners to stay on track with their learning as well. Some appreciated the nudge. Others explained they were struggling financially or had become too busy to keep up. Those conversations reinforced something important: a learner not paying or progressing was not always a sign of unwillingness. Sometimes there was a blocker underneath it that we could only understand once we reached out.

Approach

I started looking beyond Community activity as a signal of learner progress. We had an LMS, which meant there was data showing which learners were engaging with their materials and which were not.

I reached out to the Data team to understand what was available and what we could track, then used that data to identify learners who had stopped engaging and reached out to encourage them back. At first I did this manually. The responses helped us separate learners who were simply busy and needed a nudge from those facing bigger blockers.

The manual process was useful for testing the approach, but it was not going to scale. I approached Engineering about automating the intervention, creating the learner segments and the messages for each group. Learners inactive for around two weeks received encouragement to get back on track; those inactive for longer received a more direct check-in focused on understanding what was getting in the way.

Outcome

The payment activation approach became repeatable across cohorts, and the LMS-based intervention created a more proactive response to inactivity. The important change was not sending more messages. It was moving from waiting for learners to tell us they were struggling to using available signals to start the conversation earlier.

Context

Customer feedback existed across surveys, Support conversations, community discussions, learner check-ins, student leaders and programme reviews.

The information was valuable, but it was easy for individual pieces of feedback to remain within the team or channel where they were received. I wanted to make sure recurring learner problems were not simply recorded. They needed to reach the people who could actually do something about them.

Approach

I brought together feedback from the different learner touchpoints and looked for recurring patterns rather than treating every response as an isolated issue. That meant analysing semester surveys and check-ins alongside Support conversations, community discussions and other learner interactions. I documented the themes, highlighted what needed attention, and shared the insights with the relevant stakeholders.

The important part for me was closing the loop. I didn't want feedback to end with a report. I followed up with the teams involved and advocated for the learner perspective in conversations with Product, Learning, Operations, Engineering, Finance and Leadership.

Outcome

Learner insight became part of cross-functional conversations around product, curriculum, operations, communication and support. The process influenced more than 15 improvements. The value was not in the number of surveys completed; it was in what the organisation chose to do with what learners told us.