Designing the Customer Intake System for an Auto Glass Business
How I designed a customer intake flow that captures vehicle details, damage assessment, and insurance info — then feeds directly into an ERP dispatch queue.
James Ross Jr.
Strategic Systems Architect & Enterprise Software Developer
What Makes Auto Glass Intake Different
Customer intake for auto glass is not a simple contact form. The business needs specific information before it can do anything useful — and "specific" means vehicle year, make, model, and trim, the type and location of damage, whether insurance is involved, the customer's location and preferred service time, and photos of the damage when possible.
Getting all of this in a single form submission is the difference between a lead that can be quoted and scheduled immediately and one that requires two or three follow-up calls to gather missing details. Every follow-up call is friction. Friction kills conversion.
The challenge was designing a form that collected comprehensive information without feeling like a bureaucratic ordeal. You can see the live result at myautoglassrehab.com. The target user is someone with a cracked windshield who wants it fixed. They are not in the mood to fill out a twenty-field form. The intake system needed to feel quick and effortless while actually capturing everything Chris needed to dispatch a job.
Multi-Step Form Design
The solution was a multi-step form that broke the intake process into logical groups. Each step focused on one category of information and felt light — three to four fields at most. Progress indicators showed the user how far along they were, and each step validated inline before advancing to the next.
Step one captured the basics: name, phone number, and service address. These three fields were enough to start a conversation if the user abandoned the form, so we prioritized them first.
Step two focused on the vehicle: year, make, model, and trim. This is where the form got interesting. We implemented cascading dropdowns that filtered options dynamically — selecting a make narrowed the model list, selecting a model narrowed the trim list. The vehicle data came from a curated database rather than free-text entry, which eliminated the garbage-in problem that plagues auto glass quoting. A customer typing "Camery" instead of "Camry" creates headaches downstream. Dropdowns prevented that entirely.
Step three addressed the damage: which glass was affected (windshield, rear window, side window, quarter glass), the type of damage (chip, crack, shattered), and approximate size. This step also included an optional photo upload. Photos were not required because mandating them would kill mobile conversion rates, but when customers provided them, they significantly reduced the need for on-site assessment before quoting.
Step four covered insurance and scheduling: whether the customer wanted to file an insurance claim, their insurance provider if applicable, and their preferred service date and time window. Insurance handling is a major differentiator for auto glass businesses, and capturing this information upfront allowed Chris to start the claims process before the technician even arrived.
Data Contracts and ERP Integration
The form was designed as a frontend for the BastionGlass ERP, even though the ERP was still under development when the intake system launched. This was a deliberate architectural choice that saved significant rework later.
Every field in the form mapped to a defined TypeScript interface that both the website and the ERP consumed. The interface looked roughly like this: customer contact information, vehicle specification, damage assessment, insurance details, and scheduling preferences. Each section was a nested type with strict validation rules.
Validation happened at two layers. The frontend used VeeValidate with Zod schemas for instant feedback — the user saw errors as they typed, not after submission. The backend validated against the same Zod schemas before accepting the submission, ensuring that even if someone bypassed the frontend validation, malformed data could not enter the system.
When BastionGlass came online, integrating the intake form was a matter of pointing the submission endpoint to the ERP's API instead of the temporary data store. The data shape did not change. The validation did not change. The form itself did not change. The customer experience was identical, but submissions now landed directly in BastionGlass's dispatch queue where they could be assigned to technicians, quoted, and scheduled without manual data entry.
Conversion Optimization
The multi-step approach had measurable effects on conversion. Compared to the single-page form we initially tested, the multi-step version had a 40% higher completion rate. Users who started the form were more likely to finish it because each individual step felt manageable.
We also implemented progressive data capture — if a user completed step one but abandoned the form, we still had their name and phone number. Chris could follow up with a quick call or text. This recovered leads that would have been completely lost with a traditional all-or-nothing form submission.
Mobile optimization was essential. Over 70% of traffic came from mobile devices, which makes sense for the use case — people discover they have glass damage, pull out their phone, and search for repair services. The form was designed touch-first: large tap targets, no tiny dropdown menus, and keyboard types that matched the field (numeric keyboard for phone numbers, email keyboard for email addresses).
The intake system became the connective tissue between the marketing site and the ERP. It turned website visitors into structured, actionable data that the business could process without manual intervention. That connection — website visitor to dispatched job with zero manual data entry — is where the real value of the system lives.