Client intake systems

Any intake form is easy to build and easy to get wrong. What decides whether it was worth building is what you intend to do with the answers: sort them, route them, compare them, match them against something else, or simply read them. One free-text box collects everything and supports none of that. Separate fields collect less and can be acted on.

So the first conversation is about the decisions the intake has to support. Who should handle this? Is it in scope for us? Which questions can we stop asking on the first call? Each answer becomes a field with a small set of allowed values, and everything that does not serve a decision goes into one optional notes box at the end.

Djob is a two-sided recruiting workspace that took about six months, and intake quality is the whole product. Candidates and jobs are not stored as one blob of text each. They are synced into statement-part tables, and OpenAI's text-embedding-3-small runs over those structured statements rather than over a CV as a single document.

That choice is what makes the result explainable. Cosine similarity gives a closeness score, and a score on its own is not a decision, because a candidate can read as close to a role and still fail a hard requirement. So the matching service computes a title score, a required score, an optional score and time gates, and it keeps the pass or fail reason. A recruiter can see why something matched, not only that it did.

The last piece is performance. Match views read from snapshot tables rebuilt daily instead of recalculating every candidate against every job when a page opens. Same intake data, precomputed once. Djob is live at djob.agency with public plans starting at $29/month.

There is a real tension in intake: the shorter the form, the more people finish it, and the less you know when you follow up. Djob handles it by not treating the two as the same object. The public job card supports a quick apply with no CV, but the modal still tries to find or create a full candidate record, so an applicant does not end up stranded in a disconnected applications table.

The same approach works for a service business. Ask a handful of things on the public form, and let the internal record carry the rest of the detail your team fills in as the conversation goes on. Enriching a record after first contact is normal. Losing the enquiry because the form demanded a budget on the first screen is avoidable.

Version one is usually one form, one set of routing rules, one review queue and one follow-up message. What waits: dashboards nobody has a question for yet, an integration for every channel enquiries currently arrive through, and automated replies that need judgment to be correct.

Djob is a fair warning about the cost of getting the shape wrong. Its matching layer had to be reworked into the snapshot model because recruiter screens needed fast, repeatable rankings. That kind of change is cheap when the intake data is already structured into separate statements, and expensive when everything was stored as prose.

A single intake flow — form, qualification rules, internal routing, a review queue, a follow-up email — is a much smaller job than Djob, which took about six months because it covered two audiences plus the matching and admin layer between them. It is closer in size to Mincha Time's first version, about a month, when the rules are already clear on day one.

The variable is almost never the form. It is how many exceptions the routing has to respect, and how many other systems the qualified enquiry has to land in.