Release notes

You can now give your own AI assistant access to your dealership account. Not our copilot inside our app — your assistant, in whatever window you already use it, working on your data through the same rules your staff work under.

Setup takes about ten minutes and is written up at Connect your AI assistant.

What it can do

Fifteen tools. Eight of them only look: search contacts, open a contact, list deals, open a deal, list appointments, pull a call, check the org's status, and check whether there is a lawful basis to contact somebody before doing it.

Seven of them act: create and update a contact, log an activity, move a deal stage, book an appointment, send a text, and place an outbound call.

So "which of my leads from last week never got a second call" is a question you can now ask in plain English and get answered from your actual records, and "text the three of them and book anyone who replies" is a thing you can ask for next, once you have decided you trust it.

The key decides which store it can see

You create a key in Settings, and the key is what says which account the AI is working in. Nothing in any request can select a different store, because the store is read off the key. There is no key that sees two accounts.

Start read-only. A read-only key lets the assistant look at everything and change nothing, and watching it work for a few days before it can text anybody is a sensible order to do this in. Add a second key with write access when you are ready, and revoke either in one click.

Texts and calls go through your existing rules, not around them

This is the part worth understanding, because it is where a connector like this usually goes wrong.

When the AI sends a text or places a call, it does not send it itself. It goes to the same place the buttons in the app go to, so the consent check, the calling hours, the wallet balance, the number rotation and the AI disclosure all run once, in the same order, with the same answers. There is no second copy of that logic that can drift, and the first drift nobody notices is the one that texts somebody at three in the morning.

An assistant can therefore place a compliant call. It cannot override a compliance warning the way a manager can — that door is simply not there for it.

One rule applies to the AI and not to your staff. Marketing texts and AI marketing calls need an actual consent record. The assistant is allowed to say a message is transactional, but that claim is checked against a real appointment, a real deal, or a message the customer sent you first. An exemption a model can type is not an exemption.

You can see everything it did, including what it was refused

Every tool call writes a line: which key, which tool, when, and what happened. Refusals are written down too, and they are the half worth reading — the log answers "what has this thing been doing on my account, and what did you stop it from doing".

The arguments are not stored. They carry message bodies and customer phone numbers, so a fingerprint of them is kept instead of the text.

There are per-account ceilings on how much calling and texting a connector can do, counted across the whole store, so adding a second assistant does not double how many strangers an AI can dial.

The honest limits

Texting and calling from a connector are off until switched on for your account — reads work without it. When the AI is refused something, it is told why and what would fix it, in a form it can repeat to you, rather than being handed an error that makes it tell you the integration is broken. And an assistant working from your records will still be confidently wrong sometimes; the read-only key exists so you can find out how often before it can act.

There were 137 live consent records across 31 stores when this was checked. Not one of them was consent to marketing texts. That was not because nobody had ever ticked the box — it was because nothing in the product could produce that kind of record.

What was actually happening

Three capture paths, three different ways of losing the same information.

A lead arriving from a website form was recorded as transactional consent no matter what the page had asked. If your form said "yes, send me offers", it was written down as agreement to be contacted about the car they had just enquired about.

The CSV importer offered one consent column, and mapped it to voice marketing. Whatever the spreadsheet said, texts were not covered.

The only path that could produce a marketing SMS record was a per-contact attestation window, and nobody has ever used it.

None of this looked broken from either end. You ticked a box, you got a consent record, and the record was there when you looked. It just did not say what you thought it said.

The one place it showed up was on the AI side, and it showed up as the AI being wrong. The agent path will not market to anybody without an affirmative marketing consent record, so it refused every contact in every account. It was refusing correctly, against evidence that had been quietly downgraded on the way in.

What it does now

A website form can send voice marketing and SMS marketing consent as their own fields, each with the exact sentence the customer agreed to, and each is recorded as its own kind of consent.

Marketing consent is never inferred from a transactional tick. Agreeing to hear about the car you just asked about is not agreeing to be sold to next quarter, and the law prices that difference. This is the same rule already applied between voice and text, for the same reason.

A marketing tick that arrives with no wording attached is dropped rather than filed against the transactional sentence. That may look strict. Evidence of the wrong agreement is worse at an audit than no evidence, because it reads as a claim your page cannot support.

A form that sends none of these fields behaves exactly as it did before.

The importer now maps all four kinds — voice transactional, voice marketing, SMS transactional, SMS marketing — instead of one.

The box on your own site is off until you turn it on

Lead Friendly dealer sites can now show a marketing opt-in box next to the existing one. It is off by default and no live dealer page has changed.

That is deliberate, and it is about money rather than caution. The wording on that box is new, and a carrier reviewer grades it against the messages your brand actually sends. That review costs $15 each time it is submitted, including resubmissions. So a store should turn the box on when its 10DLC campaign already covers promotional traffic, not before.

The copy itself carries your brand name, its own message frequency, the message and data rates line, STOP and HELP, "not a condition of purchase", and the statement that numbers are not shared — in English and Spanish, matching the transactional box beside it.

It does not fix the past

This records consent from here forward. It cannot go back and turn the existing 137 records into something they were not, and it must not: a consent record that was manufactured after the fact is not evidence of anything. Your existing contacts stay exactly as they are, and the AI will keep declining to market to them until somebody actually agrees.

The book-out sheet has always printed a number somebody typed. This is the plumbing for a day when it prints a number a book quoted — and an honest account of how far off that day still is.

Nothing you see changes today

The product does not pull live book values. There is a Kelley Blue Book provider in the code now, written against their InfoDriver sandbox, and the sandbox is all it can reach: the production hosts refuse us because the agreement is not signed. Sandbox figures are roughly six months out of date and come back carrying KBB's own notice that they are not a real valuation.

So the book-out sheet is untouched. No screen shows a fetched number, no submission carries one, and nothing you do on a deal behaves differently than it did last week. If you want a book value on a sheet today, you still type it in.

That the sheet is untouched is the point of the work, not an omission from it.

Why the plumbing was worth doing first

Two reasons, both of them about your deals rather than about the code.

The first is that no single book satisfies two banks. Lendmark advances against J.D. Power, Reliable Credit prefers KBB and takes nothing else, and a store that sends the same car to both needs both numbers on the same deal. So the setting that decides which book answers lives on the lender, not on the store. That is already how your lender directory is shaped; the valuation side now matches it.

The second is that KBB's own service is being retired. InfoDriver is going away in favour of a newer one, targeted for the end of 2026 and already slipping. Building against it directly would mean doing this whole job twice. Behind a seam, the switch is one file.

Two things it refuses to guess

Clean retail, average retail and rough trade can be thousands apart on the same car, and a lender advances against one of them specifically. So a fetched value never picks a category on your behalf — the caller has to say which figure it is printing. A sheet that guesses what it is printing is worse than one that says it does not know.

And when a book does not quote a particular figure, that figure comes back empty rather than filled in with the nearest one the book did quote. A sheet headed "rough trade" carrying an average trade number is a document a lender makes decisions on.

Same rule on a VIN that decodes to several trims: you get the list of possibilities, not whichever one sorted first.

The lending value question, stated plainly

Lending value — what a bank will advance against — and typical listing price are both returned, and neither is treated as a book value. They are their own fields with their own headings, because a lending value is not a retail figure and filing it as one would quietly change what every existing deal's stored answer means.

There is an unresolved disagreement about showing the lending value at all. KBB's display requirements prohibit publishing lending value and auction value outside internal use. Cox's own product team told us in writing on 9 September that lending value belongs on a book-out sheet. Those cannot both be followed, so the lending value is fetched and held but not printed unless a specific approval flag is set, and the conflict is on the list of things to settle in the contract rather than resolved by whichever reading is more convenient.

Auction value is not mapped onto the wholesale figure for the same reason. They are different numbers, and treating one as the other on a document a lender reads is the kind of shortcut that gets noticed later.

Everything this system did with a credit application before today ended with a person carrying it: an email draft somebody read and sent, a set of fields somebody typed into RouteOne. There is now a rail built to send it directly.

Read the next paragraph before you read anything else.

What this is, and what it is not

This is built against the Dealertrack API and is in certification with Cox. It is not live, it is not connected to a bank, and no real customer's application has gone through it. Every environment is set to Dealertrack's sandbox, and no live call has ever completed. The wiring, the field mapping, the refusals and the logging are written and tested; the send itself is documented, not proven.

When it does carry a real application, the first one should be watched by a person, and this note will be replaced by one that says so.

A person approves every submission, three separate ways

A credit application leaving the building puts a hard inquiry on somebody's bureau file. That is not recoverable, so the path is deliberately hard to fire by accident.

The request has to carry an explicit confirmation flag — it is never assumed from the fact that a request arrived, so a stale browser tab or a copied command sends nothing. The lender has to be marked as an API lender in your lender directory; that is a separate setting, not a loosened default. And the submit button takes a second deliberate click, but only for this channel. Recording a submission you emailed or faxed yourself still takes one click, because a confirmation people dismiss by reflex is worse than no confirmation.

There is no queue, no retry, no cron and no background job anywhere on this path. "Try again automatically" would mean a second hard inquiry on somebody's credit report that nobody asked for.

The same application cannot go to the same lender twice over the API. If it is tried, you get the first submission's reference back and a sentence explaining it, rather than a second inquiry. Submissions you hand-carried are unaffected — if you emailed Lendmark twice, you did in fact send two emails.

Everything sent and received is kept, with the sensitive parts removed

When a lender says an application is wrong, the first question is what exactly was sent. Both sides of every exchange are recorded — but the social security number, date of birth, driver's licence and income are stripped out of the copy first, on the way in and on the way back. A lender echoing the applicant back at us would otherwise smuggle the SSN into a table nobody thinks of as holding it.

Phone number and email are deliberately left readable. Hiding them would be for show, and would make the log useless for the most common real failure, which is a wrong phone number.

Decisions arrive on their own, and you can also just ask

When a lender answers, the answer lands on a callback and updates the deal: status, approved amount, rate, term, tier, stipulations, decline reasons, and the analyst's message.

A callback is a promise about a network, and every way one quietly fails looks identical from the desk — the bank has gone quiet. So there is also an Ask the lender button. It fetches the current decision on demand. Nothing polls: no interval, no cron, no background job. It is a read at the far end, so nothing reaches the lender, no application moves and no credit is pulled, which is why it needs no confirmation step of its own.

A pushed decision and a fetched one go through the same reader, so the two can never disagree about what a number means.

One outcome is deliberately left unmapped. A counter-offer — the bank will lend, on different terms — has no equivalent in our vocabulary, and calling it "approved with conditions" would send a desk down the wrong path. It is recorded with the lender's own word visible and a note to look at the deal by hand.

Before a lender, a bureau or a data provider tells you something about one of your customers, somebody has to have that customer's permission. You already know that. What you did not have was anywhere to say so, or anything showing that you had.

Now, the first time you send a customer's application out to a lender, a short notice appears with the reason stated plainly above a single box:

Sending this application forwards the customer's personal and financial information to each lender you select. Confirm they have authorised you to submit it on their behalf.

Tick it, and the submission continues. We record who confirmed it, when, for which customer, what the request was, and the exact wording you agreed to — so if a dealer's practice is ever questioned, the answer is a record rather than a recollection.

It does not nag. One confirmation covers that customer for the rest of the working day, so shopping one deal to four banks asks you once. A box that appeared four times in five minutes would stop being read, and a control nobody reads is not a control.

It cannot be edited or deleted afterwards. That is deliberate: the value of the record is that nobody could adjust it once the question was asked.

The same notice is ready for payoff quotes, credit bureau pulls and data purchases as those arrive — each with its own reason, because the reason is the part that matters.

Until today there was exactly one way to start a credit application: open a customer you already had and press the button. A walk-in you had never met meant typing them into the CRM first, and if they were already in there under a slightly different name, the store now had two of them — with the deals, the message history and the previous application on the one nobody was looking at.

The gate

Dealership → Credit review now opens with Start an application, and the first thing it does is search.

Pick Individual or Business, type the name, press Search. You get back everyone who might be them, with enough beside each one to tell them apart: phone, email, town, and how many credit applications they already have and when the last one was. That last column is usually the answer — two Robert Smiths are two people, and only the one with an application from March is the Robert Smith standing in the showroom.

Then either use this customer, or say none of these and start a new record.

"None of these" is still checked

Saying none of these does not create a duplicate on its own. Behind the button, the phone number and email you typed run through the same matching every web lead and every website application already uses — last ten digits, so formatting differences do not matter. If they hit an existing customer, the application goes on that record and the screen tells you so, rather than quietly doing the right thing somewhere you were not looking.

This is why a phone number or an email is required to start a new one. Without either, there is nothing to tell this customer from the next person with the same name, and "create" would mean "create" every single time.

Business applicants

Choose Business and the application changes shape. The borrower is the company:

• Legal business name — what goes on the contract.
• EIN, entered by the customer on their own link.
• Type of business — LLC, corporation, S corporation, sole proprietorship, partnership, non-profit or trust. A list, not a text box, so your applications do not carry three spellings of "LLC".
• Time in business, in years and months.
• The owner or officer who signs, with their own name, SSN and income — the lender checks their personal credit as guarantor.

A second signer on a business application is recorded as an additional guarantor, not a co-applicant. They are different things: an adverse-action notice is owed to an applicant and not to a guarantor.

The customer's link, the review screen and the printed application all follow the choice. A sole trader buying a truck in their own name never sees an EIN box they have to work out they should ignore.

The EIN is treated like a Social Security number

Because it is one. An EIN is a taxpayer identification number, and a sole proprietor is entitled to use their own social as their business's — so the same nine digits can arrive in either box.

It is encrypted, it never appears on the credit review screen, and there is no "last four" anywhere. It prints on the dealer's copy of the application — the one your finance manager keys into a lender portal — and that print writes a line to the PII access log, exactly as printing an SSN already does. The customer's own printable copy leaves it as a blank line to fill in by hand.

A sole proprietor may not have one

We do not require an EIN from a sole proprietorship, because the IRS does not either. Their SSN is the business's taxpayer number, and demanding an EIN would have got a placeholder typed into the field. Every other entity type has to provide one before the application can be signed.

A dealership computer sits on a sales floor, and it gets walked away from. Until today it could be walked away from with a credit application on screen — name, date of birth, social security number, driver's licence — and it would still be there an hour later for whoever wandered past the desk.

Four screens now sign themselves out when nobody has touched the machine for 30 minutes:

• Contacts and any customer's record
• Dealership → Credit — the credit application
• Dealership → Documents and the deal jacket behind it
• The documents inside a deal

You get two minutes' warning

At 30 minutes idle a box appears saying you are about to be signed out, with a countdown. Press Stay signed in and you carry straight on — the page behind the box never went anywhere, so a half-filled application is exactly as you left it, in the same box, with the same cursor.

The box also says the thing it would be dishonest not to say: anything you have typed and not saved will be lost. Two minutes is enough to press Save first.

Nothing else in the app logs you out

This is deliberately not an app-wide timeout. A manager can leave the dashboard, a report or the inventory list up all afternoon and nothing will happen — those screens do not have somebody's personal details on them, and being thrown out of a screen you were reading is its own kind of broken.

Typing counts. A wobbly desk does not

The clock measures time since you last clicked, typed, scrolled or tapped — not time since you opened the page. Somebody who has been working through an application for 45 minutes straight is never interrupted.

Moving the mouse is deliberately not enough on its own. On a sales floor a bumped desk or somebody leaning on the counter will nudge a cursor, and a machine that keeps itself signed in because the desk wobbled is not protecting anything.

Nor does the app keep itself alive: pages on this platform refresh their own data in the background every minute or two, and none of that counts as you being there.

Two screens open at once is fine

If you have a customer's record on one monitor and are working in another tab, the record does not expire underneath you. Working anywhere counts as working, and the timeout only ends the session when every window has gone quiet. When it does, every tab clears at the same moment rather than one of them sitting there still showing the customer.

Thirty minutes, and it is not adjustable

Thirty minutes is the number Dealertrack uses, so it is the one most people on a dealership floor already have a feel for. It is fixed on purpose — a timeout a store can set to eight hours is a timeout that has been switched off, and this is the kind of control that is only worth having if it is the same everywhere. If 30 minutes genuinely does not fit how your store works, tell us; that is a conversation worth having with a real example in it.

Until now, finding out that something on the platform was misbehaving meant noticing it yourself, trying it twice more, and then emailing us. By the time anyone answered, the morning was gone.

There is now a bar at the top of every page for the times something genuinely is wrong. It carries four things:

• What is broken, in plain words — "credit applications are not reaching lenders", not "the submission queue is backed up".
• Who it affects. Most problems touch one workflow. If it is not yours, you can read the bar and carry on with your day.
• What to do meanwhile, when there is something — submit through the lender portal directly, print the sticker from the vehicle page instead. When there genuinely is no workaround, it says nothing rather than inventing one.
• How bad it is — maintenance, degraded, or an outage.

The all-clear

When it is fixed, the bar turns green and tells you so, and says whether anything needs redoing.

You get the all-clear even if you dismissed the original notice. Closing the red bar to get your screen back does not opt you out of the good news — that would leave you working around a problem that no longer exists, which is the whole failure this is meant to prevent. The green bar shows once and dismissing that one is final.

Dismissing it sticks

Press the X and it stays gone — on your phone, on the desk machine, tomorrow morning. It is remembered against you, not against your browser and not against your store, so shutting it does not shut it for the sales manager and clearing your cookies does not bring it back.

Most days it is not there

A notice like this is only worth anything if it is rare. When nothing is wrong, there is no bar and nothing moves down the page.

Most people who look at a car on your website are not going to buy it today. Almost all of them leave without telling you anything.

There is now a button under the call and test-drive buttons on every available vehicle that has an advertised price: 🔔 Tell me if the price drops.

What they give you, and what it costs them

A short form — first name, email, mobile — and one consent box. Either an email address or a mobile is enough. They do not have to give both, and most will give one.

They become an ordinary contact in your CRM with a lead source of price watch, so they show up in your people list, your reports and your pipeline like any other lead. Their name on the watchers list goes straight to their conversation thread.

Texts are confirmed twice

Typing a mobile brings up a second, separate, optional box offering text alerts. Ticking it does not sign anybody up for texts. It buys exactly one message — "reply YES to get a text if the price drops on the 2021 Toyota RAV4 XLE" — and nothing else is ever sent to that number until they reply.

If they never reply, your list says Text: awaiting reply and they get email only. That state is shown rather than hidden on purpose: a number stuck there usually means the confirmation was stopped by quiet hours or an existing opt-out, and they are waiting on a text that is not coming.

A phone number typed into a web form is the weakest evidence in messaging. The reply is what carriers and the FCC credit, and it is what keeps a campaign approved.

The notice fires on all three ways a price moves

You edited it on the vehicle. You used Update prices on a multi-select in the inventory report. Or the overnight markdown schedule did it while nobody was awake. All three go out. A price rise sends nothing.

Three things stop a notice — deliberately

They already know that price. Once somebody has been told $18,995, that is the number a new price has to beat. A car cut, put back up by a manager and cut to the same figure again has given the shopper no new news, and $18,995 twice in a week reads as a system that is broken.

The frequency floor. By default nobody hears from you about price more than once every 72 hours, however many times a price moves. A store running the standard five-step schedule could otherwise text the same person on consecutive nights, and somebody annoyed into replying STOP is lost for every car on the lot, not just this one. Change it on Dealership → Vehicle pricing.

Quiet hours, opt-outs and the DNC list. Price alerts go through exactly the same compliance path as every other message you send — there is no second send route and no shortcut for "it's only a price". A message stopped this way is recorded with the reason, so "nobody told me" always has an answer.

Getting off it

Every email carries a link that stops that one watch, not all your email and not the other cars they are watching. Every text carries STOP. And on Dealership → Price watchers you can take somebody off yourself when they phone in and ask.

Most stores mark aged cars down on a rule they carry in their head: $500 at a month, again at six weeks, again at two months. Dealership → Vehicle pricing → Automatic price reductions is that rule, written down and running itself.

Your store already has a schedule: $500 off at 31, 45, 60, 75 and 90 days on the lot. Change it, pause a step, add your own. Nothing happens to any car until you tick Reduce prices automatically on this schedule — a written schedule and a running one are different things, and the tick is the difference.

The floors come first

A markdown schedule with no floor is a countdown to selling at a loss. There are two, both checked, and the higher one wins:

• a minimum margin over cost, set once for the store;
• a floor price on an individual vehicle, for the one car you know something about.

When a floor blocks a reduction we open a high-priority task naming the price that was refused and the floor that refused it. That car has aged past what the schedule can fix, and it needs a decision from you — wholesale it, lower the floor, or accept where the price is. Going quiet about it is how a car sits for another month.

One thing worth knowing: the margin floor can only protect a vehicle whose cost you have recorded. If your cars arrive from a feed without cost, the per-vehicle floor price is what protects those.

Switching it on does not dump your whole lot

We record the moment you turn the schedule on, and steps your cars had already passed before then are skipped rather than applied. A 100-day car on a 31/45/60/75/90 schedule does not lose $2,500 the first night. It takes its next step when it reaches one.

You see it before it happens

What drops next, on the same page, lists every vehicle the schedule will reduce tomorrow night, what it is advertised at now, and what it becomes. The night before, the new Price reductions due tomorrow notification goes to whoever you route it to under Settings → Notifications.

To stop one: pause the step, or put a floor price on that vehicle.

What it will never do

• Reduce a sold car, one with a deal pending, or one with a deposit.
• Reduce a call for price car, or one with no advertised price.
• Reduce the same car twice in one day, even when two steps fall due at once.
• Overwrite a price a person just typed. If someone reprices a car while the job is running, it leaves that car alone and records that it did.
• Apply the same step to the same car twice, ever.

Where the new prices go

Your marketplace feeds are a full snapshot of your lot, uploaded twice a day. The job runs 45 minutes before the morning upload, so every price it moves is on CarGurus and Cars.com in the next feed with nothing to press.

Every reduction is written to that vehicle's own history, so "why is this car $17,995 now?" has an answer on the car.