Plumber Website vs Field Service Software: What Should Own What?

Overview

A plumbing company can have one customer and five different software records before lunch.

The customer finds the company on Google.

The website captures an enquiry.

A booking system creates an appointment.

Dispatch assigns a technician.

The field app creates a work order.

The invoice system records the bill.

That stack can work beautifully.

The trouble starts when nobody knows which system owns the truth.

The clean architecture is:

public website + ordinary CRM → explicit handoff → specialist plumbing field operations

The website starts before a work order exists

The public website helps a customer:

That is the acquisition and relationship layer.

Current OneStudio features support website editing, enquiries, online booking, client records/history, payment state where enabled, reminders, media and analytics.

• discover the business;
• understand services;
• check the service area;
• decide whether to call;
• request planned service;
• book a suitable appointment;
• submit a quote request;
• build trust.

Plumbing FSM starts when the field job exists

A specialist plumbing field-service system may need to own:

That is the operating layer.

• service request;
• emergency priority;
• property;
• work order;
• technician;
• dispatch;
• route;
• diagnosis;
• pricebook;
• estimate;
• parts;
• truck stock;
• customer authorization;
• field photos;
• invoice;
• job cost;
• service agreement.

Booking and dispatch are not the same thing

A customer can book:

Water-heater consultation, Thursday 14:00

Dispatch may later need to decide:

The first object is customer-facing availability.

The second is field operations.

Do not call ordinary booking dispatch.

• which technician;
• driving route;
• previous job delay;
• skill;
• parts;
• territory;
• emergency override.

Emergency calls need a different entry path

A burst pipe does not behave like annual maintenance.

The emergency path should prioritize:

The website/CRM can preserve the caller relationship.

The dispatch system should own:

• visible phone number;
• service-area fit;
• true availability;
• fast triage.
• priority;
• technician;
• ETA;
• route;
• accepted field job.

Keep customer symptoms separate from technician diagnosis

Customer:

Water heater is leaking.

Technician:

Tank failure or another verified diagnosis.

Those are different facts.

The website should preserve what the customer reported.

The field system should preserve the professional finding.

Never automatically convert intake language into a diagnosis.

Keep client, property and work order separate

A homeowner can have two properties.

A property manager can have fifty.

One property can generate many plumbing jobs.

A useful architecture distinguishes:

Keep installed equipment specialist

Plumbing businesses may track:

Useful technical history can include:

That belongs in the field/asset system.

The ordinary CRM does not need to become an equipment database.

• water heater;
• boiler;
• pump;
• filtration equipment;
• backflow device;
• another serviceable asset.
• serial;
• model;
• install date;
• warranty;
• prior repair;
• recommended service.

Keep the pricebook specialist

A plumbing pricebook can contain:

That is operational commercial logic.

OneStudio should not be described as a plumbing pricebook.

The website can explain services and collect the lead.

• task codes;
• labor assumptions;
• parts;
• markup;
• options;
• member pricing;
• regional pricing;
• flat-rate packages.

Keep inventory and truck stock specialist

A field-service system may track:

The website does not need this information.

The customer should not see a false in stock promise based on a generic CMS field.

• warehouse stock;
• truck stock;
• consumed parts;
• purchase orders;
• reorder points.

Keep estimates and proposals in one place

A plumbing estimate can change after:

Choose one owner for the current estimate.

The public CRM can know the customer asked for a quote.

It does not need an editable competing price.

• diagnosis;
• camera inspection;
• parts selection;
• customer option;
• permit requirement;
• additional scope.

Keep trenchless project operations specialist

Trenchless and CIPP work can involve:

The website can own the trenchless service page and enquiry.

The specialist project/FSM system should own the field record.

• inspection/video;
• pipe condition;
• measurements;
• liner/material system;
• reinstatement;
• equipment;
• crew;
• QA/QC;
• project cost.

Keep service agreements specialist

Maintenance plans can involve:

If the plumbing FSM already owns the plan, keep it authoritative.

OneStudio reminders are useful for ordinary appointment communication.

They should not be described as a plumbing membership engine.

• membership status;
• included services;
• discounts;
• renewal date;
• recurring billing;
• priority rules.

Keep invoice status separate from front-office payment status

OneStudio can keep a payment status connected to a booking/client when payments are enabled.

A plumbing invoice may depend on:

Keep the operational invoice with the system that owns those facts.

• actual work;
• parts;
• estimate;
• additional tasks;
• taxes;
• discounts;
• membership;
• job completion.

Choose one explicit handoff event

Use a named event such as:

Plumbing job accepted into field operations

Possible triggers:

Choose one real rule.

Before handoff, the public/front-office system owns:

After handoff, the FSM owns:

• emergency call accepted;
• planned service request reviewed;
• booking promoted to a work order;
• estimate/project accepted.
• website;
• enquiry;
• bookable appointment;
• ordinary client history;
• source/marketing attribution.
• job;
• dispatch;
• technician;
• diagnosis;
• estimate;
• work order;
• parts;
• invoice.

Use a source-of-truth matrix

Compare three practical stack patterns

Do not buy the wrong product by comparing feature counts

A website platform can be inexpensive because it does not replace:

A plumbing FSM can be more expensive because it does.

Compare responsibilities, not just monthly prices.

Use current OneStudio pricing for OneStudio's live plan scope.

• technician dispatch;
• inventory;
• pricebook;
• field app;
• payroll;
• job costing.

A 30-point buyer test

1. Domain ownership is clear.
2. Emergency phone path is independent of planned booking.
3. Customer-facing booking is distinct from dispatch.
4. Client, property and job are distinct.
5. Customer symptoms remain customer-reported.
6. Handoff has one explicit trigger.
7. Stable source references exist where supported.
8. Operational job has one owner.
9. Emergency priority has one owner.
10. Dispatch has one owner.
11. Technician assignment has one owner.
12. Diagnosis has one owner.
13. Equipment/asset history has one owner.
14. Pricebook has one owner.
15. Estimate has one owner.
16. Parts inventory has one owner.
17. Truck stock has one owner.
18. Work order has one owner.
19. Field photos have one owner.
20. Customer work authorization has one owner.
21. Job cost has one owner.
22. Operational invoice has one owner.
23. Service agreement has one owner when used.
24. Website payment status is not confused with operational invoice status.
25. Generic lead nurture stops/changes after job acceptance.
26. Each stage-specific customer message has one final owner.
27. Field data is not copied into marketing exports.
28. Website URLs can survive a future FSM change.
29. Staff can trace the field job back to the public source.
30. Staff can explain the stack in one sentence.

Give the website and the truck different jobs

The front office should make it easy to find, trust and contact the plumber.

The FSM should make it easy to send the right technician, record the work and bill it correctly.

That boundary creates a stronger stack than asking one generic CRM to pretend it is everything.

Explore OneStudio features, compare plans, or review the turnkey website service.

Questions businesses ask