One Number the Whole Group Trusts: Unifying CDK, Reynolds, and Tekion into a Single Source of Truth

The Problem: A Dealer Group with Three Versions of the Truth

Grow a dealer group by acquisition and you inherit its data the hard way. One rooftop runs CDK. Another runs Reynolds and Reynolds. The newest acquisition runs Tekion. Three systems, three definitions of "customer," three versions of the truth, and a leadership team that cannot get one trustworthy number across the group without a person and a spreadsheet in the middle.

The visible cost is the analyst time. Month-end becomes three to five days of exporting, stitching, and reconciling, and the GM still does not fully trust the figure that lands in the meeting. The invisible cost is larger: the same household gets mailed across rooftops because no system knows they are the same person, redundant reporting tools are paid for store by store, and decisions on inventory, ad spend, and staffing get made on data that is days stale.

This is a reference architecture, built and validated on AutoDataLab: DataStackX's synthetic dealer-group dataset of 40 rooftops, ~250,000 customers, and live CDK, Reynolds, and Tekion feeds with their real-world quirks preserved. The architecture, pipelines, and data contracts are production-grade and real. The dealer group and the dollar figures are modeled on industry benchmarks and our team's 20+ years of combined dealer-data experience, not a specific client. We scope your group's actual numbers in the first working session.

Why It Is Genuinely Hard: Three DMS Realities

This is not a "connect the APIs" problem. Each DMS models the dealership differently, down to how it decides a customer exists. A credible unification absorbs those quirks without losing data, and that is exactly where generic data teams stall and where dealer-native experience earns its keep.

DMS	Lineage	The quirks that break naive integrations
CDK Global	Mainframe	ALL-CAPS tables, codes instead of values, dates stored as YYYYMMDD numbers, and a customer who "does not exist" until they buy (service-only customers live in a separate table)
Reynolds & Reynolds	90s relational	One invoice table for both sales and service, customer IDs that collide across rooftops (must dedupe with dealer ID), and inconsistent NULL versus "N/A" handling
Tekion	Cloud-native	UUID keys and ISO timestamps (modern), but JSONB blobs that hide real complexity and soft-delete flags downstream logic must respect

A "customer count" that naively unions these three systems can be off by 20 to 30%: it double-counts the household that bought at one rooftop and services at another, and drops the service-only customers CDK never promoted to the master file.

What We Built: A Governed Foundation, Not Another Dashboard

Every DMS feeds one lakehouse through a source-adapter layer. Data flows through three governed tiers (raw, conformed, and analytics-ready), with identity resolution stitching customers into one identity across systems and households. KPIs are defined once, so "gross," "unit," and "service retention" mean the same thing in every rooftop and every report.

Data contracts and automated tests guard every layer, so a drifting feed or a broken number is caught before it reaches a meeting. The same codebase runs on a laptop and in the cloud; the difference is configuration, not a rewrite, which keeps the foundation ready for enterprise procurement and for every analytics use case that comes after it.

From "Three Days and a Debate" to One Trusted Number

What changes	Before: fragmented DMS	After: single source of truth
Month-end group reporting	3 to 5 days of manual stitching	Automated overnight refresh
"How many unique customers?"	Days of work, still wrong	Instant, deduped, household-aware
Service retention across rooftops	Not measurable	Tracked daily, group-wide
Trust in the number	Debated in every meeting	One agreed definition
A new report request	1 to 2 weeks of analyst work	Self-serve in hours
Adding a rooftop or DMS	Months of rework	Plug in one adapter

The headline operational result is roughly a 70% reduction in reporting cycle time and manual effort, with one governed definition of every core KPI and a clean base for everything downstream.

The ROI, in Dollars

Modeled for a representative 10-rooftop group (around 13,000 vehicles retailed and 150,000 repair orders per year, around $9 to $10M annual ad spend). Every figure is a hard, countable saving: a real line item a controller can tie to a payroll cost, a software contract, or a marketing invoice. No projected revenue, no "better decisions," no soft value.

Value driver	How it is recovered	Conservative	Upside
Reporting labor redeployed	About 1 to 1.5 FTE of controller and analyst time freed from manual stitching and reconciliation	$120K	$180K
Redundant tooling rationalized	Per-rooftop reporting add-ons, DMS report modules, and overlapping dashboards consolidated	$40K	$90K
Duplicate-marketing waste eliminated	Identity resolution removes the 15 to 30% of mail and CRM spend hitting the same household across rooftops	$50K	$120K
Total hard annual savings		~$210K	~$390K

We deliberately excluded the larger "better decisions" upside (smarter inventory, pricing, and ad-spend calls), even though it is real. That value is earned by the analytics this foundation unlocks and is scoped as separate engagements. Keeping it out means the $210K to $390K is a floor you can defend in a board meeting, not a forecast you have to believe.

How Fast: An AI-Accelerated Build

The build runs in weeks, not quarters, because we do not start from a blank repo. AutoDataLab gives us proven CDK, Reynolds, and Tekion adapter patterns, an identity-resolution and KPI framework, and AI-assisted delivery that scaffolds the pipeline, generates the dbt models and tests, and proposes the source mappings.

Phase	Duration	What lands
Discovery and access	About 1 week	DMS landscape mapped, KPI definitions agreed, data access secured, ROI numbers put against your group
AI-accelerated build	About 4 weeks	Adapters, the three governed tiers, identity resolution, data contracts, and your core trusted KPIs, live in production on your cloud
Harden and expand	Ongoing	Your team owns it with documentation and runbooks; we harden edge cases, add deeper domains, and sequence the first analytics win

The four-week build targets your core sales, service, and customer KPIs and assumes data access is in place; deeper domains follow in the expand phase.

The Real Prize: Everything It Unlocks

A trusted foundation is what makes the high-value work possible. Lead scoring, co-op fund recovery, F&I product propensity, service-retention modeling, used-car pricing: each is a seven-figure opportunity, and each is dead on arrival without clean, unified, governed data underneath it. The foundation is the land; the analytics roadmap is the expand.

What This Demonstrates

This reference build shows the full data-foundation stack for a multi-rooftop dealer group: source adapters that absorb each DMS's quirks, identity resolution and household stitching, a Kimball model with data contracts and automated tests, and a single governed KPI layer, all production-grade and cloud-switchable.

It is grounded in 20+ years of combined experience building these systems for the US automotive industry, including platforms that ran reporting and analytics across 4,000+ dealerships. The same pattern applies to any multi-system business carrying fragmented customer and operational data: retail groups, healthcare networks, and financial services.