Where a repair request starts
A ringing phone is not a scheduling system. Independent auto repair shops take calls, texts, website requests, and walk-ins—then still lose the customer's "it only squeals when it's cold" note on a sticky pad, the approval for an extra repair in a technician's memory, and the ready-for-pickup message in a text thread nobody else can see. The appointment form is not the workflow. The workflow is the path from the first request to a written estimate, a recorded approval, and a customer who knows when the car is ready.
This map is for service writers, owners, and small shop teams who share intake, estimates, and customer updates across the front counter and the bays. TwoQM develops custom software, automation, CRM workflows, AI integrations, websites, and connected systems when your current tools do not hand the work to the right person.
Here is an original example, not a TwoQM client and not a measured result. A four-bay shop gets a Sunday web request for "brakes, maybe rotors," with no vehicle year listed. On Monday a regular customer calls about a check-engine light and is told to "just bring it in." A technician finds a leaking water pump on that car, the service writer leaves a voicemail, and the customer texts back "ok do it" to the owner's personal phone. By Tuesday afternoon the customer calls to ask why nobody said the car was ready. Three channels, three partial stories.
The same request may begin on a website form, a phone call, a Google Business Profile message, a text, or at the counter. Ordinary automation covers a large share when it points at one record the team opens: a confirmation that the request arrived, a reminder the day before drop-off, and a status update the shop can send without retyping the vehicle and the concern.
Write the staff path first
One intake shape. Every request collects the same facts: name, best contact method, vehicle year, make, and model, mileage if known, the concern in the customer's own words, and preferred drop-off time. A form can require some of that. A phone call needs a service writer to enter it before the car arrives.
One owner for unscheduled channels. Name who checks the shop text line, voicemail, and web requests, and by what time each morning. "Whoever answers" means Sunday requests wait until Tuesday.
Findings that travel with the repair order. Inspection notes and photos of the worn part belong on the repair order the service writer and the customer both see, not only on a technician's phone.
Approvals recorded, not remembered. The Federal Trade Commission's auto repair guidance for consumers tells drivers to ask for a written estimate that identifies the condition, parts, and expected labor, and that says the shop will contact them for approval before going past a set amount. State law may add requirements. Whatever your process, the approval—who approved, what amount, when, and through which channel—should live on the repair order, not in a personal text.
Statuses the customer understands. Request received, scheduled, checked in, inspecting, waiting on approval, waiting on parts, in repair, ready for pickup.
One owner for the pickup message. Name who sends the ready notice, who answers "what did you find?", and who follows up on recommended work the customer postponed.
Automation first, then a draft a person sends
Use business automation when the answer is already in the record: request confirmations, drop-off reminders, an alert when an estimate has waited too long for an answer, a ready-for-pickup text when the status changes, and a reminder months later about the service the customer deferred. Those steps should not wait on a language model, and they should not invent appointment times the schedule does not have.
AI fits when the message is messy and a person still decides. A text like "car shakes on the highway since the tire place, also AC smells weird, can I drop it Thursday early?" can become a short intake summary: likely concerns, missing vehicle details, and a draft reply asking for the year and model and confirming the drop-off window. It must not diagnose the car, quote a price, or send itself. AI and automation at TwoQM starts with the task, the information it may use, and who reviews the result.
A CRM workflow helps when declined or postponed work needs a follow-up stage and a clear owner. If your shop management software already holds repair orders and vehicle history, connect that system instead of starting a second database.
When a custom piece is justified
Custom software fits when the same handoff breaks every week and no setting fixes it: bilingual intake, an approval page that shows the customer the photo and line items before they reply, fleet customers who need their own view of open repairs, or web and text requests that must land on one board with the original channel preserved. Agree on permissions and what happens when a connected system is unavailable before anyone builds. If the problem is that customers cannot find your services or booking path, a clearer website may be the right first step. If they can find you but approvals and updates still get lost, fix the workflow.
Tell us about your workflow
Write down the path you are losing: Sunday web requests, approvals that live in personal texts, or customers who call to ask whether the car is done. Then tell us about your workflow. TwoQM is based in Brownsville, Texas, and works with businesses nationwide, in English and Spanish. We will tell you whether your current tools, a connection between systems, or a small custom piece fits—and what it will not do. An inquiry is not a quote, and it is not a claim that a system is already built.