In Lavenity, "ready to schedule" is not a judgement the model makes. It is a property of the service template: a request is ready when every field the business marked as required for action has a stored, validated answer. That is why the catalog, not the prompt, is where a front-office rollout actually begins — a service with no template is a service Ven can recognise but never complete.
A field is a key, a type, a rule, and an approved question
Each qualification field carries a stable key, a human label, a data type, a required-for-action flag, an optional validation rule, and the exact question Ven is permitted to ask. Types cover text, number, boolean, date, single choice, and multiple choice. Typing matters beyond form rendering: a typed value can be validated before it is stored, and a choice field turns a free-text answer into a value automation can branch on later without parsing prose.
The pilot heating-maintenance template shows the shape in practice. The system type is a choice field and required, because dispatch cannot send the right technician without it. Manufacturer and model are text and optional — useful, often unknown to the customer, and not worth blocking a booking over. A preferred date window is required, and a free-text notes field catches everything a checklist did not anticipate. Labels and questions are written in the customer's language while option values stay language-neutral, so an automation decision never depends on presentation copy.
What the ask template unlocks, and what catalog readiness reveals
The ask template is what makes a service askable. Without it Ven can still match the service and record facts it reads from what a customer volunteered, but it has no approved wording to ask with, so it cannot close the gap on its own. This is visible rather than implied: catalog readiness counts active services, services with at least one required field, and services that also give Ven a question — three numbers that usually explain a disappointing Qualify pilot faster than any transcript.
The editor enforces the constraints that keep the data usable. Keys must match a lowercase identifier pattern and stay unique within the service, every field needs a label, and choice fields cannot be saved without options. Only an owner can change a template, because widening what a service collects changes what the AI is allowed to ask every customer from that moment on.
Readiness is derived, never supplied
Readiness itself is always derived and never supplied. The server computes the missing-field list from the current template and the answers actually stored; it does not accept a list from a client. A client that could post its own readiness could mark a request complete with nothing filled in, and scheduling would then book a visit against an empty qualification — the failure would surface at a customer's front door rather than in the inbox.
Keep the template as short as dispatch allows
The practical advice is to keep templates short and honest. Every required field is a question somebody has to answer before a booking can happen, and an optional field nobody reads is a question that costs a customer time for nothing. Start with the fields a dispatcher genuinely refuses to schedule without, run the service in Observe long enough to see which answers customers volunteer unprompted, and add the rest only when the transcript shows the gap is real.
Draft a template from the last ten jobs you actually dispatched
Pull ten recent visits for one service and write down every fact the dispatcher needed before assigning them. That list, not a generic intake form, is the first draft of the template. Anything that appears in all ten is a candidate for required for action; anything that appeared once belongs in the free-text notes field.
Turn the recurring choices into choice fields with language-neutral values and readable labels. A boiler type stored as a stable value can drive resource skill matching and later reporting, whereas the same answer captured as free text has to be re-read by a person every time it matters.
Write each ask template as the sentence you would want a new colleague to use on the phone. Ven sends it verbatim, one question at a time, so a vague wording produces a vague answer that a person then has to correct — and every correction shows up in the accuracy signal the rollout plan uses to decide whether the service is ready for more autonomy.
Frequently asked question
What makes a service ready for autonomous qualification?
Three things, and the catalog readiness figures report each of them: the service must be active, it must define at least one field marked required for action, and those required fields must carry a non-empty ask template. Without the question, Ven can match the service and record facts a customer volunteers, but it has no approved wording to close the remaining gaps on its own.