Requester portal

The deliberately simple surface for occupants and residents - submit a problem, attach a photo, and watch its status. Nothing else.

The portal is what Requesters see instead of the application: one place to report a problem and watch what happens to it. No asset registry, no queues, no training required.

What a requester can do

That last line is the point: you can hand portal access to every teacher, tenant, or arena user group without any data-exposure conversation.

Getting people into the portal

Invite them with the Requester role under Settings → Users (or via self-registration options if enabled for your organization). They sign in the same way staff do - email one-time passcode - and land in the portal automatically.

The zero-login path: QR codes

Most reporters won't remember a URL. Location and asset QR codes are the workaround: a scan on the broken door opens a submission form already tagged with that door. Post location codes at entrances, gyms, and rinks and problem reports start arriving pre-triaged.

What staff control

Under Settings → Requester Portal, Administrators control six toggles:

Auto-routing for incoming requests lives under Settings → Work Orders (details).

Communicating back

Each request's conversation thread is the channel: messages staff send appear in the portal live, new replies are emailed and badged as unread, and the same thread continues on the work order after conversion - so "any update on my door?" has a place to be asked and answered. Two habits pay off:

  1. Close the loop on declines. "This is the landlord's responsibility - forwarded to them" costs ten seconds and preserves trust.
  2. Don't over-communicate mechanics. Requesters see clean statuses and your messages - not your internal queue gymnastics. Internal coordination belongs on the work order itself, which requesters never open.