Story from the CRM Trenches – When a little knowledge is dangerous, or Let the experts do their job.

03.10.18 10:22 AM By Rich Astone

Story from the CRM Trenches – When a little knowledge is dangerous, or Let the experts do their job.

      
Photo by Młgorzata Tomczak (whoismargot)
 “Your system deleted all my vendor data!” The voice on the other end of the phone was the president of an engineering firm that built water filtration systems for cities around the world. He was understandably quite upset. My company had just finished a CRM implementation for his company, and I had been quite satisfied with the results, having designed some nice sales and marketing automation as well as custom user screens. What could have gone wrong? I needed to scramble to try to assist him and save my company’s reputation. I returned to the client’s offices to begin my investigation. I knew I had done everything within my power to do it right. But I had a sneng suspicion that the problem was related to not something that I did, but something that the client would not let me do. This was before the cloud days. To support his field sales staff, we were using a data synchronization feature in the CRM product to propagate changes to the database. I had attended two days of training to get certified in that module, and had experience setting it up with other clients. But during the implementation, the president (being an engineer) decided that to save some money. He had instead insisted on setting up the synchronization himself, against my protests. I decided to bring in a third party, paying out of my own pocket to hire the best consulting firm in the area that worked with that CRM product. The president of that company came out to review the situation himself. It was a bit tricky to do the forensics, but he soon discovered the problem. “There is nothing wrong with the work you did” he informed me. “He did this to himself.” When the president of the engineering company set up the synchronization, he failed to input a necessary code that would identify which datasets would sync. As a result, when he did the batch sync of what he thought were all his sales records, his vendor records went along for the ride. Then, a field sales rep saw those vendor records, and trying to be helpful, decided to delete them. When the sales rep synced his data back to the home office, the deletions flags were sent as well, deleting the all the company’s vendor records. Having that third party helped me to convince the president that this was his doing, and not a problem with the general CRM implementation I had provided. Now all he had to do was pull the vendors from his backups. When I first started the implementation, I told the president that I wanted to check his backups before I did anything. This he also would not allow, because he managed the backups personally, and they were fine. Or so he thought. It turns out that, being busy running his business, he had not properly set up his backups. Thus, his vendors had not been backed up in ages. At this point, he agreed that none of this was the fault of my services, but because of his decisions to go against my recommendations. I felt bad for him. But I still fired him as a customer. It cost me some money, but I kept my company’s reputation intact. The software vendor soon made dataset codes a requirement to prevent those sorts of mistakes made by clients who didn’t want to pay for trained professionals to do the work. And in hindsight, perhaps I should have made the customer pay for the third-party consultant if the error was discovered to be his. Perhaps I should have insisted that I do all the work, at the risk of sounding like I was trying to milk him for all the business I could get. Running a business is a learning experience after all. Still, I had cleared my name, and in that situation, it’s what mattered. Of course, had the issue been caused by me or my staff, my number one priority would have been fixing the issue and making the customer whole. Even though the nature of technology is different today, there are still some good lessons that I learned in this situation, which I’ll share now.
  • It’s important that good service contracts are in place to protect both the consulting firm as well as the customer. In this situation, at least the client had enough integrity to admit that the faults were his. But what if he had not? It could have been very costly for me if I didn’t have proper sign-offs and stipulations in my contract.
  • We all need to be careful about the dangerous combination of having ‘enough’ knowledge to figure it out ourselves and the desire to save every dollar. Pride (and being cheap) often go before a fall.
  • We need to cultivate a relationship of trust with clients. When money is an issue we need to show we are willing to work with them to achieve the win/win. But if we have built enough trust, we should also expect that they will not resist our strong recommendations.
  • If clients are still resistant to our sincere warnings. We need to pause to consider if we can improve the trust in the relationship, be willing to respectfully walk away from the project in a way that does not leave the client in the lurch, or at least review contracts and agreements and get the client to state in writing what services they are bypassing against our recommendation.
Fortunately, with cloud-based platforms, losing backed up data is less of an issue. But we still need to be wary for the sake of all involved that we are not too prideful about our capabilities whether we are service providers or clients. Honesty about what we are good, and not-so-good at is still the best policy. A touch of humility doesn’t hurt either.

Rich Astone