Requests Console – Functional Specification v0.9

In the old SM, work-to-be-done is fragmented across two ARC views – Incidents (OSM-side) and Tickets (ILOS ARC-side) – and a separate Service Agreements Workspace queue. The SSL Service Manager collapses all of these into one Requests console (G-001):

Design principle. The console is the office/ARC work surface: a supervisor or dispatcher sees every open and closed request in their scope, filters to what needs attention, drills into a request to manage its tasks, and creates new requests. Field staff (responders/installers) primarily act on the mobile app; this console is where work is raised, assigned, watched against SLA and closed.

The landing view of the module is a cross-client list of requests with working status filters, search and quick actions.

Status filters & scope NEW

The five count tiles at the top of the page are the status filter – clicking a tile (Open · Due / overdue · On hold · Unassigned · Closed) filters the list to it and highlights the active tile; clicking it again clears back to all. Counts are computed live from the data. Open = any request still with incomplete tasks; Closed covers both completed and cancelled. A separate All requests / My requests scope toggle limits the list to requests the signed-in user raised, is assigned, or is responsible for. (The earlier duplicate pill row was removed in review – the cards carry the filter.)

Columns

Breached rows are highlighted across the whole row (red tint) so SLA breaches read at a glance. The list paginates at 25 rows per page with explicit page controls (1, 2, 3 …, prev/next), as in the old SM advanced-search results.

Search & type filter

The list controls sit on a single horizontal row: the All requests / My requests scope toggle, a text filter that highlights the matching characters (the same treatment as the header search), and a Type dropdown. (The separate "Advanced" search was removed in review – the global header search covers cross-field lookup, and the inline filters cover the list.)

Service user: search-and-pick, never free text CHANGED

A request must hang off a real service agreement, so the Service-user field is a typeahead, not a text box. Typing searches across surname, forename, "known as" and the 9-digit agreement number, with matches highlighted and the address shown to disambiguate households (three Carters live at 12 Mill Lane). The selection is held in a hidden id and is only ever set by choosing a suggestion; re-editing the text drops it, and leaving the field without a pick clears it - so a half-typed name can never be mistaken for a chosen one. Advancing past step 1 without a real pick is refused. Keyboard: arrows to move, Enter to choose, Escape to close. If nothing matches, the message says why ("a request can only be raised against an existing agreement") rather than offering to create one.

A two-step flow – What → Who & when – replaces Mark's single long form, keeping the dynamic, type-driven field model. Type and Priority are the first two fields (Q-013). For a new request only Type, Priority, Title and Details show at first; choosing a type reveals the rest – a prominent per-type SLA panel, the type-specific fields, the default task set, channel and the cross-user option – and pre-fills suggested values (Title, Details, default task set and the responsible group), per Q-001/Q-003/Q-013. No type is pre-selected.

Field model

• Header grammar CHANGED: the console adopts the platform's table-header pattern - scope segment and filters in the table's own header, the icon-only Columns control, then New request as the primary dark action hard right on the table it acts on. It previously floated in the page header, away from the list it creates rows in. The page subtitle is removed: the heading and the list say what this is.
• Actions column CHANGED: no visible "Actions" heading (the icons are self-evident and the word only added noise; the name is retained for screen readers via a visually-hidden span), and the column is right-aligned so every row's icons line up flush beneath one another.
• Filter cards CHANGED: the "clear" affordance on an active card was absolutely positioned in the card's corner and printed over the label text as the cards narrowed. It now sits in the flow at the end of the label row - the label takes what it needs, the chip takes what is left - and is hidden entirely (not merely transparent) when the card is not the active filter, so it cannot steal space either. Below 900px it collapses to its icon.
• Narrow screens CHANGED: at 1150px the scope segment (All requests / My team / My requests) drops its labels and becomes icons only. The threshold matters: with three labelled buttons plus the search box and the type filter, the row ran out of room at around 1040px and the primary New request action was pushed out of the row entirely - the button vanished before the labels ever collapsed. Collapsing the labels first frees the space so the primary action survives every width; the search box is the elastic element and yields width, the actions never do. The label text stays in the DOM, visually hidden, so the accessible name and the tooltip still read in full.
• Tri-state sorting on the list CHANGED: the console's own sort model now cycles ascending → descending → unsorted, matching the platform standing rule. The model already had a "no sort" state; the third click simply returns to it, restoring the list's natural order.

The detail view manages a single request and its tasks. There is one canonical layout (Q-016): the detail opened from a profile's Requests tab is identical to the one opened from the all-Requests console – Details / Links / Actions in the left 330px panel, Tasks and Stock in the wide column.

• Tasks ("task history" renamed) – each task shows assignee, SLA pill and status; click to open the task panel. Each row carries quick actions to reassign, reschedule and delete the task (audited). Defaults closed as N/A are shown for transparency. Q-007, Q-016
• Stock items – "allocated" renamed reserved; reserved on pick, assigned to the client only on task completion. Items can be added on the detail ("Add stock item" → reserve from a store). Q-004, Q-007
• Details – Type, Priority, Requester, Assigned, Responsible (+ user group), SLA and Booked, Resolution, and (when applicable) Applies to the linked residents. CHANGED "Next action by" is replaced by the SLA target (RAG-coloured) plus who the work is booked on and when. Editable via an audited modal (from → to, who, when); Type is fixed once raised. Q-016, S-014, Q-006
• Links – store third-party URLs, attach a document from the Tunstall reference library (searchable picker, type filter), and accept auto-suggested guides based on the request type / affected equipment. Q-009, Q-017
• Linked requests – where requests exist for the same property / linked agreement, the detail indicates it ("Applies to" + Linked tag) and the profile's Requests tab carries a linked-requests banner. Q-018
• Cancel request – never one-click; opens the guarded cancel flow (§6).

Urgent requests (the incident form of a request) open a dedicated detail carrying the same response timeline component used on the Service-User Profile (S-013): Sent → Accepted → En route → Arrived → Completed, with the live stage highlighted and the SLA-breach banner. In the list, hovering (or focusing) the status pill of an urgent request reveals that whole timeline in a popover. S-013, G-001 · wireframe ↗

Everything captured at creation is shown CHANGED

Fields were being collected on the New Request form and then never surfaced again. The detail view now carries the full creation record, grouped in the order it was captured: what it is (type + change kind, priority, title, details, equipment affected), who it is for (service user with the 9-digit agreement number, linked to the profile; requester with a dialable phone), who is doing it (assigned, responsible group, SLA), and where and when (booked slot, location with a map link, the what3words square, the follow-on request and its Pending / SLA-not-started state, and who raised it, when and through which channel). A request should be readable end to end without reopening the form that made it.

Tasks table carries the scheduling picture NEW

A request's tasks are the same objects Scheduling books, so the request now shows what Scheduling knows about them. A Scheduled column gives the booking - day, slot, and any co-attendee ("Fri 12 Jun, 09:00-11:00, with G. Mason"); an urgent task shows dispatch time and ETA instead, because an incident is dispatched, not booked into a slot; a task that cannot be booked (a phone task, or one that starts on arrival) says so.

The constraints Scheduling enforces ride as compact chips under the task name rather than one column each - there is no room for a column per attribute, and they are read together anyway: size and duration (S/M/L/XL, which drives the slot length, C-005), females-only visits (from the service user's profile keyword - Scheduling will not offer a male responder and an override is confirmed and audited), two-person jobs (Scheduling books each attendee and aligns their arrival times), and access (keysafe, etc.). The chip vocabulary is deliberately identical to the Scheduling board, so a dispatcher reading the request and a dispatcher reading the board see the same thing. Every chip carries a full explanation on hover and none rely on colour alone.

One Tasks table for every request CHANGED

The urgent request's Tasks table was a stripped-down read-only list. It is now identical to the standard one - same columns, same chips, same action buttons. An urgent request's tasks are still tasks: they get reassigned, rescheduled and deleted like any others (Q-016), and a responder on an incident needs the two-person and females-only constraints at least as much as one on a planned visit.

Table header grammar follows the platform pattern: icon-only Columns control, then the emphasised primary action (Add task / Add stock item) hard right. The Actions column heading is not shown (the icons are self-evident; the name is kept for screen readers), the column is right-aligned so the icons line up beneath one another, and it is not sortable - an actions column has nothing to sort by, so it carries data-nosort and gets no sort affordance at all.

Opening a task CHANGED: the task name is the link into the task panel. The separate View (eye) action is removed - a row whose title is already a link does not need a button that does the same thing, and it was competing with the actions that actually change something.

Column balance CHANGED: the Task column (name plus constraint chips) was absorbing all available width and crushing Scheduled / Assigned / SLA / Status into slivers on narrower screens. The columns now have explicit shares and the table a minimum width; below that the shared .ttwrap scroller takes over with its edge shadows. Scroll, do not squeeze.

Verify-by-scan on every stock item CHANGED

The scan check was only on the first reserved item. It is now on every one: a responder fitting three devices has to confirm all three are the right ones, not just the first. The modal states the item and serial it was opened from and checks the scan against that task's picked stock, not against inventory - a wrong item is caught before it is installed, and the check is audited. Q-004

Tasks are the unit of work; a request is the container. The task panel (a side panel) shows status, assignee, SLA, reserved stock, links and notes, with actions to complete, put on hold or reassign.

A request completes only when all its tasks complete. NEW When the last open task is completed, the completing user is prompted to close the request (the same user may do both); the request stays open only if explicitly chosen.

• If other tasks remain open, completing one shows a non-blocking notice – the request stays in progress.
• Resolution on close is optional / free-form (may be omitted) – distinct from the mandatory cancellation reason. Q-010
• On completion, reserved stock is assigned to the client. Q-004

Wireframe demo: open the install task → Complete task → the "close this request?" prompt appears (it requires an explicit choice and does not auto-dismiss). Q-002

Cancellation is an irreversible action – never one-click. The flow requires a mandatory, predefined reason (so the system "knows" the reason – cost / gone into care / no longer required / …) from the admin-defined category list, releases reserved stock and is audited.

Installation (and stock-bearing change) requests carry a pick-stock task. The agreed process rethink: pick stock first; when an installer is picked, a stock-transfer request is auto-initiated if their van (secondary store) lacks the item; stock is reserved on pick to prevent allocation conflicts.

Disposition of the old work-management surfaces against this module. Counts to be reconciled against the Incidents/Tickets screenshot set once catalogued (OQ-R4).