From Work Orders → Field Service Management System
End-to-end
0→1
B2B
2025
Industry
Field Service
Company
Method CRM
Role
Lead Product Designer
↑ 46%
Retention by Week 7 — rising from 26% at Week 3
→ 44–55
New users per week by March 2026, up from 9–14 in January
✓ 78%
Week 10 retention for the January cohort
Challenge
The tools existed. The workflow didn't.
Only 1 in 4 users engaged with the field service tools weekly. Fewer than 20% were still active at Week 24.
The gap was clear: customized users retained at 54%. Stock users retained at 18%. That wasn't a feature problem — it was a workflow problem.
Users weren't leaving because something was missing. They were leaving because there was no standard way to use what already existed.
Group 2 and 4 highlight a dramatic improvement in retention customization.
Research
Not all field service businesses are the same
Field Service Installation and Maintenance businesses — pool services, HVAC, windows and doors, roofing. Companies with 5–20 employees, predictable repeatable workflows, and some of the highest LTV in Method's customer base. Already using Method. Not getting enough value to stay.
Three personas, one system.
Primary Persona
Dispatcher Diane – Responsible for creating and updating job records. Needs speed, visibility, and minimal screen switching.
Field Crew Frank – Receives and executes job details provided by the dispatcher. Relies on accurate, up-to-date information to avoid delays and rework
Secondary Persona
Customer Chris – Interacts with the business and expects timely, professional service.
Constraints
Building new on top of old
0→1
+
Legacy code
+
No - code platform
Best UX vs. feasible
The calendar was limited and prone to bugs. Scheduling by geography and skill set — exactly what real dispatchers need — wasn't supported by the component framework. Some table-stakes features simply couldn't be built.
Solution
I worked through feasibility with the PM and engineering before designs were finished — not after. Every pattern established here becomes the foundation for what comes next.
System Design
One job. Everything connected.
This wasn't a single feature. It was the operational foundation of a field service management platform for SMBs, built within the constraints of a legacy no-code system.
The Job is the parent record. Everything connects back to it — estimates, visits, work orders, invoices, customer interactions.
Visits are the units of work. Estimate visits for site assessment. Work Order visits for execution. One job can have multiple visits across different days, different technicians, different phases.
The Schedule App is where dispatchers operate — moving visits from an unscheduled waitlist into the calendar, assigning technicians, tracking status in real time.
The Customer Portal connects the customer into the system — confirm, reschedule, or cancel visits, and pay invoices without calling the dispatcher.
Four entry points -> one system
Web to Lead
Converting an opportunity
Service request (Customer portal)
Creating a job
↓
Job
Estimate
→
Work Order
Schedule app
Estimate Visit
Work Order Visit
Customer Portal (Visits)
→
Invoice
→
Customer Portal (Payment)
Building & Learning
The same problems kept surfacing.
I built the first version and tested it across multiple rounds with people who understood field service from different angles — our Professional Services team who customize Method's workflows daily, partners who build industry-specific solutions on top of the platform, and our CEO who had personally run and sold a field service company.
BUT qualitative feedback told a different story
"It would be nice to have a single point — a primary way of doing it that is the best practice."
→ No clear entry point.
"I wanna see all the estimators to see who's available... I wanna be able to filter by discipline."
→ Scheduling was backwards. Dispatchers start with availability, not assignment.
Job management creation
0%
0%
Satisfaction completion Rate
Adding visits to Work order
0%
0%
Satisfaction completion rate
"What if they chose invoice later and then just forgot to do it?"
→ Invoice Later was a black hole with no safety net.
Async walkthrough — pressure testing against real field service operations
What Changed
Two insights. Not six fixes.
The scheduling model was backwards.
Dispatchers start with availability — not assignment. Everything flowed from this:
We introduced modals for visit creation — the first time the platform had used them. Dispatchers could create, schedule, and update visits without losing their place in the workflow. No more context switching to a separate screen for every action.
Duration replaced end time — one field instead of two. Schedule Later let visits exist without a time slot, sitting in the unscheduled waitlist until the dispatcher was ready. The standalone Work Order path was preserved for simple jobs that don't need the full flow.
Duration auto-calculates end time — adjusting a job no longer means changing two fields
Unscheduled visits — wait until the dispatcher has enough information to place them
The invoicing model needed a safety net.
Invoice Later and Invoice on Completion were removed. An Invoice Summary screen replaced them — all work orders pulled from the job record, ready to merge or invoice separately. No manual entry. No forgetting.
The Product
The workflow, connected end to end.
Dispatcher Diane
One hub. One workflow. Insight Blocks on the Jobs list surface what needs attention — new requests, cancelled visits, outstanding payments, unscheduled work — without manual filtering.
Dispatchers arrive knowing exactly where to focus
Customer Chris
The Customer Portal closes the loop. Visits appear automatically once scheduled. Customers confirm, request a reschedule with two preferred times, or cancel. A reschedule triggers Reschedule Pending — the dispatcher responds before another request can be made.
Customers act on their visits without calling the dispatcher
When the final invoice is paid, CSAT triggers automatically. Three options. Optional feedback. Job closes on submission.
Method job— the feedback is stored on the job and is closed
Triggered by payment — the right moment to ask, automatically
Outcomes
Users who stayed became regulars
Users who made it past Week 3 retained at 46% by Week 7. The January cohort held 78% through Week 10. For users who activated, the workflow created genuine long-term habits.
The smile curve tells the real story. Users don't churn because the workflow is wrong. They churn before they ever experience its value.
"The recent changes that you’re showing are very groundbreaking and needed."
"The merge invoices … seems complicated behind the scenes and I love it that you have that!"
What's Next
The next problem is already visible
What do users who make it past Week 3 do in their first two weeks that churned users don't? That's the question the next iteration is built around.
Scheduling by geography and skill set. In-app notifications. A mobile-first field crew experience. Progressive billing. What shipped is the foundation — not the finish line.
Retrospective
I should have tested the logic before the UI
High satisfaction completion rates masked the real friction until the CEO session surfaced it more sharply. Testing the workflow logic at low fidelity — before building screens — would have caught the scheduling model being backwards earlier and saved iteration cycles.
I'd also design the simple job path from the start, not as an afterthought. The CEO named it. The data confirmed it. Next time both cases get equal weight from day one.
© Copyright 2025 ELAINE CHOW
From Work Orders → Field Service Management System
End-to-end
0→1
B2B
2025
Industry
Field Service
Company
Method CRM
Role
Lead Product Designer
↑ 46%
Retention by Week 7 — rising from 26% at Week 3
→ 44–55
New users per week by March 2026, up from 9–14 in January
✓ 78%
Week 10 retention for the January cohort
Challenge
The tools existed. The workflow didn't.
Only 1 in 4 users engaged with the field service tools weekly. Fewer than 20% were still active at Week 24.
The gap was clear: customized users retained at 54%. Stock users retained at 18%. That wasn't a feature problem — it was a workflow problem.
Users weren't leaving because something was missing. They were leaving because there was no standard way to use what already existed.
Group 2 and 4 highlight a dramatic improvement in retention customization.
Research
Not all field service businesses are the same
Field Service Installation and Maintenance businesses — pool services, HVAC, windows and doors, roofing. Companies with 5–20 employees, predictable repeatable workflows, and some of the highest LTV in Method's customer base. Already using Method. Not getting enough value to stay.
Three personas, one system.
Primary Persona
Dispatcher Diane – Responsible for creating and updating job records. Needs speed, visibility, and minimal screen switching.
Field Crew Frank – Receives and executes job details provided by the dispatcher. Relies on accurate, up-to-date information to avoid delays and rework
Secondary Persona
Customer Chris – Interacts with the business and expects timely, professional service.
Constraints
Building new on top of old
0→1
+
Legacy code
+
No - code platform
Best UX vs. feasible
The calendar was limited and prone to bugs. Scheduling by geography and skill set — exactly what real dispatchers need — wasn't supported by the component framework. Some table-stakes features simply couldn't be built.
Solution
I worked through feasibility with the PM and engineering before designs were finished — not after. Every pattern established here becomes the foundation for what comes next.
System Design
One job. Everything connected.
This wasn't a single feature. It was the operational foundation of a field service management platform for SMBs, built within the constraints of a legacy no-code system.
The Job is the parent record. Everything connects back to it — estimates, visits, work orders, invoices, customer interactions.
Visits are the units of work. Estimate visits for site assessment. Work Order visits for execution. One job can have multiple visits across different days, different technicians, different phases.
The Schedule App is where dispatchers operate — moving visits from an unscheduled waitlist into the calendar, assigning technicians, tracking status in real time.
The Customer Portal connects the customer into the system — confirm, reschedule, or cancel visits, and pay invoices without calling the dispatcher.
Four entry points -> one system
Web to Lead
Converting an opportunity
Service request (Customer portal)
Creating a job
↓
Job
Estimate
→
Work Order
Schedule app
Estimate Visit
Work Order Visit
Customer Portal (Visits)
→
Invoice
→
Customer Portal (Payment)
Building & Learning
The same problems kept surfacing.
I built the first version and tested it across multiple rounds with people who understood field service from different angles — our Professional Services team who customize Method's workflows daily, partners who build industry-specific solutions on top of the platform, and our CEO who had personally run and sold a field service company.
BUT qualitative feedback told a different story
"It would be nice to have a single point — a primary way of doing it that is the best practice."
→ No clear entry point.
"I wanna see all the estimators to see who's available... I wanna be able to filter by discipline."
→ Scheduling was backwards. Dispatchers start with availability, not assignment.
Job management creation
0%
0%
Satisfaction completion Rate
Adding visits to Work order
0%
0%
Satisfaction completion rate
"What if they chose invoice later and then just forgot to do it?"
→ Invoice Later was a black hole with no safety net.
Async walkthrough — pressure testing against real field service operations
What Changed
Two insights. Not six fixes.
The scheduling model was backwards.
Dispatchers start with availability — not assignment. Everything flowed from this:
We introduced modals for visit creation — the first time the platform had used them. Dispatchers could create, schedule, and update visits without losing their place in the workflow. No more context switching to a separate screen for every action.
Duration replaced end time — one field instead of two. Schedule Later let visits exist without a time slot, sitting in the unscheduled waitlist until the dispatcher was ready. The standalone Work Order path was preserved for simple jobs that don't need the full flow.
Duration auto-calculates end time — adjusting a job no longer means changing two fields
Unscheduled visits — wait until the dispatcher has enough information to place them
The invoicing model needed a safety net.
Invoice Later and Invoice on Completion were removed. An Invoice Summary screen replaced them — all work orders pulled from the job record, ready to merge or invoice separately. No manual entry. No forgetting.
The Product
The workflow, connected end to end.
Dispatcher Diane
One hub. One workflow. Insight Blocks on the Jobs list surface what needs attention — new requests, cancelled visits, outstanding payments, unscheduled work — without manual filtering.
Dispatchers arrive knowing exactly where to focus
Customer Chris
The Customer Portal closes the loop. Visits appear automatically once scheduled. Customers confirm, request a reschedule with two preferred times, or cancel. A reschedule triggers Reschedule Pending — the dispatcher responds before another request can be made.
Customers act on their visits without calling the dispatcher
When the final invoice is paid, CSAT triggers automatically. Three options. Optional feedback. Job closes on submission.
Method job— the feedback is stored on the job and is closed
Triggered by payment — the right moment to ask, automatically
Outcomes
Users who stayed became regulars
Users who made it past Week 3 retained at 46% by Week 7. The January cohort held 78% through Week 10. For users who activated, the workflow created genuine long-term habits.
The smile curve tells the real story. Users don't churn because the workflow is wrong. They churn before they ever experience its value.
"The recent changes that you’re showing are very groundbreaking and needed."
"The merge invoices … seems complicated behind the scenes and I love it that you have that!"
What's Next
The next problem is already visible
What do users who make it past Week 3 do in their first two weeks that churned users don't? That's the question the next iteration is built around.
Scheduling by geography and skill set. In-app notifications. A mobile-first field crew experience. Progressive billing. What shipped is the foundation — not the finish line.
Retrospective
I should have tested the logic before the UI
High satisfaction completion rates masked the real friction until the CEO session surfaced it more sharply. Testing the workflow logic at low fidelity — before building screens — would have caught the scheduling model being backwards earlier and saved iteration cycles.
I'd also design the simple job path from the start, not as an afterthought. The CEO named it. The data confirmed it. Next time both cases get equal weight from day one.
© Copyright 2025 ELAINE CHOW
From Work Orders → Field Service Management System
End-to-end
0→1
B2B
2025
Industry
Field Service
Company
Method CRM
Role
Lead Product Designer
↑ 46%
Retention by Week 7 — rising from 26% at Week 3
→ 44–55
New users per week by March 2026, up from 9–14 in January
✓ 78%
Week 10 retention for the January cohort
Challenge
The tools existed. The workflow didn't.
Only 1 in 4 users engaged with the field service tools weekly. Fewer than 20% were still active at Week 24.
The gap was clear: customized users retained at 54%. Stock users retained at 18%. That wasn't a feature problem — it was a workflow problem.
Users weren't leaving because something was missing. They were leaving because there was no standard way to use what already existed.
Group 2 and 4 highlight a dramatic improvement in retention customization.
Research
Not all field service businesses are the same
Field Service Installation and Maintenance businesses — pool services, HVAC, windows and doors, roofing. Companies with 5–20 employees, predictable repeatable workflows, and some of the highest LTV in Method's customer base. Already using Method. Not getting enough value to stay.
Three personas, one system.
Primary Persona
Dispatcher Diane – Responsible for creating and updating job records. Needs speed, visibility, and minimal screen switching.
Field Crew Frank – Receives and executes job details provided by the dispatcher. Relies on accurate, up-to-date information to avoid delays and rework
Secondary Persona
Customer Chris – Interacts with the business and expects timely, professional service.
Constraints
Building new on top of old
0→1
+
Legacy code
+
No - code platform
Best UX vs. feasible
The calendar was limited and prone to bugs. Scheduling by geography and skill set — exactly what real dispatchers need — wasn't supported by the component framework. Some table-stakes features simply couldn't be built.
Solution
I worked through feasibility with the PM and engineering before designs were finished — not after. Every pattern established here becomes the foundation for what comes next.
System Design
One job. Everything connected.
This wasn't a single feature. It was the operational foundation of a field service management platform for SMBs, built within the constraints of a legacy no-code system.
The Job is the parent record. Everything connects back to it — estimates, visits, work orders, invoices, customer interactions.
Visits are the units of work. Estimate visits for site assessment. Work Order visits for execution. One job can have multiple visits across different days, different technicians, different phases.
The Schedule App is where dispatchers operate — moving visits from an unscheduled waitlist into the calendar, assigning technicians, tracking status in real time.
The Customer Portal connects the customer into the system — confirm, reschedule, or cancel visits, and pay invoices without calling the dispatcher.
Four entry points -> one system
Web to Lead
Converting an opportunity
Service request (Customer portal)
Creating a job
↓
Job
Estimate
→
Work Order
Schedule app
Estimate Visit
Work Order Visit
Customer Portal (Visits)
→
Invoice
→
Customer Portal (Payment)
Building & Learning
The same problems kept surfacing.
I built the first version and tested it across multiple rounds with people who understood field service from different angles — our Professional Services team who customize Method's workflows daily, partners who build industry-specific solutions on top of the platform, and our CEO who had personally run and sold a field service company.
BUT qualitative feedback told a different story
"It would be nice to have a single point — a primary way of doing it that is the best practice."
→ No clear entry point.
"I wanna see all the estimators to see who's available... I wanna be able to filter by discipline."
→ Scheduling was backwards. Dispatchers start with availability, not assignment.
Job management creation
0%
0%
Satisfaction completion Rate
Adding visits to Work order
0%
0%
Satisfaction completion rate
"What if they chose invoice later and then just forgot to do it?"
→ Invoice Later was a black hole with no safety net.
Async walkthrough — pressure testing against real field service operations
What Changed
Two insights. Not six fixes.
The scheduling model was backwards.
Dispatchers start with availability — not assignment. Everything flowed from this:
We introduced modals for visit creation — the first time the platform had used them. Dispatchers could create, schedule, and update visits without losing their place in the workflow. No more context switching to a separate screen for every action.
Duration replaced end time — one field instead of two. Schedule Later let visits exist without a time slot, sitting in the unscheduled waitlist until the dispatcher was ready. The standalone Work Order path was preserved for simple jobs that don't need the full flow.
Duration auto-calculates end time — adjusting a job no longer means changing two fields
Unscheduled visits — wait until the dispatcher has enough information to place them
The invoicing model needed a safety net.
Invoice Later and Invoice on Completion were removed. An Invoice Summary screen replaced them — all work orders pulled from the job record, ready to merge or invoice separately. No manual entry. No forgetting.
The Product
The workflow, connected end to end.
Dispatcher Diane
One hub. One workflow. Insight Blocks on the Jobs list surface what needs attention — new requests, cancelled visits, outstanding payments, unscheduled work — without manual filtering.
Dispatchers arrive knowing exactly where to focus
Customer Chris
The Customer Portal closes the loop. Visits appear automatically once scheduled. Customers confirm, request a reschedule with two preferred times, or cancel. A reschedule triggers Reschedule Pending — the dispatcher responds before another request can be made.
Customers act on their visits without calling the dispatcher
When the final invoice is paid, CSAT triggers automatically. Three options. Optional feedback. Job closes on submission.
Method job— the feedback is stored on the job and is closed
Triggered by payment — the right moment to ask, automatically
Outcomes
Users who stayed became regulars
Users who made it past Week 3 retained at 46% by Week 7. The January cohort held 78% through Week 10. For users who activated, the workflow created genuine long-term habits.
The smile curve tells the real story. Users don't churn because the workflow is wrong. They churn before they ever experience its value.
"The recent changes that you’re showing are very groundbreaking and needed."
"The merge invoices … seems complicated behind the scenes and I love it that you have that!"
What's Next
The next problem is already visible
What do users who make it past Week 3 do in their first two weeks that churned users don't? That's the question the next iteration is built around.
Scheduling by geography and skill set. In-app notifications. A mobile-first field crew experience. Progressive billing. What shipped is the foundation — not the finish line.
Retrospective
I should have tested the logic before the UI
High satisfaction completion rates masked the real friction until the CEO session surfaced it more sharply. Testing the workflow logic at low fidelity — before building screens — would have caught the scheduling model being backwards earlier and saved iteration cycles.
I'd also design the simple job path from the start, not as an afterthought. The CEO named it. The data confirmed it. Next time both cases get equal weight from day one.
© Copyright 2025 ELAINE CHOW