Requests
Capture customer inquiries from email, web forms, or chat channels — triage and convert to estimates or work orders.
A request is a customer inquiry that hasn't yet been priced or scheduled. It's the starting point of the field-service pipeline. Once you triage a request you can convert it into:
- An estimate — when the customer needs pricing before they approve the work, or
- A work order — when no quote is needed (service-contract-covered visits, returning customers with agreed rates, urgent calls).
You can also reject a request with an optional reason — useful for tracking lost work and identifying patterns.
Where requests come from
| Source | How |
|---|---|
Mail sent to your workspace's intake alias (service@… by default) auto-creates a request. See Email Intake. | |
| Channel adapter | WhatsApp / SMS / custom channel routed to FSM via a workspace routing rule with action create_fsm_request. |
| Manual | Dispatcher creates one when a customer calls — /fsm/requests → New (Phase 4.8 UI; today via the v1 API or AI tool create_fsm_request). |
| AI tool | The create_fsm_request AI tool — useful when a CSR is in chat with the customer through Workestra's AI panel. |
Every request is automatically numbered REQ-YYYY-NNNN.
Triaging a request
-
Go to
/fsm/requeststo see the triage queue. Filter by status if you want only new ones. -
Click any request to open the detail page. You'll see the original message, the customer (if matched), the requested service type, any preferred time window, and the location.
-
Decide what to do next:
- Convert to estimate — opens a new draft estimate pre-filled with the customer + asset + the request summary as notes. The request status flips to
estimatingand links to the new estimate. - Convert to work order — creates a work order directly (no quote). The request status flips to
converted. You can then schedule an appointment on the new work order. - Reject — captures an optional reason and flips the request status to
rejected.
- Convert to estimate — opens a new draft estimate pre-filled with the customer + asset + the request summary as notes. The request status flips to
The request stays linked to whatever you converted it to, so you can always trace a job back to the original inquiry.
Request statuses
| Status | Meaning |
|---|---|
new | Just arrived; not yet looked at |
qualified | Triage in progress — assigned, you've confirmed it's a real lead |
estimating | Converted to an estimate that's being built |
converted | Converted to a work order (or to an approved estimate that became a WO) |
rejected | Won't be worked — reason captured |
new, qualified, and estimating are all "still in play". converted and rejected are terminal.
What's on a request
| Field | Notes |
|---|---|
| Number | REQ-YYYY-NNNN, auto-allocated |
| Source | email / web_form / portal / phone / api / channel |
| Customer | Contact and/or company from CRM |
| Asset | Linked asset under service (optional) |
| Service type | Free-text label (e.g. "HVAC repair", "Annual inspection") |
| Summary | Short subject (~the email subject) |
| Description | Full body (email body / form notes) |
| Preferred time window | When the customer would like the visit (optional) |
| Location | Street / city / postal / country |
| Source inbound item | Back-link to the original email/form payload when applicable |
Activity log
Every status change auto-appends a row to the request's activity timeline. When a request is converted, the activity row captures which work order or estimate it became. Useful for support: "what happened to my request from last Tuesday?"
Requests dedupe on the source message ID. Re-running the same inbound email (e.g. webhook replay) returns the existing request — no duplicates.
Related
- Email Intake — set up the
service@…alias - Estimates — what happens after "Convert to estimate"
- Work Orders — what happens after "Convert to work order"