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:

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.
• 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; 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.
• 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 - 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