← All posts

From inbox to completed job: the Lavenity AI Front Office roadmap

See what Lavenity has already delivered across service requests, Ven qualification, scheduling, and jobs — and what comes next before broader automation.

Lavenity is moving from a generic AI help desk toward an AI Front Office for field-service businesses. The goal is not simply to answer more messages. It is to turn an inbound conversation into structured, accountable work: identify the service, collect the facts required to act, find a valid time, confirm the visit, and give the team a work order that preserves what the customer agreed to. This roadmap explains what is already in the product, which safety boundaries remain deliberate, and what the next milestones add.

The category shift: from answering messages to creating work

The product keeps the parts of the help desk that already work well: omnichannel intake, customer identity, the shared inbox, approved knowledge, attachments, human assignment, and reporting. Front Office is a new operational layer beside that foundation. A Service Request represents the work being requested; qualification answers explain whether it is ready; an Appointment represents a committed time; and a Job represents the work the business must deliver. Keeping those concepts separate prevents a conversation status from pretending to be an operational workflow.

M1 established the Service Request foundation. Operators can turn a conversation into a request, choose a catalog service, connect a property or asset, see missing information, and move the request through an explicit lifecycle. Service templates define the qualification fields that matter for each service instead of relying on one universal intake form. The request panel keeps the structured state beside the original conversation, so a teammate can correct a value without losing the message that produced it.

M1 and M2: structured requests with controlled AI qualification

M2 introduced Ven qualification and reliable orchestration. Ven returns a structured decision rather than directly changing arbitrary records. Deterministic policy code checks the matched service, confidence, current version, permissions, emergency rules, and the exact fields the service allows. Observe shows what Ven understood, Assist lets an operator approve proposed changes, and Qualify lets Ven record high-confidence facts and ask one approved question at a time. An action audit and transactional outbox make retries visible and idempotent.

M3 added safe native scheduling. Resources carry availability, exceptions, skills, service zones, and buffers. Slot search is deterministic, temporary holds expire, and confirmation rechecks the current request and availability. Database-backed conflict prevention ensures two customers cannot reserve the same resource and time, while repeated confirmation returns the same appointment. Customer confirmations are queued durably, so a temporary channel failure does not undo a valid booking.

M3 and M4: safe scheduling followed by accountable work orders

M4 closes the first operational loop with Jobs and Work Orders. A confirmed appointment creates exactly one Job in the same transaction. The Job receives a snapshot of the service, customer, address, access notes, asset, urgency, summary, and qualification answers as they stood when the visit was accepted. Dispatch can then move it through created, dispatched, in progress, completed, or cancelled without rewriting the original customer request.

M5–M8: quotes, vertical operations, hardening, and integrations

The next milestones expand capability without relaxing the boundary between an AI proposal and a committed business action. M5 adds quote drafts and explicit approval. M6 deepens vertical onboarding, policy editors, operational reports, packaging, and positioning. M7 covers multi-node hardening, retention, failure testing, and security runbooks. M8 adds external calendars and ERP or field-service connectors. Autonomous Book mode remains off until Ven receives allowlisted availability, hold, and booking tools; the scheduling foundation is ready, but the agent must not promise a time it cannot safely reserve.

Use the roadmap as a deployment gate, not a release calendar

Begin with one active service whose qualification rules the team can explain. Run it in Observe until the service match, required fields, emergency classification, and handoff decisions are reliable. Move to Assist only when operators can review the proposed changes quickly and can trace every value back to the customer message that produced it.

Enable Qualify when the template questions are customer-ready and the exception queue has a named owner. Track how often requests reach Ready for scheduling, how often customers correct a captured fact, and how often an ambiguous or unsupported case receives a safe answer. A higher autonomy level should remove manual work without increasing recovery work.

Treat Book, quote sending, and external connector writes as separate gates. Each needs its own allowlist, idempotency, conflict handling, delivery evidence, and rollback path. The roadmap is successful when a workspace earns the next permission from measured behavior, not when every mode is enabled on a date chosen in advance.

Frequently asked question

Which parts of the Lavenity AI Front Office roadmap are available now?

The core M1–M4 operational foundation is implemented: Service Requests and templates, Observe/Assist/Qualify orchestration, native resource scheduling with holds and conflict prevention, and Jobs created from confirmed appointments. Autonomous Book remains off until Ven receives policy-controlled scheduling tools. Quotes, deeper vertical onboarding and reporting, hardening, and external calendar or ERP connectors follow in M5–M8.