Service Orders
Field operations — inspections and installations — inside the CRM, with custom forms, configurable journeys and schedules checked against travel time. It drove dozens of plan upgrades.
- Role
- Front end, plus back end alongside the CTO
- Period
- Jun 2025 – Present
- Context
- Groner · built with the CTO
- Stack
- Vue.js C# Google Maps API SQL Server Quasar TypeScript .NET SQS Lambda S3
This work is proprietary to Groner. It is described at architecture level, without source code or client data.
At a glance
- Dozens of customers upgraded to the top plan
- Sales and field operations in one system
- Schedules checked against travel time and capacity
Context
After a solar sale closes, the work moves to the field: inspection teams survey the site, and installation teams mount the system.
The problem
That operation lived outside the CRM. To run it, customers paid for a separate field-service tool such as Auvo or Field Control — and each customer’s history was split between two systems.
My role
I built the module’s front end — order screens, custom forms, the availability board and the route planner — and worked on the back end alongside the CTO, who wrote most of it. We built the core of the module during a business trip to the headquarters of Resolve Energia Solar, one of Groner’s largest customers at the time, next to the people who would use it.
Architecture
- Configurable per company. Each service type has its own form — photos, checklists, signatures, location and formulas, with conditional fields and role-based editing — and its own time and cost settings.
- Automations on every status change. Per service type and status, an order can update the deal, create the next order, post finance entries, call webhooks or message the customer on WhatsApp.
- Slow work off the request. WhatsApp messages, webhooks and PDF reports go through SQS to Lambdas, with files on S3.
Key decisions
- Custom statuses on a fixed lifecycle. Companies name their steps however they like, but each status maps to a fixed stage — pending, travelling, on site, in progress, validation, finished — so time tracking, automations and reports work the same for everyone.
- One system for sales and operations. Orders hang off the same deal sales works on, so the customer’s history stays in one place and the operation gets the rest of the CRM — permissions, notifications, documents and automations — for free.
The hardest part
Estimating how long an order will take — and whether it fits the technician’s day:
- Service time comes from the service type: base minutes plus a formula over the deal’s own data — the number of panels, the system’s size in kWp and more.
- Travel time comes from Google’s Distance Matrix, starting from the technician’s previous job that day, their base or the store.
- Capacity: service, waiting and travel time have to fit the technician’s or team’s working hours, minus what’s already booked; orders that fall in blocked time or overlap another one are rejected.
On top of that, a route planner orders a day’s stops for the shortest, fastest or a balanced route — trying every order up to eight stops, and a nearest-neighbour heuristic beyond that.
Results
- Dozens of customers upgraded to Groner’s most expensive plan — at the time, the only one with Service Orders — because of this module.
- Customers run inspections and installations in the same CRM as their sales, instead of paying for a separate field-service tool.