Marc Beinder

Build Software for People, Not the Enterprise

Marc Beinder

Marc Beinder

Enterprise Technology is broken. It’s disjointed, disconnected, and an overall royal pain to use. These large systems of scale promise the world but deliver confusion and dread. 

Over the last eight years, I have been exposed to different CRM (Customer Relationship Management) systems, Help Desk & Support Systems, Marketing Automation Systems, and General Business Process Systems. I was an administrator for some of these and a general end user for others. I was internal to the company and not a customer of all of them. 

The Promise 

These companies and products promise expanded insight and increased visibility into your business and your data when using their products.  

The Problem 

While sometimes it may be true that their products deliver increased insight, what is not commonly said aloud is that you need to be standardized on their platform to get the maximum value. To some extent, that makes sense to me. But in my experience, that is rarely something easily accomplished or even feasible. There are always constraints on any project. Some may be financial, some may be technical, and some may even be legal. I cannot begin to expand on every potential reason why standardizing on a single platform may not be possible, but we all have our war stories of issues we have faced in this effort. 

Build vs. Buy 

Because of these issues, a significant debate has formed around building versus buying the various business systems used by almost every company worldwide. Do we develop our CRM or go with Salesforce or HubSpot? Do we need marketing automation? What does that look like depending on our CRM choice? 

You could spend years debating this topic and be no closer to a solution than when you started. What’s the impact? Your business starts to fall behind, and instead of deciding on what technology makes the most sense for you, you play catch-up and probably make some bad decisions along the way. 

Integration Hell 

In the many businesses I’ve started and stopped, I always faced one constant problem: Customer data syncing. I felt it was best to use existing software solutions for a long time. Some were SaaS (Software as a Service) applications like HubSpot CRM; others were open-source applications like EspoCRM, osTicket, and Mautic. 

Each of these point solutions was particularly good at what they did. But I encountered a problem when needing to connect all of them somehow. It’s not that they didn’t have any way of communicating with each other, but that each system had its own model of what a customer record looked like. I would expect this and encourage a dedicated system to have its own data model that makes the most sense for the use case the application is solving. The problem is introduced when attempting to normalize these various models across multiple systems. 

The original support software I used in one of my endeavors was osTicket. I eventually moved over to EspoCRM as it provided much more functionality than just support in a single system, and by doing so, I could eliminate an integration point simplifying the flow of data. It’s important to note that it’s okay to eliminate some things when working to centralize and standardize your data. You’re already introducing a massive change. As a part of that change, make your system easier to use and not harder. 

Consider Your Goals and Their Effects 

One of the integration points I had between EspoCRM and Mautic was that if a support ticket were open for a customer, Mautic would not send promotional emails to that customer since they were actively facing a problem. I don’t know about you, but when I’m having trouble with a company, I don’t like receiving emails trying to get me to spend more money. So, I wrote a simple script that would detect if a support case was open for a customer and then pause any promotional marketing campaigns in Mautic for their customer record. This script ran once per hour every hour. You might already see the problem. If a customer emails support with a new issue before the script runs, they could receive promotional emails for up to an hour. This is not the end of the world, but it is not ideal. 

When standardizing the various customer data models, consider the following: the customer emails support from an email that is not on file. No problem, just add that email to their contact record in EspoCRM. However, this didn’t work because EspoCRM regularly pushed data back into HubSpot. A new email address in EspoCRM meant a new contact record was automatically created. HubSpot would see the newly created contact in EspoCRM and create a new contact record of its own. As a result, Mautic would see a new contact record in HubSpot and also create a new contact record. So now we have duplicate data and more work to return to a singular customer record in each system. 

There has got to be a better way to work with Enterprise Systems. 

What did I do? 

I started to build a custom data platform that all of my different point solutions would talk to instead of talking to each other. But by doing so, I ended up recreating a substantial portion of functionality from each of these point solutions. I even built a small user interface to view all this data through a single pane of glass. It was nice, but it didn’t solve the more significant problem. This was just another system to maintain and another data model to keep in sync. This, coupled with the numerous customizations to the point solutions I would make, led me to explore just building my own software to manage everything. Now, I’m spending more time building a custom system to manage my products rather than building my products at all. 

Why Build It? 

I needed a central source of truth for all my customer data. General customer records, marketing data, and support data. I now knew what I wanted to build and the features I liked and disliked from each system I’ve used. 

So that’s what I’m building. I want to develop a system to manage customer data, including general CRM records, support tickets, and marketing automation triggers. You’re probably thinking, “Great… you’re building Salesforce. You’re just moving the problem in-house rather than to a standardized third-party vendor.” To some extent, you’re right. That is what I’m doing. However, after previously using third parties like Salesforce, I know that they are not the right solution for my goals and the objective of what this system will do. In this case, Salesforce is not the right tool for this job. 

I’m also building this system where the external point solutions, such as Mautic, are still first-class citizens. Some of the software I had been using did not keep other software in mind beyond having some form of a REST API. Some of the APIs were helpful in the tasks I would perform. Still, in others, they were not necessarily designed for moving data between systems but rather for interacting with a single-page JavaScript application. Again, not a problem caused by the software itself but a problem introduced by the goals I had. I was using the wrong tool for the job. And to be more specific, the tool I was using was no longer appropriate for what the job had evolved into. 

Here’s a perfect example of what I want this system to be able to do. When a support ticket is opened, I want to automatically trigger any marketing automation system to stop sending promotional emails. Then once the ticket has been resolved, turn them back on. Let the system use the contextual information that it has to aid you in delivering exceptional customer experiences. 

The point of this system is not only to have a standard and centralized single source of truth for customer data but also to allow for your system of record to enhance your point solutions, not just bolt-onto them. How amazing would it be when your customer calls or emails you about a billing issue to have your support agent be able to see their Stripe history without actually needing to give that support agent access to Stripe directly? Your support agent could even initiate a refund right from the system. The customer knows they are getting a refund because they were double-billed after talking with only one person. Not after talking with someone who notes everything in a support case, transfers the customer to the billing department, who doesn’t even read the case, and makes the customer explain their issue again. 

This system is the single pane of glass not just into your customer data but into the entire digital experience for your company. Yes, it starts by being a standardized solution, but it’s a standardized solution with the ability to connect to other systems from the get-go. Not a single system that periodically syncs with upstream or downstream systems. It connects in real time as life happens. 

Enterprise Software has been built for the C-Suite and for reporting for too long. I am not building software for the enterprise; I’m building it for the users. The other solutions thrive on getting you fully integrated into their platform. This system thrives by being the single pane of glass into whatever systems you have. It takes an opinionated approach that makes using the system delightful and powerful. You don’t have to choose anymore.