SimplBrain
What should an employee assistant do when the source is unavailable?
SimplSolutions editorial team · 3 min read
Published
Missing evidence changes the answer
An assistant that normally explains the company procedure may lose access to that source. The useful response is not automatically a generic version of what companies usually do. If the source governs the action, missing it is a material limitation.
Write the expected failure response before testing. It should identify that the approved guidance cannot currently be verified and direct the employee to an appropriate person or permitted source. It should not imply that the task was completed or that the usual rule can safely be guessed.
Distinguish three failures
| Gap | Who investigates | What should remain visible |
|---|---|---|
| Source unavailable | Access or connection owner | The source cannot currently be verified |
| Question outside coverage | Knowledge owner | No approved rule answers this question |
| Approved sources conflict | Authorized process owner | The conflicting rule needs a decision |
These need different repairs. Record the affected employee question, source version and observed limitation so the receiving person can investigate the actual failure.
If every failure becomes contact IT, the operational owner never sees missing policy. If every failure becomes ask your manager, a broken connection can remain invisible. Make the handoff fit the actual gap.
Agree any fallback explicitly
A fallback can be a separately approved reference, a manual source lookup or a hold pending review. It cannot silently become the oldest cached file just because that file is convenient. Record the fallback's owner, version, audience and limits.
For a fictional supplier request, the safe fallback may be to give the purchasing coordinator's public internal contact and say the current procedure cannot be verified. That does not authorize an order or promise an approval date. Keep the message short enough for an employee to act on.
Exercise the failure, not only the happy path
Ask the known supported question while the controlled test source is unavailable. Inspect the answer, citations and proposed action. Then restore the source and repeat the same question. Verify that the recovered answer uses the intended current version.
Include an access denial in a separate test. A person without permission should not be given a technical recovery path that exposes restricted material. Operational resilience and authorization are separate acceptance concerns.
Name who accepts the unresolved question
A handoff should identify the problem, useful context, responsible recipient and next action. It is not accepted merely because a message was prepared. Define how the receiving team knows it owns the follow-up and what happens when the usual owner is unavailable.
Do not tell the employee a ticket exists unless the implemented workflow actually created one and returned a receipt. Explaining where to contact support, preparing a request and submitting it are different states.
Measure limitations honestly
Count unavailable-source events, unsupported questions, conflicts, time to repair and unresolved handoffs. Keep them separate from successful answers. A system that hides its failures may appear productive while sending downstream teams more ambiguous work.
Review the knowledge problems page and add one outage case to the acceptance sheet. Request a demo that includes loss and recovery of a synthetic source. A useful assistant should remain honest when the material that made its answer useful is missing.
