From Work Orders → Field Service Management System
End-to-end
0→1
B2B
2025
My tech stack
Gemini ai, Claude code, Cursor, Lovable ai, Figma, ChatGPT
Industry
Field Service
Company
Method CRM
Role
Lead Product Designer
↑ 64%
Retention at Week 8–10 for activated users
→ 74
Peak active accounts in March — up 17.9% week over week
✓ 78%
Week 10 retention for the January cohort
Challenge
The tools existed. The workflow didn't.
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.
I pushed back on the team's initial instinct to add more features. The data told a different story — churn reasons, support cases, feature requests, in-app chat transcripts all pointed to the same thing. Users weren't leaving because something was missing. They were leaving because there was no standard way to use what already existed.
36-point retention gap between stock and customized users
Today
This is how dispatchers were managing it.
No standardized workflow existed. Every dispatcher had invented their own.
Jumping between screens.
Creating a job meant navigating across work orders, estimates, scheduling, and invoices — no single place to manage any of it.
Re-entering the same data
Customer details, job site, line items — entered once per screen, every time, with no connection between records.
Paying to fix what should have been standard.
Customers who could afford it paid partners to build custom workflows. Customers who couldn't — worked around it or left.
Losing track across multiple days.
Jobs that spanned multiple visits had no parent record to connect them. Progress lived in people's heads, not the product.
Who am I designing for?
Not all field service businesses are the same
I made an early decision to design specifically for Field Service Installation and Maintenance — FSIM. 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.
This wasn't arbitrary. FSIM businesses had the highest work order volume, the most predictable workflows, and the clearest gap between what they needed and what the stock product offered. They were already using Method. They weren't 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
Every design decision had two layers — what's right and what's buildable.
0→1
+
Legacy code
+
No - code platform
Legacy design system
The legacy design system meant visual modernisation was out of scope — every decision had to work within existing components, not around them.
Every pattern I established here would become the foundation for what came after. I worked through feasibility with the PM and engineering before designs were finished — not after. Getting it right mattered beyond this release.
Legacy no-code platform
No native patterns existed for what I was designing. Every interaction had to be built from existing components or require a deliberate platform investment.
Calendar component limitations.
The calendar was limited and prone to bugs. Scheduling by geography and skill set — exactly what real dispatchers need — wasn't supported. Some table-stakes features simply couldn't be built.
The system
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.
his wasn't a single feature — it was the operational foundation of a field service management platform. Method's version of what Jobber does for SMBs, built within real constraints.
The Job is the parent record. Everything connects back to it — estimates, visits, work orders, invoices, customer interactions. A single job can hold multiple work orders, each with independent line items, completion status, and invoicing — supporting phased projects, follow-up work, and work discovered on site.
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)
Testing & Iteration
The same problems kept surfacing.
I tested across multiple rounds — our Professional Services team, partners who build on the platform, and our CEO who had run a field service company himself. Users completed both core tasks. But completion masked the friction.
No clear entry point. Scheduling backwards — assign first, check availability second. Invoice Later with no safety net. Then our CEO pressure-tested the workflow against real field service operations. He came back with six specific challenges — each one changed something.
But completion masked the friction.
"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.
Testing and the CEO session pointed to two core problems — not a list of UI changes.
The scheduling model was backwards. Dispatchers start with availability — not assignment. Everything flowed from this: duration replaced end time, Schedule Later was added so visits can exist without a time slot, the standalone Work Order path was preserved for simple jobs.
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.
For our dispatcher
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
For our B2B's customer
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
What the data showed
Users who stayed became regulars
45 days post-launch the signal was clear.
Active accounts peaked at 74 in March — up 17.9% week over week. Retention stabilized at 64% by Week 8–10 for users who made it past the early drop-off.
The smile curve tells the real story. Retention falls steeply from Week 0 to Week 3 — then climbs back and holds. Users don't churn because the workflow is wrong. They churn before they ever experience its value.
Dotted line indicates recent cohorts still maturing — Week 11–12 data is incomplete
"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
The data points to one question: what do users who make it past Week 3 do in their first two weeks that churned users don't? Finding that moment is what the next iteration is built around.
Scheduling by geography and skill set. In-app notifications for dispatcher re-entry after field crew completion. A mobile-first field crew experience. Progressive billing. The Jobs app is the foundation. What shipped is the starting point.
Retrospective
What I'd do differently.
I'd test the workflow logic before the UI. The scheduling model being backwards was visible in the design in hindsight — earlier low-fidelity testing of the interaction logic, not the screens, would have caught it faster.
I'd design the simple job path from the start. The CEO named it. The data confirmed it. I designed around the complex case because that's where the system requirements were clearest. Next time both cases get equal weight from day one.
The legacy design system meant the UI reflects platform constraints, not design intent. That's the honest context for what you're seeing.
© Copyright 2025 ELAINE CHOW
From Work Orders → Field Service Management System
End-to-end
0→1
B2B
2025
My tech stack
Gemini ai, Claude code, Cursor, Lovable ai, Figma, ChatGPT
Industry
Field Service
Company
Method CRM
Role
Lead Product Designer
↑ 64%
Retention at Week 8–10 for activated users
→ 74
Peak active accounts in March — up 17.9% week over week
✓ 78%
Week 10 retention for the January cohort
Challenge
The tools existed. The workflow didn't.
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.
I pushed back on the team's initial instinct to add more features. The data told a different story — churn reasons, support cases, feature requests, in-app chat transcripts all pointed to the same thing. Users weren't leaving because something was missing. They were leaving because there was no standard way to use what already existed.
36-point retention gap between stock and customized users
Today
This is how dispatchers were managing it.
No standardized workflow existed. Every dispatcher had invented their own.
Jumping between screens.
Creating a job meant navigating across work orders, estimates, scheduling, and invoices — no single place to manage any of it.
Re-entering the same data
Customer details, job site, line items — entered once per screen, every time, with no connection between records.
Paying to fix what should have been standard.
Customers who could afford it paid partners to build custom workflows. Customers who couldn't — worked around it or left.
Losing track across multiple days.
Jobs that spanned multiple visits had no parent record to connect them. Progress lived in people's heads, not the product.
Who am I designing for?
Not all field service businesses are the same
I made an early decision to design specifically for Field Service Installation and Maintenance — FSIM. 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.
This wasn't arbitrary. FSIM businesses had the highest work order volume, the most predictable workflows, and the clearest gap between what they needed and what the stock product offered. They were already using Method. They weren't 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
Every design decision had two layers — what's right and what's buildable.
0→1
+
Legacy code
+
No - code platform
Legacy design system
The legacy design system meant visual modernisation was out of scope — every decision had to work within existing components, not around them.
Every pattern I established here would become the foundation for what came after. I worked through feasibility with the PM and engineering before designs were finished — not after. Getting it right mattered beyond this release.
Legacy no-code platform
No native patterns existed for what I was designing. Every interaction had to be built from existing components or require a deliberate platform investment.
Calendar component limitations.
The calendar was limited and prone to bugs. Scheduling by geography and skill set — exactly what real dispatchers need — wasn't supported. Some table-stakes features simply couldn't be built.
The system
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.
his wasn't a single feature — it was the operational foundation of a field service management platform. Method's version of what Jobber does for SMBs, built within real constraints.
The Job is the parent record. Everything connects back to it — estimates, visits, work orders, invoices, customer interactions. A single job can hold multiple work orders, each with independent line items, completion status, and invoicing — supporting phased projects, follow-up work, and work discovered on site.
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)
Testing & Iteration
The same problems kept surfacing.
I tested across multiple rounds — our Professional Services team, partners who build on the platform, and our CEO who had run a field service company himself. Users completed both core tasks. But completion masked the friction.
No clear entry point. Scheduling backwards — assign first, check availability second. Invoice Later with no safety net. Then our CEO pressure-tested the workflow against real field service operations. He came back with six specific challenges — each one changed something.
But completion masked the friction.
"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.
Testing and the CEO session pointed to two core problems — not a list of UI changes.
The scheduling model was backwards. Dispatchers start with availability — not assignment. Everything flowed from this: duration replaced end time, Schedule Later was added so visits can exist without a time slot, the standalone Work Order path was preserved for simple jobs.
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.
For our dispatcher
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
For our B2B's customer
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
What the data showed
Users who stayed became regulars
45 days post-launch the signal was clear.
Active accounts peaked at 74 in March — up 17.9% week over week. Retention stabilized at 64% by Week 8–10 for users who made it past the early drop-off.
The smile curve tells the real story. Retention falls steeply from Week 0 to Week 3 — then climbs back and holds. Users don't churn because the workflow is wrong. They churn before they ever experience its value.
Dotted line indicates recent cohorts still maturing — Week 11–12 data is incomplete
"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
The data points to one question: what do users who make it past Week 3 do in their first two weeks that churned users don't? Finding that moment is what the next iteration is built around.
Scheduling by geography and skill set. In-app notifications for dispatcher re-entry after field crew completion. A mobile-first field crew experience. Progressive billing. The Jobs app is the foundation. What shipped is the starting point.
Retrospective
What I'd do differently.
I'd test the workflow logic before the UI. The scheduling model being backwards was visible in the design in hindsight — earlier low-fidelity testing of the interaction logic, not the screens, would have caught it faster.
I'd design the simple job path from the start. The CEO named it. The data confirmed it. I designed around the complex case because that's where the system requirements were clearest. Next time both cases get equal weight from day one.
The legacy design system meant the UI reflects platform constraints, not design intent. That's the honest context for what you're seeing.
© Copyright 2025 ELAINE CHOW
From Work Orders → Field Service Management System
End-to-end
0→1
B2B
2025
My tech stack
Gemini ai, Claude code, Cursor, Lovable ai, Figma, ChatGPT
Industry
Field Service
Company
Method CRM
Role
Lead Product Designer
↑ 64%
Retention at Week 8–10 for activated users
→ 74
Peak active accounts in March — up 17.9% week over week
✓ 78%
Week 10 retention for the January cohort
Challenge
The tools existed. The workflow didn't.
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.
I pushed back on the team's initial instinct to add more features. The data told a different story — churn reasons, support cases, feature requests, in-app chat transcripts all pointed to the same thing. Users weren't leaving because something was missing. They were leaving because there was no standard way to use what already existed.
36-point retention gap between stock and customized users
Today
This is how dispatchers were managing it.
No standardized workflow existed. Every dispatcher had invented their own.
Jumping between screens.
Creating a job meant navigating across work orders, estimates, scheduling, and invoices — no single place to manage any of it.
Re-entering the same data
Customer details, job site, line items — entered once per screen, every time, with no connection between records.
Paying to fix what should have been standard.
Customers who could afford it paid partners to build custom workflows. Customers who couldn't — worked around it or left.
Losing track across multiple days.
Jobs that spanned multiple visits had no parent record to connect them. Progress lived in people's heads, not the product.
Who am I designing for?
Not all field service businesses are the same
I made an early decision to design specifically for Field Service Installation and Maintenance — FSIM. 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.
This wasn't arbitrary. FSIM businesses had the highest work order volume, the most predictable workflows, and the clearest gap between what they needed and what the stock product offered. They were already using Method. They weren't 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
Every design decision had two layers — what's right and what's buildable.
0→1
+
Legacy code
+
No - code platform
Legacy design system
The legacy design system meant visual modernisation was out of scope — every decision had to work within existing components, not around them.
Every pattern I established here would become the foundation for what came after. I worked through feasibility with the PM and engineering before designs were finished — not after. Getting it right mattered beyond this release.
Legacy no-code platform
No native patterns existed for what I was designing. Every interaction had to be built from existing components or require a deliberate platform investment.
Calendar component limitations.
The calendar was limited and prone to bugs. Scheduling by geography and skill set — exactly what real dispatchers need — wasn't supported. Some table-stakes features simply couldn't be built.
The system
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.
his wasn't a single feature — it was the operational foundation of a field service management platform. Method's version of what Jobber does for SMBs, built within real constraints.
The Job is the parent record. Everything connects back to it — estimates, visits, work orders, invoices, customer interactions. A single job can hold multiple work orders, each with independent line items, completion status, and invoicing — supporting phased projects, follow-up work, and work discovered on site.
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)
Testing & Iteration
The same problems kept surfacing.
I tested across multiple rounds — our Professional Services team, partners who build on the platform, and our CEO who had run a field service company himself. Users completed both core tasks. But completion masked the friction.
No clear entry point. Scheduling backwards — assign first, check availability second. Invoice Later with no safety net. Then our CEO pressure-tested the workflow against real field service operations. He came back with six specific challenges — each one changed something.
But completion masked the friction.
"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.
Testing and the CEO session pointed to two core problems — not a list of UI changes.
The scheduling model was backwards. Dispatchers start with availability — not assignment. Everything flowed from this: duration replaced end time, Schedule Later was added so visits can exist without a time slot, the standalone Work Order path was preserved for simple jobs.
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.
For our dispatcher
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
For our B2B's customer
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
What the data showed
Users who stayed became regulars
45 days post-launch the signal was clear.
Active accounts peaked at 74 in March — up 17.9% week over week. Retention stabilized at 64% by Week 8–10 for users who made it past the early drop-off.
The smile curve tells the real story. Retention falls steeply from Week 0 to Week 3 — then climbs back and holds. Users don't churn because the workflow is wrong. They churn before they ever experience its value.
Dotted line indicates recent cohorts still maturing — Week 11–12 data is incomplete
"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
The data points to one question: what do users who make it past Week 3 do in their first two weeks that churned users don't? Finding that moment is what the next iteration is built around.
Scheduling by geography and skill set. In-app notifications for dispatcher re-entry after field crew completion. A mobile-first field crew experience. Progressive billing. The Jobs app is the foundation. What shipped is the starting point.
Retrospective
What I'd do differently.
I'd test the workflow logic before the UI. The scheduling model being backwards was visible in the design in hindsight — earlier low-fidelity testing of the interaction logic, not the screens, would have caught it faster.
I'd design the simple job path from the start. The CEO named it. The data confirmed it. I designed around the complex case because that's where the system requirements were clearest. Next time both cases get equal weight from day one.
The legacy design system meant the UI reflects platform constraints, not design intent. That's the honest context for what you're seeing.
© Copyright 2025 ELAINE CHOW