Why Dealership Software Vendors Should Send Engineers to Dealer Visits

• When MOTO(acquire) visits a dealer partner, the goal is to sit with the team and see how things are actually going, not to pitch.

• MOTO(acquire) does not bring a salesperson to those visits. It brings a software engineer.

• Mike Crothers sees this as the difference between MOTO(acquire) and any other company: to solve problems, you send the people who solve problems.

• Dealers evaluating software vendors can use this as a test: ask who shows up at your store and how fast your feedback reaches the people who build the product.

When a software vendor visits your dealership, you usually know what to expect: a friendly check-in, a recap of how the tool is being used, and maybe a pitch for the next product. Mike Crothers, CEO of MOTO(acquire), thinks that misses the point. His answer to why dealership software vendors should send engineers to dealer visits is simple: if you want problems solved, send the people who solve them.

In this video, Mike is on site with a longtime dealer partner. Visits like this are something MOTO(acquire) loves to do: go to the store, sit with the team, and see how it is going. What is different is who comes along.

Why should dealership software vendors send engineers to dealer visits?

"We don't bring a salesperson, we bring a software engineer," Mike says. In his view, that is the difference between MOTO(acquire) and any other company.

The logic is practical. A salesperson can listen to a problem and write it down. An engineer can watch your used car manager work the tool, see where the process slows down, and understand why. The feedback does not have to pass through several people before it reaches someone who can change the product.

As Mike puts it: "In order to solve problems, you need to send the people who solve the problems, which is the engineers."

What engineers learn by sitting in the store

Dealership software works or fails in the details of how a store actually runs. Every rooftop has its own way of handling trades, its own handoffs between departments, and its own mix of systems. Those details are hard to describe in a support ticket and easy to see in person.

When an engineer sits with your team, the kinds of things they can see firsthand include:

• How a trade-in lead moves from your website to the person who works it

• Where the handoff between the service drive and the sales team gets stuck

• Which screens your people use every day and which ones they skip

• How data moves between your DMS, CRM, and inventory tools

That is a big part of how automotive SaaS team culture should work, at least the way Mike sees it. The people building the product should know what a busy Saturday on the desk looks like, not just what a feature request says.

How to evaluate dealership software vendor support

If you are comparing vendors, Mike's point gives you a useful test. Do not just ask whether a vendor has support. Ask who shows up and what they can actually do about what they see.

• Who visits your store? Find out whether it is someone who sells the product or someone who builds it.

• How does your feedback reach the product? Ask how many steps sit between your used car manager's complaint and the person who can fix it.

• What happens when your setup is different? Every store has quirks. Ask how the vendor handles a system or process they have not seen before.

• Why are they visiting? A visit to see how things are going is different from a visit built around a renewal or an upsell.

What engineers at a car dealer software company build

MOTO(acquire) builds software that helps dealerships acquire used vehicles, and it works with hundreds of dealers. The engineers who visit stores work on tools like these:

• MOTO(convert): a website trade tool with instant valuations, firm offer requests, and monthly value tracking, including the free buying power tool.

• MOTO(retain): sends past sales and service customers their vehicle's value every month.

• MOTO(drive): service drive acquisition using DMS data and automated texts. It pushes VIN and miles to inventory tools, and the sales team is alerted when a customer is ready.

• MOTO(social): gives each person posting on social their own link, with leads attributed in the CRM.

Integrations are a good example of why the engineering mindset matters. MOTO(acquire) integrates with all major DMS platforms and many others, including Tekion, Dealertrack, CDK, Reynolds, and Auto/Mate. If your store uses a DMS MOTO(acquire) does not integrate with yet, the team will build the integration. That is a commitment you make when the people visiting your store are the people who write the code.

For more on how the team works, see Inside MOTO(acquire). If you want to see the tools in your own store's context, book a demo.