Inside Fyxr's AI-Assisted Job Intake System

When a homeowner posts "kitchen sink is leaking" on a job board, a contractor can't quote it. They don't know whether the leak is from the supply line, the trap, or the disposal. They don't know whether the cabinet is wet. They don't know if the homeowner has already turned the water off.

Most of the friction in home services starts here. The homeowner doesn't know which details matter, and the contractor either drives out for a free estimate or writes a quote so padded with assumptions that it isn't useful.

Fyxr's intake flow is the engineering response to that gap. This post is a walk-through of how it works.

The shape of the problem

The intake form has two competing requirements. It needs to capture enough structured data for the platform to route the job to the right trade, match it to a service area, and present a clean brief to contractors. And it needs to feel like writing a sentence, not filling out a tax return.

Our v1 was a long form. Completion rates were low and the data was uneven — homeowners would skip optional fields that were actually important and over-fill ones that didn't matter.

The current system inverts that. The homeowner writes a sentence; the form fills itself in behind a short follow-up conversation.

Architecture

The intake pipeline has four stages:

1. Free-form description

The homeowner types a plain-English description of the problem. There is no character limit and no required format.

2. Category and archetype routing

A classifier maps the description to one of forty-three job categories and one of five archetypes (triage_diagnostic, project_scope, bundle_tasks, recurring_service, spec_install). The classifier is small, fast, and runs on a frozen rules layer with an LLM fallback for ambiguous cases.

3. Clarifying questions

Once the archetype is known, a category-specific prompt asks two to four follow-up questions. The questions are not generated freely — they're drawn from a curated bank we wrote by interviewing contractors. The model's job is to pick which questions are relevant given the description, not to invent new ones.

4. Structured payload

The answers populate a structured details object. The shape of that object is defined per-category in our intake registry and validated server-side by a Joi schema. Contractors see the structured payload, not the conversation.

What the model does not see

A few things deliberately stay outside the model's context:

• Personal data. Name, email, phone, exact address, and payment details never enter the prompt.
• Message threads. Conversations between the homeowner and a contractor are private to that pair.
• Past job history. The intake model sees the current description and the answers to its own follow-up questions. Nothing else.

The model knows enough to ask better questions. It does not know enough to identify the homeowner.

How we evaluate it

Every prompt has an evaluation suite — a fixed set of real intake descriptions, hand-labeled with the correct category, archetype, and the questions a good contractor would want answered. Before a prompt change ships, it has to maintain or improve performance against the suite.

When a contractor flags an intake as missing critical information, that example is added to the suite. The system gets sharper at exactly the points where it was failing in practice.

Where it still falls short

Two areas remain genuinely hard:

• Photos. Homeowners often describe what a photo would show in one sentence ("there's a stain on the ceiling"). We're working on a vision-assisted follow-up that prompts for a picture when text isn't enough.
• Multi-trade jobs. A bathroom remodel touches plumbing, electrical, tile, and sometimes structural work. The current system picks one primary trade and notes the others; routing all of them cleanly is an open problem.

We'd rather ship a system that asks one good question than one that pretends to ask five.