Weekly Job Intelligence: Who owns the exception?

Imagine arriving at a pharmacy counter with a code sent to your phone. The code should unlock a service. The connection is weak. The pharmacist sees a warning. What happens next?

That moment appears in Girl Effect's current WAZZII request for proposals (opens in a new tab). The organization is seeking a partner to design and build a service-navigation platform for girls and young women in Kenya. Its proposed code-redemption flow includes generation, delivery, validation, reconciliation and controls against reuse. The brief also calls for a service blueprint of the pharmacy-counter moment, safeguarding escalation paths, accessibility checks and low-bandwidth QA.

These are proposed requirements in a tender, not features I can claim are live. AI functionality is explicitly outside this contract. What makes the document useful here is the way it refuses to treat the screen or code as the whole service.

The hard part is the handoff

If a code cannot be validated, the software may display an error. That does not answer the girl's question, protect her privacy or tell the person at the counter what they are allowed to do. A workable design has to identify the authoritative record, the allowable alternatives, the person who can make an exception, and the evidence that must remain afterward.

Girl Effect asks for journey maps that stay current as the build evolves and for escalation designs approved with its safeguarding team. Each feature cluster needs an approved requirements pack and acceptance criteria before development begins. Design QA covers each girl-facing release, including accessibility and low-bandwidth performance. Those are explicit procurement requirements (opens in a new tab), not an independent assessment of the eventual implementation.

This is a sharper test of workflow design than a polished happy-path prototype. Can the service still be used when the signal drops, the record is wrong, the code has expired or a sensitive situation needs a human? Which of those cases should the software resolve, and which must it return to an accountable person? The answers change the requirements, the interface, the operational training and the acceptance tests.

More capable software raises the same question

The tender is a non-AI example. Separately, AI vendors are describing systems that carry more work across existing enterprise processes. ServiceNow's November 5 Brazil release (opens in a new tab) says its tools can take on more of the development process, while developers remain responsible for architecture, quality and production readiness. OpenAI's November 4 Enterprise and Edu notes (opens in a new tab) describe controls for workspace administrators to manage access, connections, activity and pausing for personal dots.

Those are vendor statements about products and controls. They do not establish adoption or measured customer benefit. They do, however, make the design question more concrete: as a system can act across more steps, someone must say what it may access, when it must stop, who reviews a result and what constitutes an acceptable handoff.

The capability is broader than prompt writing. It joins service design, information architecture, operations, technical implementation and governance. No one discipline can simply hand the exception away. The WAZZII tender itself seeks a partner with engineering, security and support capacity alongside service design; it is not evidence that a single designer can deliver the whole service.

Practice on one exception

Take a consequential workflow you know. Choose a real exception: an expired code, a mismatched record, an incomplete application or a request outside policy. Write a short test case with these parts:

1. The normal result: what should happen when the source, permission and conditions are valid?
2. The exception: what observable fact changes the path?
3. The owner: who may decide, and what must the system refuse to decide on its own?
4. The recovery: what can the person safely do next, especially with poor connectivity or incomplete information?
5. The record: what evidence allows the organization to review and correct the decision later?

Ask an operator and an engineer to read it separately. If they disagree about the source, authority or acceptable result, the disagreement is useful work to resolve before building. It may change the interface, the rule, the training or the scope. A diagram alone will not settle it.

What changed this week

The broad labor picture also moved. The Bureau of Labor Statistics reported (opens in a new tab) 165,000 additional U.S. payroll jobs in October, including 70,000 in professional and business services; unemployment was 4.1%. September job openings and hires (opens in a new tab) were little changed. Those figures correct last week's pending-data account, but neither dataset measures demand for workflow consulting or proves that a particular role is opening up.

The more useful signal for this issue is a specific work requirement. A buyer has put service journeys, exception ownership, acceptance criteria, engineering and support in one procurement brief. AI vendors are adding capabilities and controls that make those same decisions harder to ignore. The next skill is to make one exception testable, then let the people who will live with the result challenge the design.

Which exception in your work looks minor on a screen but changes what a person must do? I would be interested in the detail that made the original process map incomplete.