Ask three vendors “how long will this take” and you’ll get three different answers, usually somewhere between a few weeks and several months for a single pilot store. That spread isn’t vendor inconsistency. It’s because the honest answer to a timeline question depends almost entirely on the state of your data and how many systems the project has to touch, not on anything the vendor controls. The more useful question isn’t “when will this be done,” it’s “what has to be true before you can start.”
Why “how long will this take” is the wrong first question
A COO asking for a firm date is asking a reasonable question the wrong way. Any vendor who commits to a number before looking at your document mix, your DMS setup, and how consistent your process is across rooftops is either guessing or quoting a best case.
Key insight
The teams that get burned aren't the ones who accept a longer timeline. They're the ones who accepted a confident short one from a vendor who never asked to see real historical documents.
This matters more in dealership operations than in most back-office automation, because the inputs are messy in a specific way: title jackets scanned at different resolutions by different clerks, lien releases that arrive as a fax image half the time, deal types that vary by state, and a “documented process” that’s really a checklist someone wrote three years ago plus a lot of tribal knowledge about which exceptions actually matter. Discovery work on a comparable transaction-processing project found the review process was “nominally documented, but the real version lived largely in the heads” of the team doing it. That gap between the written process and the actual process is usually the single biggest variable in how long implementation takes, and it’s invisible until someone goes looking for it.
What actually determines the timeline
Three factors do almost all the work in predicting how long a rollout takes, and none of them are about the vendor’s engineering speed.
The state of your existing data and documentation. If your title, funding, and audit workflows are well-documented and your document quality is consistent (clean scans, standard formats, a real record of how exceptions were historically resolved), a vendor can validate a system against reality fairly quickly. If the process only exists as institutional knowledge in a few people’s heads, that knowledge has to be extracted and turned into explicit rules before anything else can happen. This discovery phase, not the software build, is usually the long pole.
How many systems need integration. A workflow that touches only your DMS is a different project than one that also has to reconcile against a CRM, a lender’s funding portal, and an ELT (electronic lien and title) provider. Every additional system is another set of field mappings, another set of edge cases where the “same” data field means something slightly different, and another party whose API access and change windows you don’t control. Integration scope, not model capability, is where most delays actually live.
How much process variation exists across rooftops. A single-store pilot can validate a concept quickly because there’s one set of rules to encode. Take a dealer group with 15 rooftops, for example, where each store’s title clerk does things a little differently: that’s a harder problem, not because the technology changes, but because “the process” turns out to be several related processes that all need to be reconciled or explicitly handled as variants. Dealer principals who’ve been burned by DMS rollouts tend to already know this instinctively, which is why the common pattern is to pilot in one store before rolling out to the group.
What a realistic phase-by-phase sequence looks like
Regardless of the specific calendar dates, a well-run implementation tends to move through the same phases in the same order, and skipping or rushing any of them is where timelines actually blow up.
- Discovery. Someone sits with the people doing the work today, reviews real transactions, and captures the rules, the state-specific variations, and, critically, the exception patterns that separate a routine approval from a case that genuinely needs a human. This is where a vendor should be asking you for documents, not showing you a demo.
- Configuration against real data. The system gets built out against your actual document types and historical decisions, not synthetic test cases or a generic template. This is the step that most exposes whether phase one was done properly.
- Parallel run or shadow mode. The system processes real transactions alongside the existing manual process, and its verdicts get compared against what a human actually decided, before it’s trusted to act on its own. This is also where you get your first honest read on accuracy versus your current manual error rate.
- Supervised production. The system starts making decisions, but a human is reviewing outputs closely and every escalation, not just spot-checking. Trust gets built incrementally here, and this is usually where “how confident are we” gets answered by actual audit trail evidence rather than a vendor’s claims.
- Scale. Once the pilot store or process is stable, the same configuration gets extended to additional rooftops or transaction types, ideally reusing most of the discovery work rather than starting over.
Vendors who quote a single end-to-end number are usually collapsing all five of these into one estimate. Say a vendor promises a six-week rollout: that’s the kind of number that quietly turns into two or three extra months once the parallel run surfaces a document type nobody accounted for in discovery.
What to ask a vendor instead of “how long”
The more diagnostic question is: what do you need from us before you can start, and what does each phase depend on. A vendor who can answer that in specifics, “we need a representative sample of your last 90 days of title exceptions, read access to your DMS by week two, and a decision-maker available for two hours a week during discovery,” is telling you they’ve done this before and know where the real risk sits. A vendor who answers with a marketing timeline and no list of prerequisites is telling you the opposite.
It’s also worth asking how the vendor handles the economics of the decision, not just the calendar. A rollout that takes an extra month but is scoped correctly the first time is cheaper than a fast one that has to be redone. The same logic used to size whether a process is worth automating in the first place, labor cost plus capacity constraint plus error and leakage exposure adding up to real money, roughly $1.2M or more a year, with the automation itself costing no more than about 20% of the value captured, applies just as much to sequencing. A rushed 15-rooftop rollout that has to be unwound is a worse outcome than a properly scoped single-store pilot that takes longer to start.
What’s a reasonable prerequisite to expect before implementation starts?
The single most useful prerequisite, and the one worth insisting on, is access to a representative sample of real historical documents and real historical decisions, not synthetic test cases. That means actual title jackets, actual funding packages, actual instances of the exceptions your team handles every week, along with a record of how those exceptions were resolved and by whom. A vendor building against synthetic or idealized data will produce a system that looks great in a demo and then stumbles on the first batch of real-world messiness: a name mismatch with a suffix, an un-notarized affidavit, a scan quality issue your team has learned to work around without thinking about it.
If a vendor doesn’t ask for this, or is willing to start configuration without it, treat that as a signal, not a convenience. It usually means the “timeline” they gave you is for building something generic, and the actual work of adapting it to your operation hasn’t started yet, it’s just been pushed later, where it will cost you more time to discover.
FAQ
What factors most affect an AI operations implementation timeline? The state of your existing data and documentation, how many systems need integration (DMS, CRM, lender portals, ELT providers), and how much process variation exists across rooftops in a dealer group. Of the three, data and documentation readiness is usually the biggest hidden variable, because it’s invisible until discovery work actually starts.
What’s a reasonable prerequisite to expect before implementation starts? Access to a representative sample of real historical documents and decisions, so the system can be validated against actual operational conditions rather than synthetic test cases. If a vendor is comfortable starting configuration without this, that’s worth questioning rather than treating as a time-saver.
Is a longer quoted timeline automatically a worse sign? Not necessarily. A vendor who gives a longer estimate after asking detailed questions about your document mix, integration needs, and rooftop variation is often being more honest than one who gives a fast, generic number without asking anything. Compare what each vendor asked for, not just what date they promised.
The fastest way to get a realistic timeline isn’t to push harder on the date, it’s to compare how specific each vendor gets about prerequisites: evaluate them side by side, check references from an operation with a document mix and rooftop count similar to yours, and work through the full AI vendor checklist for dealership operations before you sign anything.
For a sense of what a well-scoped rollout looks like end to end, here’s how one deal-processing implementation actually played out.