Sheet BEA-04 — ITSM Manual
Tenant Setup & Onboarding
First-run setup for a new Beacon tenant: what ships ready, what the administrator must decide, and how to reach an operable workspace.
Scope
A new tenant arrives with sensible defaults, but a few decisions belong to the administrator. This guide keeps the first-run operating model and removes private platform detail.
Audience: the administrator who has just been given a new Beacon tenant.
Where: the relevant workflow — “First-run setup”, the first section in the
Administration console’s Service Management group. Visiting bare the relevant workflow
takes you there automatically until setup is finished.
Permission: admin.setup.view to read it, admin.setup.manage to record
progress. Both are included in the Beacon Administrator role.
What Beacon has already done for you
Beacon is not a blank product. The moment your tenant was created it seeded a working service desk:
| Area | What was created |
|---|---|
| Organization | One default organization, named after your tenant |
| Categories | A 7-branch category tree (Hardware, Software, Network, Access & Identity, Email & Collaboration, Service Request, Other) with 25 subcategories |
| Assignment groups | Service Desk, Change Advisory Board, Engineering |
| SLA | Four priority-keyed policies (P1–P4) plus a business-hours fallback, and two recurring public holidays |
| Priority | The conventional 4×4 impact × urgency matrix |
| Service catalog | A “Common Requests” category with five offerings (Password Reset, New Laptop, Software Access Request, New User Onboarding, VPN Access) |
| Escalation | A two-stage default policy, a weekly “Primary on-call” rotation shell, and five starter escalation checklists |
| Change | Five governance templates, an example (inactive) year-end freeze |
| Major incident | A default policy that auto-declares at P1 with a 30-minute comms cadence |
| Automation | Three default-on hygiene journeys, the chat intent map, hold reasons, resolution codes, three system saved views |
Your job is to review this, not to retype it. Every setup step shows what is already configured and lets you accept it in one click, or jump straight into the real admin section to change it.
The one thing Beacon will not do for you
Beacon never invents a person. The seeded Service Desk group has no members, and the seeded Primary on-call rotation has no participants — because the first person to log in to a new tenant might be a requester, and guessing a human into a paging path is worse than an empty one.
That is why a brand-new tenant is configured but not yet operable, and why the wizard says so on the very first screen rather than letting you discover it when an escalation quietly reaches nobody.
The six steps
Work through them in order; you can open any of them at any time, and you can leave halfway and come back — Beacon remembers exactly where you got to.
-
Organization and identity — confirm the default organization is named the way your users would recognise it, and decide whether you are running one organization or several (branding and terminology live here too).
-
Teams, agents and escalation — the step that actually needs you. Put at least one person in a group; add participants to the on-call rotation if you page out of hours; review the escalation policy and the starter escalation checklists.
-
Service level promises — the response and resolution clocks Beacon shows requesters, and the business calendar they run against. Review the numbers before they become a promise you are measured on, and add the public holidays your desk does not work.
-
Service catalog — keep the seeded offerings that match services you actually provide, retire the rest, and check each one has a fulfilment group.
-
Front doors — how work reaches you. The requester portal is always on. Microsoft Teams and inbound email are optional and off until you connect them.
-
Integrations — API keys, outbound webhooks, paging channels (PagerDuty/OpsGenie) and automation providers. None of these stop the desk from running; review them and move on if you have nothing to connect yet.
Accepting versus customizing
Each step offers two ways to finish it, and they mean different things:
- Accept these defaults — “what Beacon seeded is right for us.”
- I have customized this — “I went into the section and changed it.”
Both are recorded in the audit log with your name and the time, because “who reviewed the SLA promises?” is a question an auditor is entitled to ask, and accepting a default changes nothing in the settings tables that would otherwise answer it.
Clicking Customize in just takes you to that section. It records nothing — walking into a room is not a statement that you changed the furniture. Come back and pick one of the two buttons when you have.
Review again reopens a step you already resolved.
“Is this workspace operable?”
The panel at the top of the wizard answers that, and it is computed from your live configuration every time you open the page — not from how many steps you have ticked. Five rules:
| Rule | Why it matters |
|---|---|
| A default organization exists | Intake files a ticket from an unrecognised requester against it. Without one, portal and email intake have nowhere to put the ticket |
| At least one assignment group has a member Beacon can verify | Assignment, auto-assignment and group routing all pick from group membership. An empty group is a queue nobody is in — and a member the Portal directory cannot match is counted as nobody, not as staffing (add members by picking them from the directory) |
| Escalation reaches a real target | A stage pointing at an empty group escalates successfully and notifies nobody |
| A fallback SLA policy is marked default | A ticket whose priority matches no policy would otherwise carry no clock at all — and the promise Beacon shows the requester is silence |
| At least one catalog offering is published | Without one, the portal can only take issue reports and half the service-request practice is unreachable |
Two consequences worth knowing:
-
You cannot click your way to “operable”. Accepting all six steps while nobody is in a group leaves the verdict unchanged, and the wizard keeps saying why.
-
Operability can be lost again. Remove the last member from your only staffed group and the next visit reports the workspace as not operable. This is intentional: the verdict describes your configuration today, not the day you signed it off.
Stopping the prompts
Stop prompting me silences the landing redirect — bare the relevant workflow will go to your usual first section instead of the wizard. It does not mark anything as done, and every unmet readiness rule keeps reporting unmet whenever you open the wizard. The dismissal is recorded with your name; Prompt me again reverses it.
Once every step is resolved and every readiness rule is met, the wizard stops prompting on its own and records the date the workspace became operable.
Escalation checklists
New in this release: your tenant ships with five starter escalation checklists — a tenant-wide default plus one each for Hardware, Software, Network and Access & Identity. They are what an agent is asked to confirm they have already tried when they escalate a ticket, and the answers travel with the handoff to L2/L3.
Edit them at the relevant workflow. If you delete them, Beacon will not put them back on your next login — a checklist you deliberately removed stays removed.
Related
readiness rules and the API