Work requests

Intake and triage - how reported problems become scheduled work, with auto-assignment, approval flows, and linking to existing work orders.

A work request is a reported problem that hasn't been vetted yet. Keeping requests separate from work orders protects the queue: technicians see committed work, while triage happens upstream.

Where requests come from

• The requester portal - occupants, tenants, user groups
• QR scans - a scan on a broken asset opens a pre-tagged request form
• Email intake - a dedicated address that turns incoming email into requests, no login required
• Staff - anyone can log a request when they spot something that isn't today's job

A request needs only a description and a place - photos help, and requesters are asked for a location so triage doesn't have to guess.

Triage

Requests land in Work Requests for Staff and Managers to review. Search by title, requester, email or category, and narrow by site, priority and status from the row under the page title. Managers and Administrators can Export the requests the list is showing as a CSV file.

1. Validate - real issue? enough information? If not, ask - every request carries a live conversation with the person who reported it.
2. Approve and convert - conversion creates a work order carrying over the description, photos, location/asset, and the requester link.
3. Or link to existing work - the same leak gets reported by five people. Link & Approve attaches the request to an existing open work order instead of creating a duplicate; the requester stays connected to the job that's already dispatched.
4. Or decline - with a reason the requester sees. Declining honestly beats a request rotting in "open".

Requesters with a portal account see their request's status change live as it moves - received, approved/declined, converted. Status changes don't send email on their own; when you want the requester notified, post a conversation message - those are emailed.

Live conversations

Every work request carries a two-way message thread between the requester and staff - a real conversation, updating live, not a one-shot rejection comment.

• Ask instead of guessing. "Which door exactly?" beats declining for vagueness or dispatching to the wrong one. The requester answers from their portal; staff reply from the request or the work order.
• Show, don't describe. Either side can attach photos to a message - up to six per message, from a phone's camera or photo library, picked from a computer, or pasted straight into the message box. A message can be photos alone. Photos show in the thread and open full size with a click; message emails say how many came with the message, and the photos themselves stay in the app. Deleting a message deletes its photos from the thread; staff also find them among the request's attachments, and on the work order once the request is converted.
• The thread follows the work. When a request converts, the conversation continues on the work order - pre-approval clarifications and during-work coordination live in one place, and the technician arrives with the full exchange.
• Nobody has to poll. New messages trigger email notifications, and unread replies are badged in both the portal and the app.
• Privacy holds. A requester sees only their own threads and the photos on them; staff see the organization's.

Auto-assignment and auto-approval

One toggle under Settings → Work Orders - auto-assignment - drives both behaviors:

• Auto-assignment matches incoming requests to user groups by site and work category (a specialist group for the matching category first, falling back to a generalist group with no category restriction) so the right people see them immediately. A request about an infrastructure feature goes to the infrastructure groups covering the feature's network.
• Auto-approval rides on the same toggle, gated by priority. Low-priority requests auto-approve whenever auto-assignment is on. Higher priorities auto-approve only when a user group matching the request's site (and category, with the generalist fallback) actually has members - or, for an infrastructure feature, an infrastructure group covering its network. A request nobody would be routed to always waits for a human.

Start manual, observe the patterns, then automate the streams that never get declined anyway.

Metrics worth watching

On the dashboard:

• Request→conversion time - how long triage takes; the requester-experience number
• Decline rate by source - high declines from one building usually means a communication problem, not a reporter problem
• Volume by category - recurring request types are PM candidates: five "door sticks" requests are one PM schedule in disguise