One place where the whole store — or the whole group — is visible: consolidated financials, variable and fixed operations, inventory, capital, and the paperwork that moves a deal. Built for your account structure and your pay plans, not configured out of someone else's product.
Owners see everything; outside stakeholders see only what you grant
Dashboard, written plan, deck, and Excel forecast all generated from the same model
Every P&L line carries a definition and its benchmark, in the interface
What-if questions re-run the model rather than estimating from it
A private, authenticated web application that sits above your DMS and holds the operating picture of a dealership or dealer group: the consolidated statement, the departments underneath it, the inventory and capital positions, the scenarios being considered, and the documents in flight.
It is not a report viewer. The numbers are computed by a model that lives in the system, which is what makes the difference between a dashboard that shows last month and a dashboard you can ask a question of. Change an assumption and the consolidated statement, the cash position, and the return all move together, because they are downstream of the same calculation.
Every deployment is built for the client. The modules below describe what we have built and what we build from; which of them you get, and how they are wired to your data, is settled during assessment.
The whole operation on one page: revenue and gross by department, store-by-store comparison, the metrics that are off benchmark, and the handful of figures a principal checks first. Drill from any of them into the detail behind it.
Volume, gross per unit, and mix on the new side. Aging, turn, cost-to-market, and recon cycle on the used side. Product penetration, per-copy gross, lender spread, and reinsurance on the F&I side — broken out by store and by manager.
Absorption, effective labor rate, hours per repair order, technician proficiency and productivity, express throughput, parts gross and obsolescence. The department that carries the store, measured like it matters.
Floorplan, contracts in transit, receivables and payables, and the cash conversion cycle that decides how much capital the operation actually ties up. Includes the covenant tests a credit agreement puts on top of it.
Move a lever — volume, pay plan, floorplan rate, expense-to-gross target, debt draw — and the model re-runs. Levers are range checked, so an out-of-bounds input is reported rather than silently clamped into a different question.
An earnings bridge that separates what the store earns from what an add-back claims it earns, and a decomposition showing where improvement actually comes from: volume, gross, expense discipline, or multiple.
For groups that acquire: a record per target with the broker package, the evaluation, the diligence status, and the modeled effect of adding that store to the group. Deal notes and activity live with the deal rather than in an inbox.
Templates rendered from live data, sent for signature with an ESIGN-compliant disclosure, countersigned, and stored so the executed copy comes back out intact years later. Material changes re-trigger consent; editorial ones do not.
Scan a PDF form once, map its fields to the data already in the system, and fill it on demand. The recurring lender, OEM, and state paperwork stops being a retyping exercise.
A chat panel over the live data that answers by reading the model and, for what-if questions, by re-running it. Every answer lists what it read and what it ran, so a figure can be checked rather than trusted. Where it cannot compute something it says so.
Every line item carries a written definition and its benchmark, reachable in place. Each page has a walkthrough explaining what the page decides, which number on it is load bearing, and what it is deliberately not claiming.
The written plan, the investor or lender deck, and the Excel forecast are generated from the same model as the screen. There is no version of the story that disagrees with the dashboard, because there is only one set of numbers.
A dealer group's dashboard has more than one audience. The principal and the CFO need everything. A capital partner, a lender, or an OEM contact needs a curated subset — and specifically must not see live broker packages, internal commentary, or a diligence argument that has not been had yet.
So access is role based, and the navigation is the policy rather than a rendering of it. The routes a role may open are derived from the routes that role can see, which removes the classic failure: a page quietly dropped from a menu but still reachable by typing its URL, which reads as a security control and is not one.
Two roles, one definition. Adding a page to the stakeholder view is one word in one file; removing it is deleting that word. A build check then verifies the page itself agrees with the policy, so the two cannot drift apart.
| Layer | What we use and why |
|---|---|
| Application | Next.js and TypeScript, server rendered. Fast on a dealership network, works on a phone in the service drive, and no app to install. |
| Model | A Python engine computing store P&L, group consolidation, and returns, with a TypeScript twin for in-browser what-if runs. The two are verified against each other on every build, so a scenario run in the browser is the same calculation. |
| Data | A warehouse fed by scheduled extracts from the DMS, CRM, inventory and lender sources, reconciled to the financial statement before publication. |
| Authentication | Managed identity provider with an email allowlist, role assignment, and route-level enforcement on the server. |
| Documents | Server-side rendering of templates, signature capture, countersignature, and durable storage of the executed artifact with its audit trail. |
| Assist | Claude, running bounded tool use over the structured model and the live database, with the sources of each answer surfaced in the interface. |
| Hosting | Deployed to your cloud account or ours. Either way you own the code and the data. |
A dashboard earns trust slowly and loses it in one wrong number, so a few things are deliberate:
We phase deliberately, because the first release has one job: prove that the numbers on screen match the numbers the client already trusts.
A single-rooftop build with one clean data source reaches a useful first release considerably faster than a multi-brand group consolidation. Scope is set after assessment, and priced against it.
It is built for you. We bring a proven architecture and a set of modules we have built before, which is why the work is measured in weeks rather than years, but the account structure, the pay plans, the metric definitions, and the integrations are yours. You own the resulting code.
DMS reporting answers questions about the DMS. It is generally accurate, generally late, and generally confined to one store and one system. The platform sits above every source you have — DMS, CRM, inventory, lender, reinsurance — applies one set of definitions across rooftops, and adds the layer the DMS does not have at all: a model you can ask what-if questions of.
Yes. Role-based access is built in. A stakeholder sees a curated set of pages with no ability to write anything, and pages outside that set are not reachable even by URL. Which pages a stakeholder role can see is your decision and is changed in one place.
Standard deployments load nightly, which is what most dealership source systems realistically support and is enough for the decisions this platform is used for. Where a feed supports it and the use case justifies it — inventory age and service drive throughput are the usual candidates — we run those loads more frequently.
Adding a store means mapping its chart of accounts to the existing definitions and standing up its extracts. It is scoped work, not a rebuild, and that is specifically what the definition layer is for. Groups that expect to acquire should say so during assessment so the consolidation is built for it from the start.
It is constrained not to. It answers by reading the computed model along defined paths or by re-running the engine, and it shows what it read and what it ran underneath each answer. Where a result genuinely cannot be computed for the question asked, the system prompt and the tooling both require it to say so rather than infer.
Hosting, the identity provider, and the data warehouse for a single group are modest — typically a few hundred dollars a month at dealership data volumes. Assistant usage is metered and small, because the panel runs a mid-tier model with the conversation cached rather than a frontier model on every keystroke. Ongoing support is a separate arrangement sized to how much change you expect.
Most dealerships are one integration away from answers they are currently reconstructing by hand. Let's find out which ones.
Schedule a Consultation
K Auto Tech