Daily Operations

Daily Operations

Daily Operations

These are the day-to-day procedures for running service work through Field Service. The spine is the service-to-cash flow: a request becomes a work order, the work order is scheduled, executed, reviewed, quoted where needed, billed and closed.

1. Request Intake and Triage

Every job begins as a service request. Requests arrive from the portal, from a phone call keyed by a coordinator, from Helpdesk (optional ticket ingestion) or from the integration API.

1. Open Field Service → Requests and pick a new request (or create one).
2. Confirm the customer, site and — where relevant — the serviceable asset.
3. Set priority and problem summary, then move it to Triage.
4. From triage, choose the outcome: convert to a work order, wait for the customer, wait for a quote, resolve remotely, reject, or cancel.

2. Convert a Request to a Work Order

When a request needs a site visit, convert it in one click. The customer, site, asset and problem details carry over — no re-keying.

1. On the request, choose Convert to Work Order.
2. Optionally apply a service template to pre-fill tasks and expected duration.
3. The request moves to converted and a new work order opens in Draft.

3. Schedule, Assign and Dispatch

A work order walks a guided lifecycle. Each transition is permission-gated so only the right roles can move it forward.

1. Release the draft to ready_for_scheduling (field_service_workorder_release).
2. Schedule it — the calendar shows technician availability from their HR schedule, and matches on skill and zone (field_service_workorder_schedule).
3. Assign a technician or crew. In Pro, use the Dispatch Board for drag-and-drop assignment with skill, availability and SLA-risk indicators (field_service_dispatch).
4. Dispatch to notify the technician (field_service_workorder_dispatch). The assignment advances proposed → assigned → notified → accepted → traveling → arrived → working.

Any state can be cancelled with field_service_workorder_cancel; a closed job can be reopened with field_service_workorder_reopen.

4. Execute the Job On Site

The technician carries out the work and documents it as they go — from the desktop work-order screen or the installable field app.

5. The Offline Technician App

Technicians open the installable app at /field_service/app. It is a Progressive Web App: install it once, then it keeps working with no signal on site.

• Works offline — the day's jobs, checklists and reference data are packaged to the device (the mobile bootstrap). Tasks, photos, parts, time and signature are captured locally.
• Syncs when back online — captured changes are pushed and new data pulled. Each change carries a unique operation id so a retry never duplicates it, and edits are reconciled by version number so two people cannot silently overwrite each other.
• Attachments resume — photos upload in chunks and resume if the connection drops.
• Location is operational only — a tracking indicator is shown in the app; live location and location history are separate permissions.

6. Review and Approve

Completed work is checked before it can be billed. This is where quality and accuracy are enforced.

1. Open the job in Under review and confirm tasks, evidence, parts and time are correct (field_service_workorder_review).
2. If something is wrong, send it back to In progress for the technician to fix.
3. When it is right, Approve the completion (field_service_workorder_approve). The job moves to approved, ready for billing.

A service-report PDF can be produced per completed job for the customer record.

7. Quote When Work Needs a Price First

When the customer must approve a price before work proceeds, raise a quotation. Quotes are versioned immutable snapshots — every send is a fixed record.

1. Create a quote from the work order or request, with labor, parts and any discount (field_service_quote; discount overrides need field_service_quote_discount_override).
2. Send it to the customer — a new version snapshot is stored.
3. The customer approves or rejects it (in the portal or by your recording it). On approval, the commercial details sync back to the work order.

8. Bill and Collect

An approved job becomes revenue with no re-encoding. Field Service produces an immutable billing snapshot and hands it off — the official invoice lives in Accounting/Invoices.

1. Open Field Service → Billing. Approved jobs appear as billing candidates with their labor and parts already totaled.
2. Hand off to create a draft invoice in Finance (requires Sales + Finance; field_service_billing). No labor or parts are re-typed.
3. Share the payment link; record payments as they arrive (field_service_payment; voids need field_service_payment_void).
4. The work order moves through billing_ready → invoiced → closed.

9. The Customer Portal Flow

Customers interact through the public portal at /field-service without calling the office. From their side:

• Request service and receive a tracking link.
• Track status as the job is scheduled, dispatched and completed.
• Approve quotes digitally.
• View the service report for a finished job.
• Pay via the payment link and leave feedback.

Portal access uses time-limited tokens (with an OTP path). Expired tokens are cleaned up automatically by a scheduled job.

10. Recurring and Preventive Work

Preventive maintenance that should recur does not depend on someone remembering it.

• Maintenance plans generate recurring work orders across one or many sites (e.g. a monthly chiller PM across five branches). Occurrences use a unique key, so re-runs never create duplicate jobs.
• Service contracts track entitlements and consumption per customer.
• SLA policies (Pro) measure response and resolution targets, flag jobs at risk and escalate on breach.