Tl;dr - A modern CRM is more than a sales tool - it's a business tool with the potential to drive revenue, reduce costs and improve customer experience. It's not a massive project like an ERP, but out of the box it won't be optimized for an industrial manufacturer. Here are tips on custom objects and other considerations to achieve real success.
Transform Your CRM from Contact Management to Business Optimization
Your business's data is a large potential asset.
It's often squandered.
Salespeople's contacts shouldn't reside in their own phone book or even their MS Exchange .ost files. (I even spoke to a company one time where the salespeople - employees - conducted business using LinkedIn messages so that management couldn't "scrape" contacts from their Outlook files! 😫) So companies sometimes turn to CRM to solve this.
But it's more than just contacts.
I often speak with capital equipment manufacturers who can't readily report where their legacy machines are or how many remain active (e.g. should be ordering replacement parts.) That information is sometimes partially reflected in various disparate spreadsheets, but since it's not consolidated, not only is it difficult to access but it's rarely updated and validated. Sometimes companies think of their ERP as the repository for improved data in this space.
Forecasts are notoriously unreliable because detailed data on open deals (opportunities) is rarely tracked explicitly and consolidated. That leaves management chasing reps for updates and squandering time updating forecast documents. Fixing this is often a management priority that leads companies to CRM - but for management reasons which rarely yield a successful implementation.
These are examples, and there are lots of ways in which clean, consistent data can improve business. The inverse is also true. Dirty data impairs business, but often in ways that can't be clearly measured.
Just think of a simple example - quote follow-up.
Put aside questions of a proper sales process, when and why to provide a proposal, and the resources required for many machinery builders to generate quotes for custom engineered systems - how many times are quotes, even for replacement parts, not chased down? Hint - almost always. In some cases there was never an order there - it was a check the box activity. But in many, the prospect got distracted, forgot, or somehow sidetracked, and simply following up on open quotes can drive more business. That takes an understanding of the data opportunity and the marketing and sales tech stack required to unlock it.
So we arrive at this critical point. We need to take a quick dive (honestly) into database construction as context.
Understanding the Mechanics of CRM and Integrated Databases
An important term in database management is "Object." A common definition that you find online is as follows:
"A database object is any defined object in a database that is used to store or reference data."
That's pretty vague. And database objects can include different types of definitions including tables, queries, forms, and reports.
But you want to run a business - so how does this fit in.
Well, most off-the-shelf SaaS databases are built on standard objects. For instance, typically a CRM will include:
- Contacts (possibly differentiate between leads and contacts as different objects)
- Companies (often called accounts)
- Deals (sometimes referred to as opportunities)
Standard objects may also include:
- Products (to support efficient CPQ - configure, price, quote)
- Quotes (proposals)
Those objects are often many-to-many. That means that you can have multiple contacts with the same company. You can have multiple products associated with a quote; multiple quotes with a deal; and even multiple companies with a deal (think OEM vendors and sales channel, in addition to the buyer company.)
Sometimes, however, they are one-to-many, or one-to-one. A common example is that a contact can only be associated with a single company at a time.
Here's the limitation that you might have already noted about these standard objects - they are clustered around new business opportunities. Sure, you can use the same database to log customer interactions, but your engagement with current customers involves other kinds of info. For instance, machine history (SN, ship date, installation date, warranty expiration date, component SNs, etc.)
Before we go further, let's back up and talk about "Properties." Properties are values that are captured in a database object. In other words, you might be an old-school sales team that does lots of business on the golf course. You could add a "Handicap" property to your "Contact Object" to note a prospect's or customer's golf tier to build foursomes effectively for a business development tournament. That "handicap" property is a custom property (most CRM won't automatically come with that field) which is only associated with a contact. (A company, quote, or deal doesn't have a golf handicap.)
You can of course use that property to create lists and segments of contacts (e.g. show me all current customers with handicaps of <= 10 in Nebraska, Iowa and Minnesota.)
This is an important distinction to understand because often software companies will try to sell custom properties to satisfy object requirements.
It's not an adequate solution.
For example, let's say you want to track machine installations with the servo controller type so you can preemptively reach out regarding retrofits when Rockwell Automation announces planned EoL for a specific controller type and generation. In that scenario, if you had included a number of machine properties in a Company object (SN, warranty date, Controller SN, controller type, etc.) you'd be stymied.
First, you would you have to create 5? or 10? or 100? machine SN fields as properties in each company, and then to create more properties for other info like controller type. Then those machine SNs and controller SNs wouldn't be associated - they'd just be part of the company record in aggregate. At this point (this is critical) you have no way to easily query the database to do something like trigger an informative email to the maintenance contacts for a machine with a certain type of controller to alert them and suggest preemptive options - or even just search it yourself.
That's a real-world scenario - and the only way to be able to do that is to use a "Machine Object" which would have a unique identifying property of Machine SN. Each machine record (think of a row in a table) would have properties for the warranty expiration date, controller type, controller SN, etc., etc. Further, each machine record would be associated with records from other objects including:
- contacts (many machines to many contacts)
- company (many machines to one company)
- tickets (many tickets to one machine)
- deals (one deal to many machines - e.g. a system with integrated machine components)
- quotes (many quotes to many machines)
- etc
ONLY by using a "Machine" Custom Object is this possible, and with that possibility, then the opportunity to trigger something like an EoL announcement to the maintenance contacts of specific machines which should have new controllers retrofitted to proactively support the customer.
So that brings us to the custom objects that every industrial manufacturer should create in their database.
Custom CRM Objects Required for Optimized Revenue and Customer Experience
When we work with a middle-market industrial manufacturer we anticipate creating three to five custom objects in the integrated CRM/ marketing automation/ aftermarket database. These include:
- Machine
- Warranty
- Service Contract
- Tickets (sometimes called Cases)
- Channel Partners
Let's look at each to understand why it can be important and how it's used.
Machine (SN)
The machine use case is introduced above. There are numerous additional reasons why it makes sense. Easy and dynamic population of a Customer Portal, for instance. This would allow customers to easily access manuals, knowledge base materials, parts orders, service history, and other details.
For capital equipment companies this is the core unit of business operations around which all other data tends to orbit.
Warranty
Simply researching when the warranty period expires typically requires diving several layers deep in documentation to compare invoices to quotes and to shipping/commissioning records. What a waste of time! And what a poor customer experience! It feels like each time is a judgment call, and customers will rarely find your judgment as obliging as they'd like. Make it simple and transparent!
But why not just have the warranty expiration date as a property in the machine object you might ask? That would let you trigger an automatic internal notification and customer email to any contacts associated with the machine. However, what if the machine contacts were different than the commercial contacts? And wouldn't you want to be able to track warranty tickets, service calls, tech support, and parts sales by machine type? By Company?
And what if you sell extended warranties? In other words, you might have the initial warranty with the sale, but then several one-year purchased warranties thereafter - each associated with a machine.
Service Contract
Depending on your business model this may be redundant to warranty. However, it could be quite distinct. Perhaps companies are entitled to a certain number of hours of remote support, or a tiered discount on parts as part of a service contract (different than a warranty.)
And as businesses begin to move more toward Product as a Service (PaaS) or Servitization model, this then becomes the atomic business element with machines associated with the contract.
Tickets
Tickets are often thought of as a way to consolidate activity around a specific technical issue. They are important and effective for that purpose.
They're also really valuable when used creatively for internal functions to avoid dropping balls.
Because you'll have multiple tickets associated with a machine over its lifecycle, associated warranty considerations, different contacts for each (and maybe even different companies if a machine is sold) these need to be a relational (and often custom) object themselves.
Channel Partners (Might Also Include OEMs)
Many manufacturers will find distributors, reps or agents involved in the sale and support of machines.
If those relationships are tracked only as company or contact associations your ability to visualize complex business dynamics will be hindered. By including them as custom object records you'll have significantly improved reporting capability (think forecasting, commission reporting, product line and territory management analysis, etc.)
These are common custom objects, but each company is different. If your products aren't serialized you might not need the "machine" object for instance. At a minimum, the list should get you thinking about how to visualize a database structure that will empower your business.
Barriers to Customer Lifecycle Database Implementation
You might be recoiling at this point; thinking that this sounds complex and disruptive. So let's look at the realistic barriers that arise as companies think about this sort of approach.
Investment (or cost)
For companies that have spent several hundred thousand dollars (or more!) on an ERP, there's an inclination to consider some simple module to track contacts. That's even more pronounced when executives have personally experimented with tools like OnePage, Pipedrive, and Zoho in the past. Those tools may have supported their job search, professional networking, or personal Christmas Card lists as contact management tools. Those are different applications than delivering a great customer experience.
Business Tool vs. Sales Tool
This raises an interesting change management question. For execs who might have used simple CRMs in the past, they probably think of the CRM as an individual sales tool.
When you understand it as a single source of truth that spans the entire customer experience, you start to visualize it as a business tool. It's not an adjunct to the ERP, rather the ERP is an order entry, inventory management and manufacturing workflow adjunct to a robust CRM.
However, that only works when companies visualize an integrated database that:
- serves as a single source of truth
- offers one intuitive UX
- is built on a unified code base (vs. acquired brands bolted together with a similar html appearance.)
- and is easily configurable by marketing operations and/or sales operations
There are lots of synchronization tools available with cloud-based software. These can helpfully coordinate opportunities and orders between the CRM and ERP, but synching doesn't solve the key issues above.
Software Sales People Aren't Capital Equipment Business People - and They're Accountable for Brutal Quotas
A software salesperson uses CRM for their sales activities. They probably haven't carried a P&L to viscerally understand the profit impacts of free service, replacement part margins, and frequent fulfillment of tech support and operator's manual requests. So they won't necessarily understand how your CRM should be configured. That's not their fault. Capital equipment is just not their world.
They are also under pressure to close deals. Sometimes that means that expediency trumps accuracy. For instance, the ability to create custom objects (important as noted above) may require a more advanced (and expensive) version of software and feature set. When executives think of CRM like Zoho, it's a longer and more complex sales journey to help them see the value of a lifecycle CRM and adjust investment expectations. The reality is that sometimes software salespeople will default to a standard object version that helps get a deal closed but will prove inadequate over time.
Complexity and Software Trauma
As you dig into the considerations and capability of CRM it can be complex. Again, when the familiar analog is a simple, single-user tool like OnePageCRM, it may be an unwelcome degree of complexity. Of course, so is running payroll reports, but companies find resources to take the sting out of that. They can with business CRM too.
Further, many middle-market industrial manufacturers have had traumatic experiences with ERP software that often result in significant cost overruns, operational disruption, and delayed implementation.
A business CRM solution can sound similar, triggering hesitance and loathing at another similar experience.
Certainly poorly designed and executed CRM implementations could result in the same consequences. But the implementation can be phased for progressive complexity, often transparently to users, and can be managed by technically savvy inside folks. It doesn't take high-priced IT consultants. (At least it shouldn't. It's worth understanding the implications, therefore, of a full industry that has grown up around Salesforce.com customization. 😳)
Change Management
There will be some work to get your team on board. Some processes will change - for instance, the automation and task reminders to follow up on quotes may feel burdensome if they've never had to do so.
You'll also have to figure out how to get the team to use the tool consistently. While that seems simple, it can be frustrating. Smart contracts and micro-rewards might help.
The Pay-Off to a Properly Configured CRM
Doing this right offers a lot of benefits. First, it probably fills in a lot of blanks that you assumed your ERP would fill but turns out not to. Second, it will create the structure to provide a substantially improved buyer and customer experience (chat, customer portal, access to information, more informed customer service, etc.) Third, it will make your industrial sales team, customer service, tech support, and others more efficient. Fourth, it will help to automate functions including sales process, quoting, order follow-ups, etc. Fifth, it will create revenue across lifecycle opportunities.
It's an amazingly powerful tool. Extracting the power requires experience and vision - a process that's more about your business and your customers than the CRM software.
