Run Wunderkind from Your Dealership CRM

Triggered email and text from behaviour on your own website, and why we would ask harder questions than usual first.

Wunderkind is a performance marketing platform built around owned channels rather than paid placements. The output is email and text messages sent to people, triggered by what those people did on your own website: which pages they spent time on, what they configured, what they abandoned partway through. It is closer to marketing automation than to a media buy, and it belongs in this directory because it is sold alongside advertising budgets and competes for the same money.

For a dealership the recognisable shape is the abandoned interaction. A shopper builds a payment estimate, starts a trade appraisal, gets three quarters of the way through a credit form and leaves. That behaviour is a strong signal, it is happening on property you own, and following it up quickly is one of the few marketing activities almost nobody argues with. Wunderkind's business is doing that follow up at scale and at speed.

The reason this page is written more carefully than most in the directory is the layer underneath. The platform's premise is identity, and identity is where both its power and its risk live. That is not a reason to dismiss it. It is a reason to read the next two sections before signing anything, and to read what a dealership CRM already does alongside it.

The case is speed on your own traffic. An abandoned trade appraisal is worth something for a short window, and most stores answer it hours later or not at all. A system that fires a well written message inside minutes, addressed to what the person was actually doing, converts a measurable share of an audience that cost real money to attract and would otherwise be lost entirely. That is a genuine argument and it does not depend on any claim about advertising performance.

The honest objection is compliance weight, and it is heavier here than anywhere else in this catalogue. Sending email and text to people carries a body of consent obligations that sit on the dealership, not on the vendor supplying the mechanism. A platform that makes it easy to message more people faster also makes it easy to message someone who did not agree to hear from you, and the exposure for that lands on the store's name and the store's number. Any dealership evaluating identity based marketing should ask exactly whose consent record authorises each message, get the answer documented, and have counsel look at it. A vendor's identity layer does not discharge a store's obligations, and treating it as though it does is how a marketing programme becomes a legal problem.

The second objection is overlap. Triggered follow up from site behaviour is a category a modern CRM is already in. Before paying separately for it, a store should establish which messages the two systems would each own, because paying twice to message the same customer twice is worse than either system alone. Set expectations against what to expect from car sales leads before committing a budget.

Available on request, which on this directory is a status with a published test rather than a polite deferral. The test is that no adapter file exists in the LeadLocate ad gateway for the platform. That is the case here. There is no partial implementation, no stub returning encouraging numbers, and no code anywhere in the CRM that has ever spoken to their systems.

Access class is CERTIFIED, which describes the vendor's gate rather than ours and is the strictest of the three used here. A contract, a certification or a minimum spend stands between any party and API access. That is a commercial negotiation rather than a form, and it does not move because somebody is in a hurry.

There is a third gate on this platform that the other two axes do not capture, and it is worth naming rather than leaving implicit. Even with an adapter written and a contract signed, an identity driven messaging programme raises consent questions that a dealership has to answer for itself before a single message goes out. We would not build this integration and hand a store the keys without that conversation having happened, because the risk of getting it wrong sits on the store and the reputational cost of getting it wrong sits on both of us.

Stated as a design rather than a description, because none of it runs and none of it is scoped. The same four row shape appears on every page in this directory, so a platform we have built and one we have not can be compared line for line.

The bottom row is not boilerplate on this page. On a platform whose value proposition is identity, the fact that no customer record of yours would leave the CRM through us is the single most important line in the table, and it is a statement about our design rather than about their capability.

If this platform were built, it would not be a special case. Every network answers the same contract.

A single library inside LeadLocate defines what any platform must be able to do: hand us an authorization URL, exchange the returned code for a token, list the accounts you own, deploy a campaign, pause or resume it, return spend and results, and prove on demand that the connection still works. Seven operations, one adapter file per network. That shape is why adding a platform is scoped work rather than an open ended project, and why turning one on does not disturb the ones already running.

Credentials are encrypted before storage using AES-256-GCM. Every action taken against a network is written to an append only event log carrying the company, the network, the user and the detail, stamped in UTC on purpose, because these tables are shared across dealerships and a timezone relative timestamp is one nobody can reconcile later. On a messaging platform that log is worth more than usual: if anyone ever asks who authorised a programme and when, the answer is a query rather than a phone call. Campaign objects record which credentials created them and re-resolve those same credentials afterwards, so a credential withdrawn at the end of a contract does not orphan what was built under it.

Twenty networks are registered against that contract and one is implemented. Wunderkind is not among the twenty at all, which is what available on request means here rather than a softer way of saying soon. Every entry in this directory carries a status with a stated test beside it.

There are two ways to advertise through LeadLocate and you pick.

The first is the webXintel Ads Network. It is included, our team builds and operates the campaigns from the selections you make in Leads Manager, and it arrives as one line rather than a stack of platform invoices. Nothing to set up, no contract to negotiate, and no dependency at all on the state of this page.

The second is your own account, connected to the CRM so programmes sit on your billing, in your name, with your history intact. That is the path this page documents, and for Wunderkind it does not exist. If your store already holds a contract with them, it stays exactly where it is and nothing inside the CRM speaks to it.

One limit stated plainly, because it holds across the whole gateway even where a network is fully built: pushing, pausing and reading numbers from a network is done by our team today, not from your dashboard. That is a deliberate constraint while the connection layer is young, and opening it up is queued work rather than a promise.

Four things in order, and only one of them is engineering.

First the compliance review, which comes before the commercial conversation rather than after it. Establish which consent record authorises which message, in writing, with counsel involved. A store that cannot answer that should not proceed regardless of what the platform can do. Second the commercial gate, because a contract, a certification or a minimum spend is required before API access is issued. Third the adapter: the seven operations written against their endpoints, a credential block added to the gateway configuration, and a verification call that proves a connection rather than assuming one. Fourth the deconfliction work, deciding which triggered messages this platform owns and which the CRM keeps, so a shopper who abandons a trade appraisal receives one thoughtful follow up rather than two competing ones.

On measurement, owned channel programmes read faster than paid media because sends, opens and replies accumulate immediately. That speed is a trap as much as a benefit. High open rates on a message somebody did not want are not a result, they are a complaint arriving later, and the metric worth watching in the first weeks is unsubscribes and opt outs rather than clicks. None of this is a promise about volume or about what any of it closes at, and nobody can promise those.

The gaps below are true whether or not an adapter is ever written, and on this platform one of them is a deliberate decision rather than an unfinished feature.

We do not export a hashed audience or any customer list. Read that first on this page. Your customer records stay inside the CRM, and there is no export anywhere in our stack that hands them to a marketing platform for matching. On a vendor whose products are built around identity, that is the boundary that matters most, and it does not move because an integration gets built.

We do not install or manage pixels. Any tag that a behavioural trigger depends on lives on your website. Placing it, maintaining it through site changes and keeping consent handling correct are not services we provide, and on this platform the consent handling half is the part that carries real weight.

We do not emit a vehicle catalog or an inventory feed to any advertising platform. Messages that render the specific unit somebody looked at need a product feed, and no code in our stack generates one. Inventory Link ingests your feed and merchandises your units on your own properties, which is a different job entirely.

We do not run a server side conversions API and we do not upload offline conversions. Tying a message to a signed deal is outside what this integration would produce.

We do not take on your consent obligations. No integration we build makes a dealership compliant, and any vendor implying otherwise, us included, would be selling you something they cannot deliver.

No programme has ever been deployed to Wunderkind from LeadLocate, because no code exists that could deploy one.

Say so, and say it with your store attached. Requests are recorded against the platform they name, and the tally is the input to build order, because a dealership ready to spend on a channel is a better signal than any internal roadmap meeting.

Expect this one to come back with questions rather than a date. What follow up do you already send from the CRM, and who owns it. Whose consent record covers the people you want messaged. Has counsel looked at it. Those are not stalling tactics, they are the questions that decide whether the integration would help your store or expose it, and a vendor who skips them is not doing you a favour.

If the honest answer is that your existing owned channel follow up covers most of the value, or that the one network already connected reaches the same shoppers without the compliance surface, you will hear that too. Meanwhile the managed path is live and waits on none of this, and pricing sits on the pricing page without changing based on which networks you turn on.

Does LeadLocate integrate with Wunderkind today?

No. The published test for available on request is that no adapter file exists in the ad gateway for the platform, and that is the case here. Nothing in the CRM has ever called their systems and no programme has ever been deployed to them from our side.

Can I use my own Wunderkind account?

Not through the CRM. Bringing your own account is the half of the product this directory documents platform by platform, and for Wunderkind that half is empty. Any contract your store holds with them runs entirely outside LeadLocate.

What happens if I request Wunderkind?

It is recorded against Wunderkind specifically and counted, and the tally decides build order. On this platform you should also expect a conversation about consent and about overlap with the follow up your CRM already sends, before anything gets scheduled.

Why is this page more cautious than the others?

Because identity based marketing carries compliance weight that ordinary media buying does not. Messaging obligations sit on the dealership, not on the vendor supplying the mechanism, and a page that skipped that would be doing a store a disservice.

Would my customer list be sent to them?

Not by us. We have no export anywhere in the stack that hands customer records to a marketing platform for matching, and that boundary is a design decision rather than an unfinished feature. It would not change if the adapter were built.

Does my CRM already do triggered follow up from site behaviour?

In part, which is exactly why overlap is the first thing to establish. Paying separately to message the same shopper twice is worse than either system working alone, so decide which messages each side owns before any money changes hands.

Requests are counted against the platform they name. Tell us what follow up your store already sends and who authorised it, and you will get an honest read on whether this would help or expose you.