A service request should give the office enough context to make a useful next decision before anyone reaches for the phone.
Too often, online booking creates a thin record: a name, a number, and a sentence like “need help with a door.” The office still has to call back just to learn what is broken, where the work is, which option the customer is considering, and whether photos are available. The customer repeats the story, the dispatcher starts from zero, and the first useful decision is delayed.
We built the Exoserva booking flow to collect more of that context up front while keeping the experience simple for the customer.
Start with a clear service choice
When a company has configured service options in its Price Book, the booking page can present those options in a way that is easier to compare. A customer can review the scope and price of the available choices instead of sending a vague request and waiting for the office to explain everything later.
That matters because a request is more useful when it records what the customer actually considered. The office can see the selected service or option, the price shown at the time, and the details attached to that request. If the catalog changes later, the team still has the original booking context.
Let photos carry part of the conversation
Some field-service problems are difficult to describe but easy to recognize in a photo. A damaged gate, a cracked panel, a worn threshold, or a wall that needs patching can be much clearer when the customer adds a few images.
The booking flow allows supporting photos to travel with the request. The goal is not to replace an onsite inspection or promise a final diagnosis from an image. It is to help the team understand the visible condition, prepare better questions, and decide what should happen next.
A simple synthetic example: a homeowner requests an exterior gate repair, selects the relevant service option, and adds three photos showing the hinge, latch, and surrounding frame. The dispatcher can now see whether the request looks like a basic adjustment, a parts question, or work that needs a broader assessment. The first call becomes a confirmation conversation instead of a complete restart.
Keep the price and the request understandable
A booking page should make the displayed amount clear. Where a company uses customer or member pricing, the relevant price can be shown as part of the request experience. The customer should not have to guess which number applies, and the office should not have to reconstruct what was displayed after the fact.
We also added clearer request states around refreshes, errors, and submission. If a page needs to recover its data, that should happen without silently changing what the customer selected. If submission fails, the customer should see a useful error instead of wondering whether the request went through. Protection against accidental double submission helps prevent two records from being created from one action.
What the office receives
A well-formed request can give the team a much better starting point:
- the selected service or proposal option;
- the price and scope shown during booking;
- customer and location details;
- supporting photos;
- the customer’s notes and requested timing;
- one clear submission record rather than an accidental duplicate.
This does not mean every request is ready to schedule automatically. Access conditions, measurements, permits, hidden damage, technician fit, and other details may still require human review. The improvement is that the reviewer begins with real context and can focus on the missing decision instead of asking the customer to repeat everything.
The principle behind the feature
Online booking should not be a digital voicemail box. It should create a usable operational record.
For us, the best booking experience is not the one with the fewest fields at any cost. It is the one that asks for the right information at the right moment, explains choices clearly, and hands the office a request it can actually act on.
Feature availability and displayed options depend on each company’s Price Book and workspace configuration.
What is the one piece of information your team most often has to chase after a customer submits a request?
— The Exoserva Team