Manage an executive question backlog without creating a second inbox

Decision support

Key takeaways

• Capture plain-language question, requesting owner, decision needed, evidence link, latest useful answer time, consequence, and proposed disposition.
• Apply one control: remove updates and tasks from the queue so every remaining item can receive an answer.
• Escalate when a question becomes urgent, loses its owner, depends on missing specialist review, or expires before the next session.

Operating data

Playbook

Decision support becomes fragile when a tidy queue conceals unresolved authority. Manage an executive question backlog without creating a second inbox addresses that weakness by making the operating record answer one question at a time. Its purpose is to batch nonurgent questions while preserving context, owners, expiry conditions, and a path for true exceptions and show where coordination ends.

Decision support review point 2. The backlog earns its place only when it lowers interruption without hiding decisions. A question about wording for next month's internal note can wait for a review block; a same-day customer safety issue cannot. The record makes that distinction visible and reversible. This is the article's working unit. It is specific enough to test against a real request and narrow enough for an assistant to maintain without absorbing another team's professional responsibilities.

Decision support review point 3. Start the intake with plain-language question, requesting owner, decision needed, evidence link, latest useful answer time, consequence, and proposed disposition. Do not fill an empty field with a guess simply to make the record look finished. Mark what is unknown, name the person who can establish it, and decide whether work may continue safely while that answer is pending.

Decision support review point 4. The central control is straightforward: remove updates and tasks from the queue so every remaining item can receive an answer. Put that rule beside the work, where the coordinator can use it during triage. A policy stored in a distant manual will not help when a sender is waiting and the assistant has to choose between routing, holding, or asking one more question.

Decision support review point 5. Authority needs its own sentence because a checklist cannot grant it: the assistant edits for completeness and routes answers but cannot turn personal preference into executive policy. Access to an inbox, calendar, document folder, or vendor portal is technical capability, not permission to make every decision the tool permits. The record should identify the accountable role rather than relying on familiarity or urgency.

Decision support review point 6. Build an exception lane before the first difficult case. Escalate when a question becomes urgent, loses its owner, depends on missing specialist review, or expires before the next session. The escalation should state the observed fact, its source, the affected deadline, the decision required, and the consequence of waiting. It should not bury the question inside a long status summary or imply a recommendation from evidence that does not support one.

Decision support review point 7. A clean status vocabulary prevents false completion. Use labels that describe the current condition, such as awaiting source, ready for owner review, approved with conditions, scheduled, communicated, or closed with evidence. Define what closes the record. A sent message may start a handoff, but it rarely proves that the recipient understood or completed it.

Decision support review point 8. Keep the source trail proportionate to the risk. Save the stable identifier, responsible owner, effective date, and link to the controlled record. Avoid copying confidential material into a convenience tracker when a permissioned link will do. If a temporary copy is necessary, give it a removal trigger and confirm disposal after the handoff.

Decision support review point 9. The Asana guidance on managing work requests is a useful external reference for this operating area. It does not replace the organization's own contracts, policies, security requirements, or professional advice. The assistant can flag a mismatch between the reference and the working instruction, then route that mismatch to the owner who can resolve it.

Decision support review point 10. Connect the routine to the relevant executive support lane so intake and follow-through use the same ownership model. This matters when one request touches several functions. The assistant can maintain the connecting record while finance, legal, security, human resources, or another specialist answers the part that belongs to its domain.

Decision support review point 11. Review performance through questions answered, delegated, withdrawn, expired, escalated, and returned for evidence. Counts alone need context. A rise in held requests may show stronger controls, worse intake, or a new external risk. Sample the underlying records, ask why the exception occurred, and change only the field, threshold, or routing rule that would have improved that decision.

Decision support review point 12. The first review should happen after a handful of real cases, not after months of accumulating friction. Look for fields people cannot answer, handoffs with two apparent owners, and closure labels that lack evidence. Remove unused complexity, but retain distinctions that protect authority, privacy, security, or a consequential deadline.

Decision support review point 13. When the workflow is stable, document a short coverage note for another trained coordinator. Include where requests arrive, when the queue is checked, which conditions interrupt the normal cadence, who owns each escalation, and how closure is verified. Coverage should preserve the control rather than depend on one assistant's memory.

Decision support review point 14. A good decision support system makes restraint visible. It shows what the assistant handled, what remained with the executive, what a specialist had to verify, and what the team deliberately chose to leave pending. That record helps the next operator continue the work without pretending uncertainty has disappeared.

Decision support review point 15. Teams that need to adapt the routine can request a tailored support plan. Bring one recent example with sensitive details removed. Mapping the actual handoffs, decision points, and failure conditions will produce a better operating design than adding a generic template to another shared folder.

Question types include factual confirmation, preference, approval, exception, prioritization, interpretation, introduction consent, scheduling tradeoff, draft review, risk acceptance, resource allocation, and policy direction. Tagging by type can expose items that never needed executive judgment. Add expiry dates for invitations, offers, quotes, holds, and time-sensitive wording. Link dependent questions so an answer does not arrive out of sequence. Archive duplicates while preserving the original requester. Measure interruption avoided, but also watch for decisions delayed because batching became a rigid ritual.

Decision support review point 17. Test a question before admission. Can it be answered yes or no, by selecting an option, supplying a missing fact, or naming a tradeoff? Does it identify requester, useful-by time, affected work, default outcome, evidence, and recommendation owner? Status updates belong elsewhere. Multi-part strategy discussions need a briefing or meeting. Personal data, investigations, legal advice, and security incidents use restricted channels. This admission rule keeps the backlog answerable and prevents a convenience list from becoming an uncontrolled archive.

Decision support review point 18. Review the queue in a fixed order: expired questions, items whose consequences changed, questions ready for an answer, and records still missing evidence. This prevents the oldest item from automatically outranking the most consequential one. When an executive answers verbally, the assistant reads back the decision, conditions, owner, and effective time before recording it. If the answer creates a broader rule, route that policy work separately. One response to one situation should not silently become standing authority for every similar future request.