A request that describes the work perfectly but not where to go is not yet work. Field service runs on two facts a chat transcript rarely states cleanly: the place the van has to reach, and the equipment waiting there. Lavenity stores both as first-class records attached to the customer rather than as sentences inside a summary, because a sentence cannot be matched, reused, or checked against a service area.
The property and the asset are separate records for a reason
A property holds the address lines, postcode, city, country, an optional service zone, and access notes — the gate code, the neighbour with the key, the parking that only works before nine. It is keyed by a normalised form of the address, so the same customer describing the same building twice does not accumulate duplicates, and a request created a month later attaches to the record that already carries the access notes somebody learned the hard way.
An asset belongs to a property and describes a specific machine: category, manufacturer, model, an optional serial number kept unique across the workspace, an installation date, and notes. Equipment outlives any single visit, which is the point. The second call about the same boiler should start from what the business already knows about it rather than from a customer reading a label in a dark cellar.
The address is a dispatch requirement, not a template field
The address is required by dispatch rather than by any service template, and readiness treats it that way — it is reported as missing whether or not a service has been chosen, under a marker deliberately shaped so it can never collide with a template field key. This closed a real gap. Requests Ven creates from a decision carry no address, and readiness once counted template fields only, so in a workspace with no service zones configured such a request could reach ready for scheduling, get booked, and have an empty address confirmed to the customer.
Zones connect the two halves of scheduling. A resource carries the zones it serves and the skills it holds; the request carries the property's postcode. Slot search prioritises resources that fit and explains the ones that do not, and the distinction between the two reasons matters operationally: an address outside the usual area is a decision an owner may want to override for a good customer, while a missing qualification is a boundary that should stay hard no matter who is asking.
Zones, skills, and what the technician brief freezes at booking
At booking time the relevant facts are copied into the job's technician brief: service, customer contact, address, access notes, asset details, urgency, request summary, and the qualification answers as they stood when the visit was accepted. A snapshot rather than a live join, because the instructions someone accepted should not change silently if a colleague edits the original request the evening before the visit. Corrections after that point are added as explicit job notes.
Where an incomplete request is allowed to stay incomplete
The operational list closes the loop by showing an empty address only where it blocks something — once a request is ready for scheduling, or once a job exists and is still live. A request still being qualified is allowed to be incomplete; a confirmed visit to an address nobody wrote down is not. That is the whole distinction the property and asset records exist to make: the difference between a conversation about work and work somebody can actually be sent to do.
Capture the address and the machine while the customer is still typing
Ask for the address as early as the conversation allows, because it is the one fact readiness requires regardless of which service is eventually chosen. A request that reaches ready for scheduling without one is a booking waiting to be confirmed to a customer with nothing in the dispatch field.
Record equipment as an asset rather than as a line in the summary. Category, manufacturer, model, and serial number turn the next call about the same machine into a shorter conversation, and a serial number kept unique across the workspace stops two half-filled records from describing one boiler.
Put anything that affects arrival into access notes rather than into the request summary. The gate code, the parking window, and the neighbour with the key travel with the property to every future visit, while a summary belongs to one request and disappears from the next one.
Frequently asked question
Why does a service request need an address before it can be scheduled?
Because the address is required by dispatch rather than by any service template, readiness reports it as missing whether or not a service has been chosen. Requests that Ven creates from a decision carry no address, and readiness once counted template fields only — so in a workspace without configured service zones such a request could be booked and confirmed to the customer with an empty address.