Building a CRM Strategy Brick by Brick
During ZohoDay26, I had the absolute pleasure of sitting down and talking CRM with Julie Lloyd from Acme Brick in beautiful Austin, Texas,. Naturally, the topic of the day was Acme Brick’s fascinating journey into the Zoho ecosystem. As a CRM analyst and consultant, I’ve seen countless software deployments crash and burn because organizations focus entirely on the technology rather than the people actually using it. That is why talking with Julie was such a breath of fresh air; her focus is entirely on the human element of Acme Brick’s digital transformation. For those who aren’t familiar, Acme Brick isn’t just any company; they are the largest US-owned manufacturer of brick. They deal in a wide gamut of materials, including manufactured block, stone, tile, and various other wall cladding. It is a sizeable operation with around 1,700 employees spread across 13 states. This coming April, Acme Brick is celebrating a its 135th birthday. When a company with that much history decides to overhaul its CRM technology, you know there’s a good story behind it. Even more so, if it is a system replacement story, Julie has been with Acme Brick for two years, and what keeps her up at night is CRM training and ensuring user adoption. TL;DR If you do not want to read, here’s the full video interview. For everyone else, read on. Having said all this, let’s dive into why they made the switch and how they are making it work this time. The Square Peg, Round Hole CRM Disaster Before migrating to Zoho, Acme Brick used another CRM system. We won’t name names here, but...The New Enterprise Moat? Zoho’s AppOS and Stack Sovereignty Signal the End of Fragmented SaaS
ZohoDay 2026 is in the books, and it has again been an intense two days of information and discussions, starting off with some impressive statistics. In time for its 30th anniversary, Zoho crossed the milestones of one million paying customers and an eye watering 150 million users. All this while not having raised a single dollar of external capital or buying technology or users. The company stays fiercely independent and continues to grow very profitably since it crossed the threshold of an annual revenue of $1bn back in November 2022. If I wanted to boil this event down to a few key messages, it would be value, independence, platform, and, of course, AI. The conference in a nutshell: Value is the result of the smart use of automation with AI that works on top of the corporate system of record, powered by a platform that is built on an independently owned stack. This is also the secret sauce of Zoho, a philosophy that the company follows since its inception. And here is how Zoho brings this to work. Zoho owns and continuously improves its stack Coming from the angle of sovereignty, Zoho extends this thought of independence to its customers now in an answer to Raju Vegesna’s not so rhetoric question “what will happen if someone can pull the plug?” on any of your essential systems. All of the sudden, the thought of local deployments or hybrid deployments with cloud apps operating on local data becomes very interesting, valuable, again. It is mitigating risk. According to Vegesna, clients of different sizes are asking for this model. Another part of this equation is...
Flipping the math: How AI changes Build vs. Buy
For the longest time, companies have been trapped by enterprise software vendors. First by shrink-wrapped software packages. Then by SaaS offerings. Both situations led to what one even in a SaaS world can call shelfware – although these days the shelf is a virtual one instead of a physical one. Buyers still get enticed to purchase more capabilities than they need, which leads to them paying more than necessary while often using software packages that offer overlapping capabilities. One of the promises that SaaS started with, was to end this. Sadly, it looks like this promise was not kept. And this is no wonder; after all vendors want to be sticky. And they need to have increasing revenues. This means that they need to offer an ever-increasing number of capabilities, aka features, to warrant their pricing and eventually regular price increases. Combined with the frequently used strategy of offering related capabilities, i.e., seats for an adjacent software that is not yet needed by a customer, this led to two things: bloat and shelfware. Both go at the expense of the enterprise buyer. Since the dawn of packaged software, the argument to buy, i.e., to voluntarily step into this trap, is the same: Buying is cheaper than building. Which probably was correct. Buying from a specialist was the logical choice. Engineering talent was, and still is, scarce. Building software includes a lengthy process of requirements engineering, years of development and ultimately never-ending maintenance. Just that most of this is true for most implementations of purchased enterprise software, too. And the buying process is arguably broken. Need identification is often done...