How to generate work orders from a CSV

Steps

1. 1

   Export scheduled jobs

   Export scheduled jobs only after dispatch has assigned the technician and time window. Create one row per job with headers such as `work_order_number,client_name,site_address,scheduled_date,technician_name,service_type,task_summary,priority,estimated_hours,contact_phone`. Keep supervisor-only notes out unless the technician needs them on site. A field-service CSV often carries messy addresses copied from customer systems; normalize `site_address` before upload so the PDF does not bury the suite number or access gate. Use ISO dates like `2026-06-18`, then render them with `{{ row.scheduled_date | date: '%B %-d, %Y' }}`. Include a realistic technician row such as `WO-2026-7712,Acme Manufacturing Co.,44 West Dock Road,2026-06-18,Jamie Park,Compressor inspection,Inspect pressure drop and replace intake filter,urgent,2.5,555-0148`. Preview one job with a long address and one with an urgent priority. The first page should answer where to go, when to arrive, what to do, and who to call.

2. 2

   Map service instructions

   Map service instructions so the technician can scan the work order without hunting. Put `site_address`, `scheduled_date`, `technician_name`, `service_type`, `task_summary`, `priority`, `estimated_hours`, and `contact_phone` in predictable positions. Use Liquid to highlight priority only when it matters: `{% if row.priority == 'urgent' %}URGENT: {{ row.task_summary }}{% else %}{{ row.task_summary }}{% endif %}`. Keep the task text practical. `Replace intake filter and check pressure drop` is useful; `Customer reported issue` is not enough. A common data problem is mixing service notes and billing notes in the same column. Split them before upload so the work order does not show pricing comments or contract disputes to the field team. If `estimated_hours` comes through as `2.5000`, clean it to `2.5` or format the source export. Preview a row for `Jamie Park` and confirm the phone number, site, task, and time all match the dispatch schedule.

3. 3

   Preview field conditions

   Preview work orders under the conditions the field team will actually face. Open the PDF on the phone, tablet, or printed format technicians use, and check the first screen or page before reading anything else. Include edge cases: a long `site_address`, an urgent `priority`, a detailed `task_summary`, and a service type that needs safety notes. Use `{{ row.contact_phone | default: 'Call dispatch' }}` so a missing phone number does not leave the technician stranded with a blank field. A common error is letting line breaks from dispatch notes create huge gaps in the PDF. Clean copied notes into short sentences before upload. Preview a job with access instructions like `Use north gate, call security on arrival, park outside loading bay 2`. Confirm it stays visible near the site details, not after the signature area. The work order is ready when the technician can identify location, arrival date, task, priority, contact, and estimated time without opening the dispatch system.

4. 4

   Generate and distribute

   Generate the final work order batch from the same CSV dispatch approved. Attach each PDF to the matching dispatch record, send it to the assigned technician, or print packets by route. Name files with the work order number and technician, such as `WO-2026-7712-Jamie-Park.pdf`, so supervisors can find them during the day. Keep the source CSV with the generated output. When a technician completes a job, that file becomes the baseline for reconciling what was scheduled against what happened on site. A common operational mistake is changing `technician_name` after generation and leaving the old PDF attached. If the assignment changes, regenerate that row and replace the file instead of forwarding a stale work order. Spot-check urgent jobs after generation. Confirm `{% if row.priority == 'urgent' %}` produced the urgent label, the `contact_phone` is present, and the `scheduled_date` is readable. Distribute only after those checks pass.