Project Overview
A US professional services firm offering twelve distinct service lines was collecting all new client intake through a single static form. The form asked the same questions regardless of what the client actually needed, which meant some clients answered questions that were irrelevant to their situation, while others submitted forms missing information that was critical to getting their project started. The result was a predictable cycle of incomplete submissions, back-and-forth clarification emails, and delayed project kickoffs. We rebuilt the intake as an AI-guided conversational flow that adapted its questions based on previous answers, validated completeness before submission, and routed each completed intake directly to the relevant service team with a structured summary attached.
The Challenge
The firm’s twelve service types each required different information from clients at intake. A static form could not accommodate this variation without either becoming very long and burdening every client with every possible question, or remaining short and leaving critical information gaps. The firm had chosen a short form and was paying for that choice with a constant stream of follow-up email exchanges before any project could begin.
- Twelve service types each requiring different intake information, with no way for a static form to distinguish between them
- Intake submissions frequently arrived incomplete, triggering one to three follow-up email exchanges before projects could start
- Completed intakes arrived in a shared inbox and were manually routed to the relevant service team, adding another delay to every project start
- The new system had to feel simple and natural to clients who were often not technical, despite collecting significantly more structured information than the old form
Our Solution
We rebuilt the intake as an AI-guided conversational interface that branched its question logic based on each client’s previous answers. A client engaging a specific service type saw only the questions relevant to their situation, in a natural sequence that mirrored how an intake conversation with a staff member would actually unfold. Before submission, the system validated that all required fields for the identified service type were complete. On submission, the intake was automatically packaged into a structured summary and routed to the correct service team.
- Adaptive Question Logic: The conversational flow used the client’s service type selection and early answers to determine the subsequent question path, covering all twelve service types through a single interface without exposing any client to irrelevant questions.
- Completeness Validation: Before allowing submission, the system checked that all required fields for the identified service type were filled and that free-text responses met minimum specificity thresholds, prompting clients to expand incomplete answers before submitting.
- Automated Routing and Summarization: Each completed intake was automatically packaged into a structured summary document and routed to the correct service team’s queue, removing the manual inbox triage step entirely.
- Client-Facing Simplicity: The interface was designed through usability testing with clients representative of the firm’s typical customer, prioritizing natural language prompts and minimal friction at every step.
Technical Approach
The conversational flow was built as a React application with a Node.js backend managing the branching question logic and state. Question paths for each of the twelve service types were defined in a structured configuration layer, allowing the firm’s staff to update question sequences and required fields without code changes. The completeness validation layer combined field-level rules with a lightweight AI model evaluating free-text response quality. On submission, a server-side summary generation step produced a structured intake document that was routed via API to the firm’s project management system and to the relevant team’s notification channel.
Results & Impact
- Follow-up clarification emails dropped significantly following deployment, as completeness validation at submission resolved the gaps that had previously required back-and-forth exchanges
- Intake completion rate improved, with fewer clients abandoning mid-form compared to the previous static form
- All twelve service types were covered through a single intake interface for the first time, replacing a mix of service-specific forms and a general form that had accumulated inconsistently over time
- Project start times shortened because teams received complete, structured intake information on day one rather than waiting out a clarification cycle
- Manual inbox triage and routing was eliminated: intakes arrived directly in the correct team queue from the moment of submission
Lessons Learned
The complexity of covering twelve service types in a single adaptive flow required more upfront logic mapping than anticipated. Before writing a line of code, we ran structured workshops with representatives from each service line to document exactly what information they needed at intake, what was truly required versus nice to have, and what follow-up questions they most commonly asked after receiving a static form submission. That documentation session revealed significant variation in what each team actually needed, and it was the foundation for the entire branching logic. Skipping it and working from assumptions would have produced a system that felt adaptive but still left gaps. The usability testing with non-technical clients was equally important: several question phrasings that seemed clear to the firm’s staff were confusing to clients, and catching those issues before launch prevented the new system from creating a different kind of friction.