Our badge issuance system was technically perfect

I spent a significant amount of time troubleshooting a "broken" credential system at Isovalent Labs, only to realize the entire problem was a psychological gap rather than a technical bug. We had users constantly complaining that they hadn't received their badges after finishing our hands-on labs. Some people were even completing the same lab two or three times, clearly thinking that a repeat attempt would "trigger" the badge to finally appear on the screen.

On paper, our AI-driven training workflow and deployment pipeline were flawless. The technical sequence looked like this:

1. The learner completes the lab via Instruqt.
2. Instruqt fires an asynchronous webhook to our platform.
3. Our platform catches the event and pings Credly to issue the credential.
4. Credly sends an email to the learner with a claim link.

Every single API call was returning a 200 OK. The webhooks were firing, the services were communicating, and the badges were indeed being issued. The issue was that because the webhook is asynchronous, it often arrived after the lab session ended. By the time the backend finished its work, the user had already closed the UI, and there was no link on the final screen to click.

The "obvious" engineering fix would have been to rewrite the entire orchestration to be synchronous or to build a custom notification layer. But instead, I decided to apply a bit of Theory of Constraints to our enablement workflow.

I started tracking two specific metrics: the volume of "missing badge" support tickets and the rate of redundant lab completions. Once I had that baseline, I ran a very simple experiment. I didn't touch a single line of code. I didn't deploy a new microservice. Instead, I just added a single instructional slide right before the final exam. It explicitly stated: "Congratulations! Once you pass, look for an email from Credly to claim your digital badge."

The results were immediate. Support complaints plummeted, and the unnecessary repeat attempts almost vanished. We solved a "technical" problem with better prompt engineering for the human user.

The difference between issuance and utility

In technical enablement, we often make the mistake of defining success by the moment a process completes in our database. We see a "success" flag in the logs and assume the job is done. But a credential isn't just a row in a SQL table; it’s a piece of portable evidence.

If we look at the real-world lifecycle of a credential, it follows this path:

complete
→ issue
→ notify
→ claim
→ use or share

If you stop caring at the "issue" stage, you are essentially declaring a package delivered while it is still sitting in the warehouse. You might have fulfilled your side of the contract, but the customer hasn't received the value.

This is a massive lesson for anyone building LLM agents or automated workflows. We often focus heavily on the deployment and the output of the model, but we forget about the hand-off. The boundary of your technical control is not the same as your boundary of influence.

Even if you can't force a user to click "share" on LinkedIn, you can influence that action by ensuring they know exactly what to expect, when to expect it, and what the email will look like. If the artifact you produce is meaningful and the path to using it is friction-less, adoption happens naturally. Don't just build a system that works; build a system that communicates its own success.