About usServicesTrainingAcademyKnowledge hubAI solutions Book a consultation

Home / Knowledge hub / Articles

From spreadsheets to a system: application processes that hold up

How to design an application process for bursaries, learnerships and ESD beneficiaries that can explain every decision months later.

By BS Vision · · AI and data

Bursaries, learnerships, internships and enterprise development programmes all begin the same way: people apply. In many companies that first step still runs on an online form feeding a spreadsheet, a shared mailbox full of attachments and a shortlist agreed in a meeting. It works until someone asks a hard question.

Why was this applicant declined? Which documents did the committee see? Was the same rule applied to everyone? Where is the learner's signed agreement, and who has had access to her ID document since she applied? For B-BBEE purposes, can you show that the beneficiary met the requirements at the time the money was spent?

A process holds up when it can answer those questions months later, without a search through inboxes. That cannot be bolted on at the end. It comes from six design choices made before the first application arrives, and this is how we approach each of them.

Ask only for what you will use

Every field on an application form should exist because a criterion, a legal requirement or a scorecard claim needs it. POPIA requires personal information to be collected for a specific, explicitly defined purpose (section 13) and to be adequate, relevant and not excessive (section 10). Applicants must also be told, among other things, what is being collected, why, and whether supplying it is voluntary or mandatory (section 18).

In practice, this means separating what you need to assess an application from what you need only once a person is accepted. A bank account number belongs in onboarding, not in the first form. Ask for race and disability information only where a programme or a scorecard claim requires it, and explain why you are asking.

Write the criteria down before you open

Eligibility and selection criteria should be fixed and published before applications open, and held in the system as rules rather than in someone's head.

Some are eligibility rules: the beneficiary requirements the Codes set for enterprise and supplier development (enterprise size and level of Black ownership among them), or the conditions a bursary must meet to count towards skills development. Others are selection criteria: academic results, the viability of a business plan, location, field of study.

Keep the two apart. Eligibility can be checked early and consistently. Selection involves judgement, and should be recorded as judgement, with reasons.

Link each claim to one document

Each claim an applicant makes should be linked to the document that supports it: the academic record for results, the B-BBEE certificate or sworn affidavit for ownership, the company registration documents for a business. Store each document once, against the applicant's record, with the date it was received and, where relevant, its expiry date.

This is where AI earns its place. It can read an uploaded certificate or affidavit, extract the level, ownership percentages and dates, compare them with what the applicant entered and flag a mismatch or a missing page. A person then confirms. The reviewer starts with a short list of exceptions rather than a stack of PDFs.

Leave the decision with a person, and record it

Every decision should record who made it, when, against which criteria and why. A decline needs a reason that could be shown to the applicant. Where a committee decides, the system should hold each member's assessment as well as the final outcome.

Be careful with automation at this point. Section 71 of POPIA says a person may not be subject to a decision that has legal consequences for them, or affects them to a substantial degree, if it is based solely on automated processing intended to profile them. The exceptions are limited, and where they rely on protective measures, those must include a chance for the person to make representations. A bursary or a place in an enterprise development programme can easily affect someone substantially.

Our position is simple: AI can check eligibility, sort and summarise, but a person decides who is accepted.

Keep the record going after acceptance

For transformation programmes, acceptance is where the evidence starts. A bursary needs proof of registration and payment. A learnership needs a signed agreement, attendance records and, in time, the outcome, including whether the learner was absorbed into employment, which can earn bonus points under skills development. An enterprise development beneficiary needs a baseline, a record of the support given and evidence of its progress.

When the application system flows straight into the programme record, the verification file builds itself through the year. When it does not, someone rebuilds it in a hurry before the verification agency arrives.

Design the audit trail in from day one

An audit trail is a log of every action on a record: who viewed or changed it, what changed, when, and who approved it. It lets a verification agency, an internal auditor or the applicant follow how a decision was reached. It cannot be added afterwards with any credibility. It has to be part of the design from the first day.

Alongside it, set retention rules. POPIA says records should not be kept longer than necessary for the purpose for which they were collected (section 14), unless the law, a contract or another recognised reason requires it. Unsuccessful applications, in particular, should not live forever on a shared drive.

Signs your current process needs attention

  • Applications arrive by email, and attachments are saved in several places.
  • Nobody can say, without a day of checking, how many people applied last year and why each was declined.
  • The criteria document was changed after applications opened.
  • Learner or beneficiary files are rebuilt each year for verification.
  • Everyone in the team can open every applicant's ID document.

We design and build application and programme systems for bursaries, learnerships and enterprise and supplier development, set up around each client's own criteria and designed to run on the client's own systems. If one of the signs above sounds familiar, write to us at sales@bsvision.co.za and tell us how your process runs today.

Talk to BS Vision. We are B-BBEE and transformation consultants in Johannesburg, serving clients across South Africa.

Email sales@bsvision.co.za More articles