We run several cohorts a year. Is each one a separate setup?

No. The template is set up once, per award. After that a cohort is a recipient list: you send it, we run it, and every learner gets their certificate and their verification page. The tenth intake costs the same effort as the second.

What do you need from us to issue a cohort?

A list with each learner's name and email address, the award they earned, and the issue date. That is the whole requirement. Most providers already hold this in their learner management system or a spreadsheet, and exporting it is usually a five-minute job.

What happens when a learner resits and passes later?

They are issued when they pass, not when their cohort passes. Late completions, resits, and deferred learners are ordinary single-recipient issuances rather than an exception the process cannot handle.

Employers keep asking us to confirm old certificates. Does this stop that?

It is the main reason providers move. Each credential has a permanent page an employer can open themselves, so verification stops arriving as email your team has to answer. Certificates you issued before joining can be brought across and issued as verifiable credentials retrospectively.

Do you support certificates that expire?

Awards can carry an expiration period, which is recorded against the award and shown on the credential. What we do not currently do is notify you or the learner automatically when that date passes, so if renewal reminders are central to your programme, plan on running those from your own system for now.

Training providers and academies

Certificates for every cohort, without the admin growing with the intake

Training providers issue in bursts. A cohort finishes, several hundred certificates are needed at once, and then nothing happens for three months. Except the corrections, the late finishers, and the employers asking about someone who graduated last year.

Request a Demo How bulk issuing works

Where the work actually goes

Providers budget for the first of these four and are surprised by the other three. What separates the last one is its shape rather than its size: the first three are bounded work that finishes when the cohort does, while verification requests arrive against every cohort you have ever run and never stop arriving. A cost that accumulates will overtake one that resets, and the only question is when. Certificate fraud in Nigeria covers why that fourth cost exists at all, and why it lands on the issuer rather than on anyone else.

The run itself: Producing the documents. The part everyone plans for, and the smallest of the four.
The stragglers: The learners who finish late, resit, or were deferred. They arrive in ones and twos for weeks after the cohort closes, and each one restarts the process for a single person.
The corrections: Some learners write back about a misspelt name, a wrong date, or the wrong award, and the number is never zero on a cohort of any size. Every correction means regenerating, re-sending, and hoping the wrong version has not already been circulated.
The alumni tail: Employers asking you to confirm a certificate from two intakes ago. This one never stops, grows with every cohort you run, and lands on whoever is least able to say no.

A cohort, start to finish

An illustration rather than a case study: a composite of how issuing runs, not an account of a particular client. For an account of a particular client, with the numbers, see what 48 CFA Society Nigeria credentials did over ten months.

A provider runs a twelve-week data analytics programme, three intakes a year, around 180 learners each. Week twelve ends on a Friday.

Monday: they export the pass list from their learner management system, with name, email, award and completion date, and send it over. 174 passed. Six are pending a resubmission. Getting a pass list into that condition is most of the work on their side, and all of it happens before anything is issued.

Tuesday: 174 certificates are generated against the template set up before the first intake, each signed, each with its own verification page. The provider reviews a sample before anything is sent, because generating and sending are separate steps.

Wednesday: emails go out. Three learners reply about spellings. Each is corrected the same day, and because the verification URL is derived from the credential rather than its contents, the links already sitting in those three inboxes keep working and now show the corrected details.

Over the following six weeks: five of the six pending learners resubmit and pass. Each is issued on their own, one at a time, using the same process rather than an exception to it.

Fourteen months later: an employer wants to confirm one of them. They open the link on the candidate's CV and see the answer. Nobody at the provider is involved, and nobody at the provider finds out it happened.

The last step is the one that compounds. Credential verification covers what that employer sees, and editing issued certificates covers the Wednesday.

Whose name goes on it

Many providers deliver somebody else's curriculum: a partner's syllabus, a vendor's programme, an international body's course. Who issues the certificate is a more consequential question than it looks.

Here, the issuing organisation is a first-class thing rather than a line of text on a template. It holds its own signing key, and every credential is signed with the key of the organisation that issued it. A provider issuing under its own name and also under a partner's arrangement is two issuers, and a credential can be checked back to whichever one actually awarded it.

That matters when a partnership ends. Credentials issued under it stay valid and stay verifiable, because verification is a check against a published key rather than a lookup against a live relationship. Digital signature explains why that holds.

Badges for the parts that are not a whole programme

Providers often run short workshops, single modules, and stages inside a longer track. Issuing a full certificate for a two-day workshop overstates it, and learners know the difference. Digital badges are the right size for those, and keeping the certificate for the whole programme is what keeps the certificate meaning something.

Both are issued the same way and verified the same way, so using both is not two systems.

Frequently asked questions

We run several cohorts a year. Is each one a separate setup?: No. The template is set up once, per award. After that a cohort is a recipient list: you send it, we run it, and every learner gets their certificate and their verification page. The tenth intake costs the same effort as the second.
What do you need from us to issue a cohort?: A list with each learner's name and email address, the award they earned, and the issue date. That is the whole requirement. Most providers already hold this in their learner management system or a spreadsheet, and exporting it is usually a five-minute job.
What happens when a learner resits and passes later?: They are issued when they pass, not when their cohort passes. Late completions, resits, and deferred learners are ordinary single-recipient issuances rather than an exception the process cannot handle.
Employers keep asking us to confirm old certificates. Does this stop that?: It is the main reason providers move. Each credential has a permanent page an employer can open themselves, so verification stops arriving as email your team has to answer. Certificates you issued before joining can be brought across and issued as verifiable credentials retrospectively.
Do you support certificates that expire?: Awards can carry an expiration period, which is recorded against the award and shown on the credential. What we do not currently do is notify you or the learner automatically when that date passes, so if renewal reminders are central to your programme, plan on running those from your own system for now.

Start with your next cohort

Send us the list from your last intake and we will issue a handful as a sample, so you can see the emails, the credential pages, and the verification result before committing to anything.

Request a Demo