Printer Connect Guide

Draft a client-ready instruction block for adding the office printer — written for how THIS client
delivers printers, because "add a printer" means something different in each setup. Verify the
delivery model before you write; when unsure, ask. Draft only — show me the reply as a draft to review first, and don't send it.

1. Identify the client's print delivery model FIRST by checking the client's documentation and past tickets: (a) printers auto-deploy to managed machines, (b) users
   add from a print server, (c) a cloud print platform with its own client/portal (Universal
   Print/Printix/PaperCut), or (d) small-office direct/wifi printers. Also pull the printer's
   documented friendly name for the user's location. If the model or printer name is unknown, ask
   the technician ONE question.
2. Write ONLY the matching branch, to end-user rules, one action per step with what-you'll-see cues:
   - Auto-deploy: keep it short — where printers appear (Settings → the printers list, phrased
     version-cautiously), "give it a few minutes after sign-in on the office network," and the
     off-ramp. Do not include manual-add steps that fight the deployment.
   - Print server: open the add-printer search, pick the documented printer by its exact friendly
     name ("choose the one called exactly <documented name> — names matter here"), wait for the
     driver cue ("your computer sets it up by itself; a test-page option appears when done"). Don't
     expose raw server paths unless docs show users add by path at this client.
   - Cloud print platform: the platform's user-side flow only (its portal/app, sign in with work
     credentials, select the printer for their floor), per docs.
   - Direct/wifi: must be on the office network first; add from the printers list; cue the name/model
     match.
   - Universal off-ramps: "If the printer isn't in the list, stop and reply with where you sit —
     we'll map it from our side." / "If you're asked for a driver, a file, or an admin password,
     stop and reply — you should never need those."
3. Include the success test: print a test page (where the flow offers it) or a one-page print, and
   what to do if it queues forever ("if it says 'printing' for more than a couple of minutes with
   nothing coming out, reply — don't print it five more times").
4. Assemble per the Email Baseline Standard.

Guardrails: never invent a printer name, share path, or IP address — docs or ask; a user adding a
guessed printer prints to the wrong floor for a month. Delivery-model match is mandatory —
manual-add steps on an auto-deploy client create duplicate broken queues. The don't-print-it-again
line stays in every draft. No admin steps (driver installs, server queue management, deployment
policy) in the user block. Localizable; Windows/Mac cue differences only if the client has both per
docs. The client's documentation is available only when those integrations are enabled.