Zero BS CRM 3.0 Improves UI, Changes Database Structure, and Becomes More Extendable

Decorative logo image featuring a bull for the Zero BS CRM plugin

The team behind Zero BS CRM launched version 3.0 of their WordPress plugin today. This is the first major release since the plugin was acquired by Automattic in August. The updated plugin uses custom database tables, opens the plugin for more extensions, and has a more consistent UI than previous versions.

CRM is an acronym for “customer relationship management.” CRM systems allow businesses to manage their customer relationships through an interface. How CRM systems work can vary greatly, depending on the software used. In general, the goal is to help manage contacts, sales, and productivity.

Zero BS CRM was co-created by Mike Stott and Woody Hayday. Despite a low number of plugin users (around 1,000 at acquisition), Automattic acquired the plugin based on the strength of the product. Currently, Stott and Hayday are the primary developers on the plugin and maintain more than 30 commercial extensions for it.

Many CRM solutions are SaaS products, such as Salesforce CRM and HubSpot CRM. “The main benefit of ZBS CRM over online SaaS type solutions is it sits in your WP admin dashboard, and you own your own data,” said Stott.

Version 3.0 of the plugin improves in several key areas. One major change is the switch to custom database tables rather than pigeon-holing everything into a custom post type. This change should speed up accessing data such as contacts and transactions in large databases.

Users should benefit from a much improved and consistent UI from previous versions. Zero BS CRM does not strictly follow the core WordPress admin UI. “When looking at ZBS CRM and how to tie in all our menu items into the WordPress UI – it wasn’t easy,” said Stott. “We settled on using a UI framework with our own top menu, and a natural follow-on for that was to draw our list views using that same UI and button systems. Whether we move this back or not depends on feedback from our users — we get a lot of positive feedback on how easy it is to navigate around and wouldn’t want to change something that’s been getting good feedback.”

Screenshot of the contact management screen in the Zero BS CRM plugin.
Contact management screen in the Zero BS CRM plugin.

Moving to custom tables over custom post types has also helped improve elements of the UI. Stott said a huge advantage is not having third-party plugins accidentally adding themselves to the plugin’s admin pages, such as having unnecessary SEO options on contact records.

Another big change in 3.0 was building out a more extendable foundation for the plugin. This will open up custom CRM objects in the future. For example, plugin users could manage resources such as “properties” or “campuses” along with customer contact data. This update creates more potential for industry-specific extensions.

“It really opens the door for more extendibility in the future,” said Stott, “and through an improved API in 2020 will allow for us to do more work across platforms and open up our CRM tools to more people.”

The Zero BS CRM plugin remains free and is available in the WordPress plugin repository. The primary source of income comes from its extension bundles, which are priced monthly and billed yearly. The website currently offers freelancer ($11/month), entrepreneur ($17/month), and elite ($30/month) pricing options. It also has a reseller plan available.

The Move to Automattic

When the plugin was first acquired, there was an initial idea to rebrand as “Jetpack CRM.” However, they have maintained the Zero BS CRM branding with an acronym instead of the direct expletive for “BS.” A rebrand may still be on the table in 2020 or beyond.

“We’ve been gathering user feedback and sentiment following the minor changes to ZBS CRM and the initial reactions if we were to rename as Jetpack CRM,” said Stott. “Since the shorter name, there’s been less objection or negative feelings, which puts less pressure on a big rebrand project, but it’s certainly something we’ll be coming back to.”

Stott said the primary focus since the acquisition has been less on branding and more on delivering 3.0 to the existing customer base.

The acquisition by Automattic has helped with how their two-person team works. “The main thing is being able to lean on the amazing team and people throughout Automattic,” said Stott. “In the past, we’d only have Woody and my input, now we can reach out to experts in design, marketing, plus much more, and bounce our ideas around a vast pool of experience.”

He explained that the additional support resources of Automattic’s Happiness Engineers means that he and his partner can focus more on engineering and growing the product and team.

The acquisition of Zero BS CRM came during a busy year for Automattic. With major moves such as acquiring Tumblr and the Salesforce investment, this small plugin has mostly flown under the radar in comparison. Stott and Hayday have big plans for 2020. They would like to grow the engineering team and explore bringing their tools to more WordPress.com users.

The plugin’s growth has remained stable since the acquisition, according to Stott. “The announcement brought us some additional customers who saw the backing from Automattic as strong advocacy for the plugin over other solutions in the WordPress space, so they made the decision to join us,” he said. The plugin has doubled its active install count and now serves over 2,000 users. The team expects to continue growing in the coming months.

20

20 responses to “Zero BS CRM 3.0 Improves UI, Changes Database Structure, and Becomes More Extendable”

  1. I don’t see the business model or rationale for a CMS (WP) – CRM amalgamation when you can get free and terrific standalone CRM called EspoCRM (https://www.espocrm.com/) which installs with about the same non-complexity as WP and is far better than the NoBS plugin.

    Sometimes, just because it CAN be done does not mean it SHOULD be done.

    YMMV.

    • “The move to custom db tables mean no devs will want to install it or extend it (for a marginal speed benefit).”

      It’s a significant speed benefit when contacts and transactions are in the many thousands. Moving to custom DB tables also has the benefit that posts / pages meta doesn’t get clogged up compared to not using custom tables.

      “Integration with jetpack will just add to bloat. Bye bye zero bs crm.”

      Not necessarily, certain elements of Jetpack are advised if using a CRM (security, backups, etc) plus benefits around things like quicker search (using elastic search).

      • Wow you really don’t understand independent developers.
        If my client needs a crm your maybe good but it won’t be exactly what they need.
        If you use common hooks/APIs I will choose your CRM to build my solution. Not only as I’m already familiar but also as I know I can re use the code. I’ll also publish my enhancement so other can benefit.
        If you use a custom table I can say that I definitely won’t use your product.

      • Peter Shaw is right.

        I recently needed to build a rather complex site with lots of custom data. There was a highly-rated plugin in the WP repo that could get me 80% of the way. But it used custom tables. Trying to go the other 20% was a nightmare. So I re-wrote the whole thing, with no custom database tables — and voilà!

        Is it slow? According to you, it should be. But it’s actually faster than the plugin was. Why? Tom Nowell has explained why:

        “When you fetch a post from the database, WordPress takes some initiative and fetches all of its post meta at the same time. So your code doesn’t trigger queries to fetch post meta from the database on the current post. Retrieving post meta values for the current post is essentially free. Combined with object caches such as Redis or Memcached, this makes post meta incredibly fast.” (https://tomjn.com/2017/02/27/not-post-meta-bad/)

        The problem with using postmeta, as Nowell has also explained, only comes if you search for posts from postmeta. Essentially, that’s doing things backwards. In such cases, you should be using custom taxonomies instead. (I can vouch for this approach. My re-written plugin uses taxonomies instead of meta whenever I need to go in that direction.) This is precisely what custom taxonomies are for. Then you get speed, resilience, and re-usable code with familiar hooks.

        I suggest you have a chat with Nowell. After all, these days you share an employer.

        • Hi Tim,
          While this is correct for fairly simple data structures, the more complex the data model the less this rings true. Once you start holding many dimensions for an object, querying at scale fails to be performant via the restrictive (but very useful for some things) custom post type model.

          There is a line to walk here, where we make it easy for developers to tweak/build upon ZBS CRM, while not sacrificing end-user performance completely. The reason we’ve moved to fully custom tables (but will be releasing a solid API & dev guide), is because we reached the limitations of the post model for the data our users want to track.

          For example, some of the more value-added functionality in ZBS CRM such as Sales Dashboard: https://zerobscrm.com/product/sales-dashboard/ – would take 5x as long to run calculations across contacts, companies, multiple taxonomies, time-periods, transaction types, etc.

          To reiterate, the post model is fantastic for simple data structures. To get high performance for some data models though, it’s essential to bake your own.

  2. I’m a ZBS client and I like it. The 3.0 version was a nice improvement and the software team is pretty friendly and helpful (Hi, Mike!).

    I would prefer to not see this be absorbed into Jetpack in any way. I really didn’t like how Automattic integrated with Woo (requiring a WordPress.com login and the dreaded Jetpack prompt on your site). I think it would be best all around if it stayed independent of the Jetpack system. There isn’t anything missing in this plugin that JetPack is going to solve and I’ve always felt it’s best to keep things clean and not introduce new complications. If people want JetPack, they can load it. But, many admins have their own ways of security, search, backups, etc, etc. JetPack is one option, it shouldn’t be the only option or a forced option.

    IMO, the best thing Automattic can do is just support this two man team with additional developers and support staff so they can get some breathing room to focus on their product.

  3. I’ve been using ZeroBS since early on and the changes have not only been needed but wanted. They’ve improved the core product immensely over the years and the extensions are a bargain. The ones I use have really helped me streamline the business and I can see it improving. I’m hoping and looking forward to seeing the QuickBooks Online integration that will make the two almost seamless. Nothing worse than double entry IMHO. As a tool, I use ZBS every day and the devs are open to suggestions and improvements which is what makes this special.

    The fact that it sits on top of my main source of revenue makes it a no brainer. I don’t want or need a standalone and this does the job nicely. I’ve used many CRM’s over the years, some that integrate CRM, ERP, Accounting, etc but at the end of the day, so many products already do such a fine job and integration between them is key.

    The developers have always been willing to help, both Mike and Woody have been extremely responsive and easy to communicate with. Obviously as the installs grow this will change but I hope the spirit doesn’t.

    Thanks for the past and keep up the good work in the future.

  4. In full agreement.

    PLEASE do not integrate this with Jet Pack.

    1) – Bloat ware
    2) – Will suck up more storage when installed onto a server due to all the UN-used other “plugins” within Jet Pack.

    PLEASE DO NOT DO IT.

    Fantastic CRM.

    Do not “break” what ain’t broke.

    • Integrating with Jetpack does not necessarily mean integrating into Jetpack. The first would be adding feature integration or leveraging APIs that Jetpack/WordPress.com offers for Jetpack users. The second would mean bundling the plugin as part of Jetpack.

      While I am unaware of the long-term plans, integration with Jetpack would not change anything for users of the plugin who choose not to use Jetpack. That’s assuming they go that route with anything in the future.

Newsletter

Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.