Draft a client-ready instruction block for the moment after shared-mailbox access is granted: how it
actually shows up, on which device, and how long that takes — because "you now have access" without
the how is just a slower ticket. Verify access state and environment before you write; when unsure,
ask. Draft only — show me the reply as a draft to review first, and don't send it.
1. Verify access state and environment FIRST. From the ticket: has the grant
actually been completed, and to which mailbox (display name only)? From client docs: which Outlook flavors the user runs and whether the user
also has send-as/send-on-behalf rights — that changes what you promise. If the grant isn't
confirmed done, do NOT send this guide; tell the tech the fulfillment step is still open. If the
flavor is unknown, cover web (works everywhere) plus ONE desktop flavor confirmed from the ticket
— not all five.
2. Write the matching paths, to end-user rules, one action per step with what-you'll-see cues:
- The patience preamble (this kills most callbacks): "In desktop Outlook the mailbox usually
appears by itself in the folder list on the left, under your own folders — but it can take up to
a few hours after access is granted. If it's not there yet, that's normal."
- Web path (the immediate-gratification route): sign in to webmail, right-click their own name in
the folder list, choose add/open shared folder (cue: "a box asks for a name — type <mailbox
display name> and pick it from the list"), and where it appears.
- Desktop path: mostly "wait for it to appear, then restart Outlook once if it hasn't" — manual-add
steps only for the confirmed flavor, version-cautious.
- Sending as the mailbox (ONLY if the grant includes it): the From-field cue ("when writing an
email, look for the From button; choose <mailbox display name> so the reply comes from the team
address, not your own"), and the first-time note that the From button may need enabling from the
options menu.
- Off-ramps: "If it hasn't appeared anywhere by tomorrow morning, reply here." / "If you can read
the mailbox but sending is rejected, stop and reply — that's a separate permission on our side."
3. Assemble per the Email Baseline Standard.
Guardrails: never send this guide before the grant is confirmed complete — instructions for access
that doesn't exist yet manufacture a "your steps don't work" reply. Promise send-as only when the
ticket/grant confirms it; reading and sending are separate permissions and conflating them is the #1
follow-up ticket. The propagation-delay expectation appears in every draft. No admin steps (adding
members, mailbox permissions, automapping) in the user block. Refer to the mailbox by display name
only; no addresses of uninvolved mailboxes, no permission-holder lists. Localizable. Docs tools
exist only when enabled.
Magic Library