Requester Portal

Scope

What requesters see and do in the portal, so agents and administrators know what the other side of a ticket looks like.

The Requester Portal, Get help (the relevant workflow; existing the relevant workflow links redirect here) is the zero-training help center for end users. The mandate is “a couple of clicks”: find what you need, answer at most a few fields, and submit — whether that’s requesting something from the catalog or reporting something broken.

The portal is white-label ready: when the tenant configures branding (Settings → Branding), the header shows their logo and display name instead of the Beacon mark, the browser title becomes {name} Help Center, the primary color follows their brand, and a support-email footer appears. Unbranded

Search from anywhere

The search box in the header is on every tab. Type two characters or more and it looks across your tickets and the help articles published for you, in one list, each result labelled with what it is. Pick a ticket and it opens on the My tickets tab; pick an article and it opens in the reader.

It only ever finds things you’re entitled to see: your own tickets — never anybody else’s, and that holds for an agent or administrator using the Help Center too, who finds only the tickets they raised here — and only articles your IT team has published for the portal. Internal runbooks and unfinished drafts are not in the results because they are not in the search at all.

Each tab still has its own box for filtering what’s in front of you: the catalog to whichever of those the current tab has, and to the header search on the tabs that don’t have one.

What do you need?

The landing tab is search-first. Type what you need and the catalog filters as you type. Each result card shows the offering, a one-line description, and a “Needs approval” badge where relevant. Selecting a card opens the request form. A prominent Something’s broken — report an issue card sits right on the landing tab, and if your search finds nothing, a Can’t find what you need? Report an issue button appears instead of a dead end. Before you’ve typed anything, an empty catalog says so plainly (“Nothing is available in the catalog right now.”) rather than reporting a search miss; type a query that matches nothing and the message says exactly that instead (“Nothing matches ‘your search’.”). If your account doesn’t carry catalog access at all, the tab shows a “you don’t have access” message instead of trying (and failing) to load anything, and if the catalog fails to load, you’ll see a retry button rather than a blank or misleading “nothing here” screen.

Help articles

When you expand a report from an article, the article remains visible while the report form loads. A form loading failure stays within the report area so you can keep reading.

The Help articles tab is the published knowledge your IT team has written for you: search it, read it, and often solve the problem in less time than it takes to file a ticket.

• Type in the search box and results rank by relevance across the whole article — not just the title.

• The list pages 25 at a time with a “Showing X-Y of Z help articles” count and a page-size selector that remembers your choice.

• Open an article and you get the full text, when it was last updated, and Did this answer your question? Yes / No. That answer goes to the people who maintain the article — a “No” is more useful to them than silence.

• If the connection drops after you answer, Beacon keeps that exact Yes or No and shows Check whether it was recorded. It checks the original operation before offering Retry original Yes/No, so a lost success cannot count twice. The same recovery remains available after reload. If the article or your access is no longer available, Beacon keeps the original reference and does not submit a replacement vote automatically.

• If Beacon cannot confirm that it recorded an answer, it keeps the original choice visible with its check action and leaves the issue-reporting exit in place. Beacon does not claim the earlier answer was lost or saved.

• After an article opens successfully, the complete Report an issue form is already expanded below it. The article keeps keyboard focus, so you can read the answer before deciding whether to submit the report; opening the form is not a second decision. If the article cannot be read, Beacon does not open a report from an answer it could not establish you may see. The empty search state still offers Report an issue, so self-service never dead-ends you.

You only ever see articles your IT team has explicitly published for the portal. Internal runbooks, drafts, and retired articles are not in here and cannot be reached from the portal at all — not by search, not by suggestion, not by guessing a link.

If your account doesn’t have knowledge access, the tab isn’t shown at all rather than appearing and then failing.

Reporting an issue

One click opens the report form: What’s wrong? (one line) and optional Details. That’s it — impact/urgency matrices are not your problem. If you want, More options reveals a single plain-language urgency question (“I can wait” → “My whole team is blocked”). On submit you get your ticket number (e.g. INC-000123), you’re told straight away when we’ll reply (“We’ll reply by Mon 13 Jul at 15:00”), and you land directly on the ticket so you can watch progress. See When you’ll hear back below.

When you arrive from a successfully opened help article, that same durable form is already expanded on the article page. Submitting it opens the new ticket and keeps that requester record current while support works, so a public update or resolution appears without making you find the record again.

What you type is kept. The report form autosaves to your browser as you write it, so closing it by accident, dropping your phone, reloading, or being signed out mid-sentence doesn’t cost you the description. Open Report an issue again and it offers Resume draft / Discard — we never put text back without asking. It’s cleared as soon as the issue is filed (or as soon as an article answers it and you close the form without filing).

If the send is interrupted, keep the same saved report. Beacon keeps a separate recovery key with the exact issue you chose before it sends. The form will say that it could not confirm the result and offers Check current issue. That check can show the ticket already created, or say only that no committed receipt is visible yet; the latter is not proof the first send failed. You may retry that same saved issue. Do not edit it or start a new report merely because a response was lost. If this browser cannot retain that recovery key, it blocks sending and keeps your draft instead of risking a duplicate.

The urgency you chose, and what we did with it

Your ticket shows the urgency it’s actually being worked at — Critical, High, Moderate or Low — right under the reply-by promise.

Most desks set a ceiling on how urgent a report can be before a person has looked at it. If yours does and your answer was above it, your ticket says so in as many words: “You told us this is Critical. It’s logged at the level shown here while an agent confirms the final urgency — if they raise it, you’ll see it change.” Nothing about what you told us is discarded; an agent reviews it and can raise the urgency, and when they do, the ticket updates and the note disappears.

We show you this rather than quietly filing your Critical as a High and hoping you don’t notice. If the ceiling means your issue isn’t moving fast enough, reply on the ticket and say so — that reply goes to a person.

We check whether you’ve already told us

Before anything else, the form looks at your own tickets and, if one of them looks like the same problem, shows it under “You’ve already told us about something like this” — its number, its title and where it has got to. Click it to open it and add to the conversation there instead of starting a second one.

It only ever looks at tickets you raised. Nobody else’s tickets are searched, ranked, or shown here, and the panel cannot tell you whether anyone else’s exists.

If the problem really is a different one, ignore it and carry on — like the article suggestions below, it never blocks the form or changes the submit button. And if nothing of yours matches, no panel appears at all rather than a “no results” message you did not ask for.

We look for an answer while you type

As you describe the problem, the portal searches both the help articles and any known issues IT is already tracking, and shows “This might help:” with up to three matches — ranked together by how well each one matches what you typed, right inside the form.

• A known issue shows its workaround inline, right away — IT is already working on the underlying fix, and the workaround may unblock you now.

• A help article expands to read without losing anything you’ve typed, and Yes — this solved it closes the form with no ticket filed if it worked. You can always come back and report it if it returns.

• If neither answers it, just carry on and submit. Nothing here ever blocks the form, gates the submit button, or makes you confirm you read anything.

The article half of this is recorded, including the unflattering outcome. When we show you an article and you file a ticket anyway, that gets logged against that article so the team can see which of their answers aren’t working — see the self_service_deflection_rate metric in report a deflection number that only counts the wins. (A known issue has no separate article to log against, so it isn’t part of that metric — its existence is tracked as a problem record instead.)

When the team has declared a major incident, a banner tells you before you file (“We’re aware of an ongoing issue — you may not need to raise a ticket”) and the report form repeats the known issues so you can skip a duplicate — but you can always submit anyway with My issue is different — report it. When the team scoped the incident to a service you use, the banner also names it (e.g. Payroll) — service names are only shown to requesters in the affected organization (or to everyone when the service is tenant-wide).

If the banner says the major-incident status could not be checked, it is not saying the incident is over or that no incident is active. Select Retry to read the current status. If it says the rows were last confirmed earlier, those rows remain available as context while the latest read is unavailable; select Retry or Refresh before relying on them as current. A signed-in viewer only sees the active-incident status their current tickets.view access allows.

Submitting a request

Choose an offering to review its form in the same help workspace. Some cards show a small set of labelled options, such as laptop models. Choosing one opens the form with that choice filled in; you can change it before submitting. Nothing is requested until you select Submit. Cancel returns to the offering you selected and keeps your unfinished draft.

The form is generated from the catalog item — you only see the fields that item asks for (text, long text, dropdowns, dates, checkboxes). Required fields are marked; the portal validates before it lets you submit. If the item needs approval, a note tells you so. On submit you get a request number (e.g. SR-000123) and land on My tickets.

Choose who the request is for when your access spans customers. A catalog offering that belongs to one customer uses that customer automatically. A tenant-wide offering also needs no question when your account has one available customer. If you can file it for several customers, the form asks Who is this request for? Search the server-backed list, page through it, and choose one before submitting. The list shows only names you may currently use and never loads an unbounded admin directory. If the list fails, the form keeps every answer and offers Retry; it does not treat the failure as an empty list or send without a confirmed owner.

You’re told the timescale before you ask, not after. Where your IT team has published one, each catalog card carries an estimate — Typically ready by Thu 16 Jul — and the request form repeats it. The estimate counts working days on your service desk’s own calendar, so weekends and their holidays are skipped rather than quietly counted against it. Where the item needs approval, the estimate says Typically 3 working days after approval instead of naming a day: nobody can start work until it’s approved, so a date would be a guess. If no estimate has been published for an offering, you’ll see nothing there — we’d rather show nothing than imply a timescale nobody set.

Long forms are drafted for you. Whatever you have filled in on a request form is autosaved to your browser, per catalog item, so a reload or a mis-tap part-way through a twenty-field form doesn’t send you back to the start. Reopening the same item offers Resume draft / Discard; the draft is cleared only after Beacon confirms the request.

If the send is interrupted, keep the same saved request. Beacon saves a recovery key with the completed form and chosen organization before it sends. That organization is frozen with the saved request and cannot be changed while its outcome is uncertain. It remains named after reload even when it is outside the current search page. If current access or the organization itself changes, keep the original saved request; do not choose another customer under the same recovery key. Use Check current request even while the choice list is temporarily unavailable to find the request already created, or to learn only that no committed receipt is visible yet. That observation does not prove the earlier send failed; retry the same saved request rather than changing it. If this browser cannot store the recovery key, Beacon leaves the form in place and does not send a request it could not safely recover.

Where your request is up to

Open any request and a progress strip shows exactly where it has got to: Submitted → Approved → Being worked on → Ready, with the stage you’re actually at highlighted and a line saying what it means (“Waiting for a decision. Nothing can start until this is approved.”).

The strip only ever shows stages your request genuinely passes through. A request that needs no approval doesn’t show an Approved step at all — a step that could never complete would look like you were stuck waiting for a manager who was never asked. A request that was rejected or cancelled stops on the strip rather than pretending it’s still moving.

Expected by. Once your request is actually cleared to be worked on — the moment you submit it if it needs no approval, or the moment it’s approved if it does — the estimate becomes a real date, and Expected by Thu 16 Jul appears on the request and on its card in My tickets. That date is fixed at that moment: if your IT team later changes the published estimate for that offering, your date does not silently move. Until it’s bound you see what it depends on (Expected within 3 working days of approval) rather than a date nobody has committed to.

And we tell you if we miss it. When the request is delivered, it says whether we hit the date: “Delivered by Thu 16 Jul, as promised.” — or, when we didn’t, “This took longer than the Thu 16 Jul we promised you — we’re sorry.” A late delivery is never quietly filed under “Done”.

My tickets

One list for everything you’ve raised — issues and requests together, newest activity first, each with a type chip (Issue / Request) and a plain-language status. It is always your list: it includes tickets an agent logged on your behalf, and it never shows anyone else’s — that holds even for an agent or administrator who opens the Help Center, who sees only the tickets they themselves raised here, not the team’s queue. Statuses: We’ve received it, We’re working on it, Waiting for you, Awaiting approval (with an approvals count), Resolved — did this fix it?, and so on.

The list shows 25 tickets a page, with Previous/Next, a rows-per-page choice of 10/25/50/100 that Beacon remembers for you, and a “Showing X-Y of Z tickets” line so you always know how much history there is. Paging happens on the server, so nothing is quietly left out no matter how long you’ve been raising tickets — the whole history is reachable.

Open any ticket to see its story: when you reported it, status milestones in plain language, and the conversation — the team’s public replies and your own. Internal work notes are never shown. A reply box sits at the bottom; type and send, done. A reply you have started is autosaved per ticket, so you can come back to it later or after a reload — the ticket offers Resume draft / Discard and clears the draft once the reply and its file work are confirmed. Before a reply leaves, Beacon saves its exact words, known upload IDs and a recovery reference. If the response is lost, use Check current reply rather than sending it again. Retry original reply is offered only after the receipt read returns no visible result; the first request may still complete, so it uses that same saved reply and reference. If support merged the ticket, Beacon names the current ticket and requester and asks you to approve that destination before it continues file recovery.

Each card and ticket also states the recorded owner when Beacon has a requester-safe assignment name. This is the assignment recorded on the ticket, not a promise that the person or team is currently available or has acknowledged the work. If no assignment has been recorded, its public label is unavailable, or the old assignment is no longer available, Beacon says exactly that instead of exposing an internal team name or inventing progress.

For a request waiting on approval, the ticket shows only the recorded current approval progress: named eligible approvers where those names are safe to show, the stage and approvals needed when available, and an honest unavailable or no-access state when that projection cannot be read. A stalled, missing, unapplied, or inconsistent approval record asks for approval administrator review. You can still add a public reply to the ticket while that record is being reconciled; Beacon does not claim that this routes work to a specific person or changes the approval.

If Beacon cannot open one ticket, it says so with Retry and Close rather than leaving a spinner behind. If the ticket opens but its public timeline or reply history cannot be read, the ticket stays visible and each failed stream names the problem with its own retry control; an unavailable conversation is never shown as though nobody has replied.

When the list can’t load

An empty list means one thing only: you have not raised anything yet — and it now comes with a Report an issue button so it isn’t a dead end.

If Beacon cannot reach your tickets, it says so and offers Retry. It will never tell you that you have no tickets when the truth is that it could not check. The same applies to the approval badges on the list: if those cannot be read, you are told, rather than the badges quietly disappearing.

If you do not have permission to view tickets, Beacon says that too, and names the permission to ask an administrator for — instead of showing you an empty list.

When you’ll hear back

Beacon tells you what it promised you, and tells you when it broke that promise. No timing information is withheld because it’s unflattering.

Open a ticket to see the policy behind its commitment and why that policy applies. If assessment is unavailable or delayed, the recorded target stays visible beside the uncertainty message; it is not presented as a confirmed forecast. Its response and restoration deadlines name the policy’s timezone and the offset on that date. If the policy timezone is unavailable, Beacon labels the displayed time as a UTC fallback. Changes to policy configuration do not silently replace the promise already recorded on your ticket.

If no restoration deadline is recorded, the ticket says that no restoration estimate is available. That alone does not mean a promise was missed. If Beacon has recorded a missed commitment but its deadline is unavailable, it preserves that history without inventing a date. You can ask for an updated estimate in a public reply on the ticket.

The moment you submit, a notification lands in your bell (and your inbox): “We got it — INC-000123. We’ve logged ‘Email is down’. You’ll hear from us by Mon 13 Jul at 15:00 (Europe/London).” That time is your organization’s agreed response target for a ticket like yours, shown on the service desk’s own clock. If your organization has no agreed target, we say that plainly instead — “We’ll get back to you as soon as we can.” — rather than inventing a deadline. Your IT team can reword this message (including per client organization), but not the timings behind it.

On every ticket — in the My-tickets list and at the top of the ticket itself — you then see where that promise stands, updating live:

What you see	What it means
Response due in 1h 40m	We haven’t replied yet; this is how long we have left. The ticket also shows the exact time we’re aiming for.
Fix due in 3h 20m	We’ve replied and we’re working; this counts down to the fix-by target.
We’re aiming to have this fixed by Mon 13 Jul at 19:00.	The resolution commitment, shown once work is under way.
Waiting on you — reply to resume	We need something from you. The clock is paused and restarts the moment you answer — the wait doesn’t eat your time budget.
On hold — awaiting vendor	Paused for a reason that isn’t yours to fix. You don’t need to do anything.
We missed our response target	We were late replying. We say so.
We missed our fix-by target — escalated	We were late fixing it and the ticket has been escalated to the next level of support. The “— escalated” part only appears when it genuinely has been.
Past our response target	We’re over the line right now, before anything has formally been logged as a miss. Shown immediately rather than letting a countdown run past zero.
Closed — but we missed our target	The ticket is done, and we’re not quietly dropping the fact that it was late.
Closed within the time we promised	Done, on time — and somebody did reply to you along the way.
Resolved before we needed to reply	Done, on time, but nobody wrote to you separately: we promised a reply by a deadline and finished the work before that deadline instead. Nothing was missed. We say this rather than claiming we met a reply commitment you can go looking for and not find.

If no service target applies to your ticket, you’ll see no countdown at all — we’d rather show nothing than a promise nobody made.

If a service target applies but its service hours are misconfigured (for example, no working days are set), you’ll see No due date: SLA calendar never opens and a sentence saying we cannot calculate a target time for your ticket. Your ticket is still being handled; the timing appears once the service hours are fixed. We show this instead of a made-up date.

What we did

When your incident or request has a recorded resolution and is resolved or closed, a What we did panel sits on it, above the reopen and rating buttons. It carries two things the team recorded when they finished: the resolution in your organization’s own words (“Fixed”, “Workaround applied”, “Known error”, whatever your IT team calls it) and the notes the person who fixed it wrote — “Reissued the wifi certificate on your laptop and rejoined the corp SSID”, not a code.

If a resolution was recorded without notes, the panel says exactly that rather than staying blank, because “no note was left” is information too, and it is your cue to reopen the ticket and ask.

You also get this by notification the moment the ticket resolves, before the request to rate it — including if you only ever deal with us by email and have never signed in to the portal. Being asked “how did we do?” about work nobody described to you is a question with no honest answer, so the account of what happened always goes first.

The same words appear on the ticket’s own timeline, next to the point where the status changed, so scrolling back through a long ticket shows you what was tried and what finally worked.

A reopened ticket drops it. If you reopen, the resolution comes off the ticket — it would be untrue to keep showing “Fixed” on a ticket you have just told us isn’t fixed. The history isn’t lost: the timeline records “Reopened. Previously resolved as Fixed — “, and the team sees the same, so whoever picks it up knows what has already been tried.

Confirming the outcome

After reviewing What we did, use Yes, this is resolved to record that the current outcome works for you. This is separate from your rating. If support must still close the ticket or complete workflow requirements, your confirmation stays recorded and the page explains what remains. Only an already permitted, unambiguous closure can happen with your confirmation.

A direct close without a recorded resolution, cancellation or rejection does not ask you to confirm a fix. If support changes the resolution or the ticket returns to active work, review the new outcome before confirming again. The previous decision and resolution remain in history.

If the result is uncertain, the page preserves the exact resolution decision. Use Check saved confirmation before retrying; Beacon reads the recorded cycle and requester without sending another confirmation. If confirmation succeeded but refreshing the ticket failed, retry the refresh; the recorded decision does not need to be submitted again.

Reopening a ticket

When a ticket says Resolved — did this fix it? (or a request says Done) and it isn’t actually fixed, choose It’s not fixed for the direct factual decision. Choose Add recurrence details when support needs to know what happened again; enter that evidence and choose Reopen incident. Both paths put the ticket straight back into work and notify the assignee automatically. Resolved tickets can be reopened at any time; closed tickets only within your organization’s reopen window (after that the portal tells you to raise a new ticket).

Beacon saves the exact displayed resolution cycle and reason before it sends. After a lost response, use Check saved decision. Only when no committed decision is observed does Retry the same decision appear; it resends the same cycle and reason. A later resolution, changed saved reason, lost access or missing event evidence is shown as unavailable rather than reopening again.

Replying by email does the same thing. If you got the resolution by email and simply reply to it, that reply reopens the ticket on exactly the same rules — a resolved ticket any time, a closed one inside your organization’s reopen window — and the person who was working on it (or their queue, if nobody is assigned) is told it came back. If the ticket was closed too long ago to reopen, your reply is not lost: Beacon raises a new ticket, links it to the old one so the whole history stays together, and the confirmation you get back tells you which earlier ticket it continues and why the number changed.

Rating the outcome

When a ticket is resolved or a request is fulfilled, a Rate how we did button appears on the ticket — one tap opens the 5-star CSAT rating with an optional comment. One rating per ticket. Once you have rated it, the button is replaced by the submitted state (“Thanks — ★★★★☆ submitted”), which persists across reloads. If you start writing a comment and the dialog closes — a stray tap outside it, a reload — the stars and the words are kept: reopening Rate how we did offers Resume draft / Discard. Written feedback is the most useful part of a rating, so it is not something we are willing to lose.

Approvals

If you can approve requests, Approvals appears directly on the Help Center home and in the bookmarkable Approvals tab. Both show the same paginated inbox and evidence-review controls, listing everything awaiting your decision — and only that: requests where you’re a named approver on the current stage, requests you’re covering for someone else, and requests whose policy names no particular approver. Other people’s approvals aren’t in this list, even if you’re an administrator; the team-wide inbox lives under Administration → Approvals. Your own requests never appear here either — you can’t approve what you asked for. Approve or reject inline; the requester is notified automatically and the request advances (or stops) accordingly. Some requests approve in sequential stages (e.g. manager first, then security): the list shows “stage n of m”, your turn comes only when your stage is active, and the request is granted only after the final stage approves — one rejection at any stage stops it.

The tab is bookmarkable (the relevant workflow), and the “approval needed” email links straight to it.

If Beacon cannot read your pending approvals, it shows the load failure and a Retry action. An empty inbox is shown only after Beacon has actually read that there is no decision waiting for you.

If you’re away, set out-of-office cover so your approvals don’t stall — Administration → Approver experience. Your delegate is asked about your approvals and can decide them for you; the decision is still recorded as yours, with their name against it. You keep getting notified too, so cover never silences you. One thing cover can’t do is give your delegate authority you don’t have: if you raised the request yourself, you can’t approve it — and neither can anyone standing in for you.

If nobody acts, Beacon re-asks. An approval left sitting is chased on your organization’s reminder cadence, to you and to your delegate, up to a bounded number of times.

Deciding from your phone. If your organization has enabled it, approval emails carry Approve and Reject links that work in any browser with no sign-in. Opening one shows a confirmation page first — nothing is recorded until you press the button — and each link works exactly once. If you press an old link, it tells you plainly that it’s already been used and what it recorded, rather than pretending to work.

If your organization has connected Microsoft Teams and you’ve chatted with the Beacon bot before, approvals also reach you as a card in Teams: the request, who raised it, and why, with Approve / Reject buttons and an optional comment. Deciding on the card is exactly the same decision as deciding in the portal — same rules, same audit trail — and the card updates in place once decided. If someone else resolves it first, the card tells you honestly (“already approved by …”) instead of erroring.

Chatting with the assistant

A round chat button sits in the bottom-right corner of the portal. Tap it and the assistant opens — a panel docked to the right on a computer, a full-screen sheet on a phone. It is the same assistant that answers in Microsoft Teams, so it knows the same catalog, follows the same steps and raises the same tickets; it just lives in the portal too.

If chat is unavailable for your access or disabled by your organization, the button is absent. If availability could not be checked, its retry control lets you check again. An administrator manages chat under /manage → Integrations → Chat.

If Beacon cannot check chat availability, it says so and offers Try again. That is different from chat being switched off: a failed check does not prove that your organization disabled the service.

What you can do in it:

• Say what you need in your own words — “my laptop won’t charge”, “I need a second monitor”. The assistant either logs it, walks you through the request, or offers you the catalog matches it found.

• Answer in the panel, not somewhere else. When it finds catalog matches you get them as buttons; picking one opens that item’s real form — the same fields the portal would show — inside the chat. Anything it already understood from your message is filled in for you and stays editable. A form too long for chat hands you to the portal with your answers carried over.

• Change your mind at any point. Every card that offers a choice also offers the way out: None of these goes back to searching, Cancel abandons a form without submitting it.

“Talk to a person” stays in the header. Not at the end of a branch, not after the assistant has failed three times — from a blank conversation, halfway through a form, or while it is asking you to confirm something. One tap raises a ticket for a human, carrying everything you have said so far so you never have to repeat yourself. If an earlier action has an uncertain outcome, check it first; if the current conversation cannot be loaded, Beacon must recover it before sending an action.

When it thinks it recognized your request, it says so before acting and tells you why: Beacon matched your message to a category your administrators configured, and only offers a suggestion when its confidence clears the threshold they set. You get three buttons — run it, it’s something else, or just make a ticket — and choosing “it’s something else” runs nothing.

Your conversation is kept. Close the panel, reload the page, come back tomorrow: the transcript is stored on the server, not in your browser, so it is still there. Once the conversation has raised something, its ticket number stays pinned at the top of the panel as a link — tap it to open the ticket in My tickets. When the conversation has run its course, Start a new conversation appears; the old transcript and anything it raised are untouched.

Honesty about what it can’t do. If Beacon cannot match your sign-in to a user record in your organization’s directory, the panel says so plainly and tells you the ticket will be flagged for the service desk to confirm your details — it does not guess who you are. If you send messages faster than it can take them, it tells you that too rather than silently dropping them.

Your message draft and card answers are saved for this signed-in conversation. After reopening, choose Resume draft to restore unfinished input. A successful send clears that submitted text while keeping anything you typed afterward.

If a response is lost, the saved request stays visible as unconfirmed. Choose Check outcome before trying again. A recorded original request needs no second send. “Not recorded yet” does not prove failure: Retry saved request deliberately uses the same original request and conversation. It cannot submit that old request to a newer thread. If local storage cannot safely save the intent, nothing new is sent and your editable draft stays available. An unreadable saved request is retained and cannot be retried as a different request. If its saved contents are unreadable, Use current conversation asks you to acknowledge that the old request may already have taken effect. Confirmation preserves the original reference and permits a fresh intentional request. It does not retry or confirm the unreadable request; the warning returns after reopening.

After an uncertain restart or request for a human, Current conversation recovered means Beacon has loaded current state. It does not claim which browser tab changed it. The assistant does not automatically repeat either action. Starting over keeps the old server transcript and tickets; it cancels outstanding cards in the old thread.

The assistant checks for new messages every 15 seconds while visible. When updates fail, the last received conversation stays visible with Retry. On a phone, keyboard focus stays inside the full-screen panel; Escape closes it and returns focus to the chat button. Closing is temporarily prevented while an action is in flight.

Requesting through Microsoft Teams

Where Teams is connected, you can raise requests without leaving chat: tell the bot what you need (or pick 2 — Request something from its menu), choose from the catalog matches it offers, and fill in the same form the portal would show — right in the thread. Anything Beacon already understood from your message (a location, a quantity) is pre-filled but always editable. Long forms hand you off to the portal with your answers carried over. On submit you get the request number in-thread, and that thread stays bound to the request — ask “what’s the status?” any time.

Notifications

The bell in the header shows your unread count and opens the notification panel: replies from the team, request approvals/rejections/fulfilments, notice that work has started on a request (with the expected-delivery date), resolution and rating invitations. Clicking a notification marks it read and takes you straight to the ticket; Mark all read clears the badge. The panel shows 25 notifications a page with Previous/Next and a “Showing X-Y of Z notifications” line, so older notifications stay reachable rather than falling off the end. The badge counts your whole unread inbox, not just the page you’re looking at, and updates immediately when you read something.

Notification titles and messages wrap so the complete promise remains readable in the panel, including on a phone.

Choosing what reaches you

Open the account menu (top right) → Notification settings. You get one row per kind of notification plus an account-wide default at the top, and a switch for each channel: in app, email, and chat (chat only applies if your ticket started in Microsoft Teams). Everything is on until you turn it off, and each row tells you where its current setting comes from — Beacon’s default, your account default, or a setting you made for that one kind of notification. Use default on a row drops your override so it follows your account default again.

“We’re waiting on you”

If the service desk needs something from you before they can continue, they put the ticket on hold waiting for you — and you get a notification saying so, linking straight to the ticket. Reply there with what they asked for and the work resumes. Beacon sends one such notice per ticket while it is unread rather than repeating it at you.

On your phone

The portal is built to be used from a phone, not merely to survive on one. It is also installable: open it in your phone browser and use Add to Home Screen (Safari) or Install app (Chrome), and it launches full-screen from your home screen like any other app.

What that means day to day:

• The catalog, help articles and your tickets all read as single-column cards. Nothing needs a sideways scroll, and the tabs across the top scroll rather than crowding each other off the screen.

• Report an issue opens as a full-screen sheet with Cancel and Report issue pinned to the bottom of the screen, so you never scroll back up to submit. Close it with the X, the back gesture, or by tapping outside it.

• Replying to a ticket puts the message box and the Send button on their own rows, so you get a full-width box to type in.

• Approvals put Reject and Approve on their own row beneath the request title, so you can always read what you are deciding about before deciding it.

• Rating a resolved ticket gets the same full-screen sheet, and the stars are individually labelled for screen readers.

• The chat assistant opens as a full-screen sheet rather than a floating box, with “Talk to a person” and the close button fixed in the header so they never scroll away, and every card button on its own full-width row.

• The right keyboard appears for the field you are in — the email keyboard for an email address, the number pad for a quantity, the search keyboard for a search box.

Every control is at least 44 × 44 pixels on a touch screen, so nothing needs a precise tap.

On being offline: installing the app does not make Beacon work offline. Opening it without a connection gives you the app’s shell rather than a browser error page, but tickets, replies and approvals all need a live connection, and nothing you type is stored on the device. That is deliberate — a phone that cached your ticket history would still be holding it after you signed out.

Approving from an email link

If your administrator has enabled approve-by-email, approval emails carry Approve and Reject links that work once, from any browser, with no sign-in. That page is designed for a phone: one column, large buttons, no navigation. Nothing is recorded until you press the button, so a mail scanner following the link cannot decide anything on your behalf.

When we’re waiting on you

If your ticket shows “Waiting for you”, the service desk needs something from you and the response clock is paused. The moment you reply — on the portal or by answering the email thread — the ticket automatically returns to the team’s working queue, the clock restarts, and the time you took to answer is credited against the deadline (you can see each pause and credit on the ticket’s timeline). You never need to do anything beyond replying; there is no “resume” button because none is needed.