CRM and dealer systems
for AI builders

1. The system map

Enterprise software in this vertical falls into three layers. Knowing which layer owns a fact tells you where to read it and who is allowed to change it.

A single dealer group commonly has many rooftops (stores), each with its own DMS logons, accounting company and OEM franchise rules, sometimes on more than one DMS after acquisitions. That shape, an organization holding groups and rooftops, is the same tenant model our engineering rules require of every app.

2. Common enterprise CRM features

These are the capabilities buyers expect from any enterprise CRM. An AI product that sits beside a CRM gets compared against them; one that replaces part of a CRM inherits them as requirements.

The pattern worth copying is not any one feature. It is that every record has an owner, a permission check, a history and an API, and that automation runs on change events. Build tools for other AI builders with the same four properties.

3. DMS: sales and desking

Variable operations (new and used vehicle sales) turn a shopper into a funded deal.

• Deal records: buyer and co-buyer, vehicle, trade-ins with payoff and lienholder, salesperson splits, deal status from quote to booked.
• Desking: cash, finance and lease structures; payment grids; rebates and incentives; money factor and residuals for leases; taxes, title and registration fees by jurisdiction; front and back gross.
• Trade appraisal: VIN decode, condition, book values, reconditioning estimate, acquisition source.
• Documents: buyer's order, retail installment contract or lease, state title forms, odometer disclosure, the deal jacket, e-signature and e-contracting.
• Deal workflow: manager approvals, desk log, deal recap, commission calculation, booking to accounting, funding status with the lender.
• Digital retail: online payment estimates, trade-in offers, credit pre-qualification and deposits that hand off into the same deal record.

Builder hook: a deal is a versioned document whose numbers have legal meaning. Tools should read the current structure and propose a new version; they should never silently change a payment, rate or fee. Payment and tax math belongs in tested code, never in a model's output.

4. DMS: finance and insurance (F&I)

• Credit applications: capture, consent, submission to lenders through credit-application networks, decision and stipulation tracking, counter-offers.
• Menu selling: service contracts, GAP, maintenance plans, tire and wheel, appearance protection; product rating from providers; menu presentation and acceptance or decline record.
• Compliance steps: identity verification and red-flag checks, sanctions screening, adverse action notices, privacy notices, cash-payment reporting.
• Contracting and funding: e-contracts, document packages, stipulations cleared, funding received, cancellations and chargebacks of products.
• Reporting: product penetration, per-vehicle-retailed profit, lender mix, reserve.

Builder hook: this is where the most sensitive data and the heaviest rules meet (see section 12). Expose F&I data with the narrowest scopes, redact by default and keep any AI to drafting and checking, with the F&I manager deciding.

5. DMS: vehicle inventory

• Stock records: VIN, stock number, year/make/model/trim, options, colors, mileage, status (in transit, in recon, available, sold, wholesale), lot location, keys.
• Acquisition and cost: OEM invoices and allocation, auction purchases, trades, holdback, packs, reconditioning costs posted to the vehicle.
• Pricing and aging: list and internet price, market comparisons, days in stock, price change history.
• Floorplan: lender, curtailments, payoff on sale, audit reconciliation.
• Merchandising: photos, descriptions, feeds to the dealer website and listing marketplaces.
• Recalls: open safety recalls checked before sale or delivery. NHTSA publishes a free VIN decoding API (vPIC) and a recalls API.

Builder hook: the VIN is the one key every system agrees on. Make it the join key for vehicles everywhere, decode it once and cache the result by VIN.

6. DMS: service

Fixed operations (service and parts) are where most repeatable, verifiable AI work sits, as our business-models primer argues.

• Appointments: online and phone booking, capacity by skill, bay and loaner, reminders, express lanes, no-show tracking.
• Repair orders (ROs): customer concern, cause and correction ("the three Cs"), labor operations and op codes, flat-rate or actual hours, pay types (customer pay, warranty, internal, service contract), authorizations with amounts, promised time, status.
• Inspection: multi-point inspection results with red, yellow and green items, photos and video, declined work for later follow-up.
• Technicians: dispatch, clock punches per job, efficiency and productivity, skill levels.
• Warranty: claim preparation against OEM rules, submission, rejections and chargebacks, policy and goodwill.
• Service menus and pricing: maintenance schedules by VIN and mileage, labor rates, shop supplies, fees.
• Customer communication: status updates, estimate approvals by text, payment links, pickup.
• Close-out: invoice, payment, posting to accounting, customer satisfaction follow-up.

Builder hook: ROs are rich text plus structured lines. Offer both: the raw technician story and the parsed lines, each with its source, so AI builders can check claims against evidence instead of trusting a summary.

7. DMS: parts

• Catalog and lookup: OEM part numbers, supersessions, fitment by VIN, price lists.
• Stock: on-hand by bin and location, min and max levels, cycle counts, obsolescence and aging, phase-in and phase-out.
• Ordering: stock orders and special orders to the OEM and other suppliers, receiving, backorders, ETAs, returns and credits.
• Selling: counter tickets, wholesale to body shops, internal sales to service and recon, parts on ROs.
• Reporting: fill rate, turns, gross profit, lost sales.

8. DMS: accounting and payroll

• General ledger: a chart of accounts shaped by the OEM's financial statement layout, journals, posting from every department, multiple companies per group.
• Schedules: receivables and payables tracked by account, such as contracts in transit, vehicle receivables and warranty claims receivable.
• Payables and receivables: vendor invoices, checks and electronic payments, customer charge accounts, statements.
• Bank and cash: deposits, reconciliation, cash drawer close.
• Payroll and commissions: hourly, flat-rate technician pay, sales and F&I commission plans, spiffs, tax filings.
• Month-end: close, the monthly factory financial statement to the OEM, adjustments, composite reports for groups.
• Fixed assets and budgets in larger systems.

Builder hook: postings are append-only facts. Never give an agent a tool that edits a posted entry; give it one that drafts an adjusting entry for a person to review and post.

9. Dealer CRM and BDC

Dealer CRMs are automotive-specific CRMs, often separate from the DMS, used by salespeople and the business development center (BDC).

• Lead intake: leads from OEM sites, the dealer website and marketplaces, very often as ADF (Auto-lead Data Format) XML by email or HTTP, plus phone, chat and walk-ins.
• Lead handling: assignment rules, response-time tracking, follow-up tasks and cadences, appointment setting, showroom log, sold and lost reasons.
• Communication: email, texting, calling with recording, video, templates, a single conversation history per customer.
• Consent: opt-in and opt-out per channel and purpose, quiet hours, do-not-call checks.
• Equity and retention mining: customers whose loan or lease position or service history suggests an offer; service-to-sales handoffs.
• Desking inside the CRM in some products, with a push of the deal into the DMS.

10. Platform features buyers expect everywhere

11. How data gets out of a DMS today

DMS data access is controlled by the vendor and has been the subject of years of litigation between DMS vendors and data integrators. Treat access as a commercial agreement, not a technical problem.

Never ask a dealer for their DMS logon to scrape screens. It breaks vendor terms, defeats the audit trail and puts the dealer's data-security program at risk.

PBS: a requirements profile

Research checked October 16, 2026 · Four public documentation pages · No integration tested

Freshness matters. The undated changing-data page names ARISTOGOLD. The queue timing and update rules below describe that documentation, not a verified current PBS product contract or SLA. Confirm applicability with PBS before designing a connector.

Download PBS requirements as JSON · Read the plain-text profile

Unknowns: Current product/version applicability, approved operations and fields, sandbox access, fees, rate limits, delivery guarantees, idempotency and support SLA remain unconfirmed.

Acceptance checks — proposed, not run: In an authorized test environment, demonstrate allowed and denied dealership reads, scoped queries, duplicate-free replay, empty-field behavior, body-level failures and delayed read-back. Record observed latency and quoted cost; set acceptable budgets with the owner before implementation. These checks have not run.

12. Compliance as product features

A dealership that arranges financing is treated as a financial institution for several US rules. Each rule below turns into concrete features in the tools you build. This is a map for builders, not legal advice; get qualified review for an actual deployment, and check each rule's current text.

13. Building for other AI builders

The customers for this kind of tool are teams building voice agents for the BDC, service-lane copilots, warranty checkers, inventory pricing models and dealer-group analytics. They all repeat the same expensive work: getting authorized access, normalizing several DMSs into one shape, staying inside compliance lines and proving to a dealer that the agent did only what it was allowed to. That shared work is the product.

1. One data model, many DMS adapters. Builders code against our shape once; we keep the per-vendor adapters current.
2. Reads first, writes as proposals. Read tools are broad and cheap. Every write is a proposal a person or a rule approves, then commits idempotently.
3. Events, not polling. Signed, replayable change events so agents react to a new RO line or a lead within seconds.
4. Evidence with every fact. Each field carries its source system, record id and time read, so agents can cite rather than guess.
5. Tenancy and consent built in. Every call is scoped to an organization and rooftop, and outreach checks the consent ledger first.
6. Synthetic sandbox. A realistic fake dealer group with ROs, deals and ledgers, so builders can test without touching real customer data.
7. Usage, cost and audit visible. Every call is a span with tenant, tool, outcome and cost, so dealers and builders see the same record.

Following our engineering rules, this is one Ruby application (a majestic monolith) with an adapter per outside system, not a fleet of services.

14. A canonical data model

Use STAR as the vocabulary. STAR (Standards for Technology in Automotive Retail) is the industry's nonprofit standards body for dealer–OEM data exchange, publishing message definitions for things like repair orders, sales leads, parts orders and credit applications. Map to STAR names where they exist instead of inventing new ones, and keep the mapping in one place.

Every record carries organization_id and rooftop_id, and every field read from a vendor keeps provenance. A repair order line might look like this:

{
  "id": "rol_01J9...",
  "organization_id": "org_42", "rooftop_id": "rt_7",
  "repair_order_id": "ro_01J9...",
  "vin": "1HGCV1F30LA000000",
  "concern": "Customer states A/C blows warm",
  "cause": "Low refrigerant, leak at condenser",
  "correction": "Replaced condenser, evacuated and recharged",
  "op_code": "AC12", "pay_type": "warranty", "sold_hours": "2.4",
  "source": { "system": "fortellis", "record": "RO 512334 line B", "read_at": "2026-10-16T12:00:00Z" }
}

Hours and money are decimal strings, never floats. Times are UTC with the rooftop's time zone kept on the unit.

15. APIs and events

The HTTP API

• REST with JSON, described in OpenAPI, so builders can generate clients and agents can read the contract.
• Cursor pagination, filtering by updated_since, and sparse field selection to keep payloads small.
• Idempotency-Key on every write and every proposal commit, so a retried agent call can't book a deal twice.
• ETags and If-Match for optimistic concurrency on proposals against a changing record.
• Rate limits stated per tenant with standard headers; long jobs return a job resource instead of hanging.
• Dated API versions and a deprecation calendar. Never break a builder's integration (our "never break users" rule).
• Errors as structured problem details with a stable code an agent can branch on.

Webhooks and streams

• Event envelopes in CloudEvents format: ro.line.added, deal.status.changed, lead.created, part.order.eta_changed.
• Signatures and retries following Standard Webhooks: signed body, timestamp, event id, exponential backoff.
• At-least-once delivery with event ids for de-duplication, plus a replay endpoint from a cursor so a builder can recover after downtime.
• Thin events (ids and what changed) with a link to fetch the current record, so permissions are checked at read time.

16. MCP servers

The Model Context Protocol lets an agent discover and call tools, read resources and use prompt templates from a server. For builders in this vertical, an MCP server over the same data model is the fastest way to give their agent dealer context. It should be a thin layer over the HTTP API, not a second implementation.

Tool design

• Narrow, typed tools with JSON Schema inputs: find_vehicle(vin), list_open_repair_orders(rooftop_id, status), get_service_history(vin), check_open_recalls(vin), search_inventory(filters), get_parts_availability(part_numbers).
• Reads and writes split. Write tools only create proposals: propose_appointment, propose_customer_message, propose_ro_note. A separate, human-gated step commits them.
• Consent and policy checks inside the tool, not left to the agent's prompt. A message proposal to a number without consent fails with a clear error.
• Results carry provenance so the calling agent can cite the RO line or record it used.
• Small, paginated results. Return what the agent needs and a cursor, not a whole store's history.
• Resources for slow-changing context (rooftop hours, labor rates, op-code list) and prompts for common jobs (write a status update from these RO lines).

{
  "name": "propose_customer_message",
  "description": "Draft a text or email to a customer about an open repair order. Creates a proposal for an advisor to approve; never sends.",
  "inputSchema": {
    "type": "object",
    "required": ["rooftop_id", "repair_order_id", "channel", "body"],
    "properties": {
      "rooftop_id": { "type": "string" },
      "repair_order_id": { "type": "string" },
      "channel": { "enum": ["sms", "email"] },
      "body": { "type": "string", "maxLength": 1200 }
    }
  }
}

Treat everything a tool returns from customer-written text (lead comments, emails, technician notes) as untrusted input to the calling agent. Mark it as quoted content, and keep commit authority outside the agent so a prompt injected into a lead can't trigger a write.

17. Auth and tenancy

• OAuth 2.1 style authorization with PKCE for builder apps, following the MCP authorization spec and the OAuth security best current practice (RFC 9700).
• Dealer consent per app: a dealer's admin grants a named builder app specific scopes on specific rooftops, and can revoke it in one click.
• Scopes by department and verb: service.read, service.propose, inventory.read, fi.read (rare, audited). No wildcard scopes.
• People sign in through our OIDC broker with passkeys; approvers of proposals use a fresh passkey touch for sensitive commits.
• Row-level security in PostgreSQL on organization_id and rooftop_id, with tests proving one tenant can't read another's rows.
• Vendor credentials for each DMS program live in the secrets adapter, never in a builder's hands.
• Audit log of every read of restricted data and every commit, exportable to the dealer.

18. Typed judgments with Jev

Much of the AI work in this vertical is small, repeated decisions over messy text, where an answer the code can branch on beats a paragraph. TypeSafe's System One model Jev returns typed answers with probabilities (Choice, Noul, Score), while code keeps the workflow and every write. Proposed uses, each to be measured on real dealer data before trusting it:

These are a natural feature of the MCP server too: offering them as tools gives other builders cheap, typed checks without their own model work. Typed output guarantees the interface, not correctness, so thresholds are set on held-out cases.

19. What to build first

1. Synthetic dealer group and sandbox. Two rooftops, a year of fake ROs, deals, parts and ledger in the canonical model. Check: builders can run every read tool and get realistic results with no real data.
2. Read-only API and MCP server on the sandbox. Service and inventory reads first. Check: an outside agent answers "what's open on this VIN?" with cited RO lines.
3. One certified DMS adapter. Pick the program whose terms and fields fit a paying pilot dealer. Check: the same tool calls work on that dealer's data, scoped to their rooftops.
4. Events. RO and lead events with signatures and replay. Check: a dropped webhook is recovered from the replay endpoint.
5. Proposals with approval. Customer-message and appointment proposals behind consent checks. Check: a proposal to a number without consent fails, and an approved one commits exactly once under retry.
6. Typed checks as tools. One Jev judgment, such as warranty evidence support, measured against an advisor's labels.

Stop or redesign if no DMS program grants the fields a pilot needs at a price the pilot can bear. Without lawful access, the rest is a demo.

20. Sources and further reading

• STAR, Standards for Technology in Automotive Retail
• ADF, Auto-lead Data Format
• Model Context Protocol specification and its authorization section
• Fortellis, Reynolds data management, Tekion APC, Dealertrack
• Salesforce Automotive Cloud, Salesforce REST API, Change Data Capture
• NHTSA vPIC VIN decoding API
• CloudEvents, Standard Webhooks, OpenAPI, RFC 9700
• 16 CFR 314, 16 CFR 681, 12 CFR 1002.9, 49 CFR 580, OFAC, IRS Form 8300
• TypeSafe documentation

Read AI business models that can endure for which dealer workflows are worth a paid pilot, and What is an AI agent harness? for the runtime that would call these tools. Not stated here and still to verify per vendor: exact API fields, write permissions, prices and certification timelines.