Requester Portal

Scope

The requester portal is built for people who will never read a manual. This guide keeps the end-user experience model so operators know what requesters actually see.

The Requester Portal (the relevant workflow) 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 (/manage → 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 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

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.

• Every article also carries Still stuck? Report an issue, and so does the empty state when nothing matches. Self-service should never dead-end 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.

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).

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).

Submitting a request

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.

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 when the request is submitted.

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: 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 is sent. A reply that fails to send is kept, not binned.

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.

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.

What we did

When your ticket 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 they closed it without writing anything, 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.

Reopening a ticket

When a ticket says Resolved — did this fix it? (or a request says Done) and it isn’t actually fixed, hit It’s not fixed — reopen, optionally say what’s still wrong, and the ticket goes straight back to We’re working on it — the assignee is notified 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). What you write in “what’s still wrong” is drafted with the rest of the ticket, so it survives a reload the same way a reply does — and comes back with its panel open, not hidden.

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, an Approvals tab lists everything awaiting your decision. 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 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 you don’t see the button, chat is not switched on for your organization. Beacon deliberately shows nothing at all rather than a greyed-out button that explains an absence you cannot do anything about. An administrator turns it on under /manage → Integrations → Chat.

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” is always in the header, and it always works. 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.

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.

The assistant replies in the panel while you have it open, and it checks for new messages every 15 seconds — so an update that arrives on its own (an approval landing, a job finishing) appears without you doing anything.

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.

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.