1. Timothy Jacobs

    Looks like a nice update. I wonder why there isn’t a public GitHub repo for the plugin if they are looking to improve extensibility and developer adoption.


  2. Al

    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.



  3. Peter Shaw

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

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


    • Mike Stott

      “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).


      • Peter Shaw

        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.


      • Tim Kaye

        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.


        • Mike Stott

          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.


  4. Rob Mc

    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.


    • Mike Stott

      Hi Rob

      Very kind words, thank you (although did you miss out a comma after pretty?) 🤩haha.

      Thanks also for the candid feedback around Jetpack too, we’ll certainly take all feedback on board as we continue to move ZBS CRM forwards into 2020 and beyond.


    • Mark Boudreau

      Definitely agree with the Jetpack sentiments. Hopefully it will become an option and not a requirement for the ZBS CRM in the future. Meanwhile I will be going live with ZBS early next year with my consulting company.


  5. Henry Archer

    I’m researching on the same CRM from the last couple of months, but didn’t get any bit info regarding this update. It’s extremely awesome and much helpful,


  6. Scott A

    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.


  7. Ant

    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.


    Fantastic CRM.

    Do not “break” what ain’t broke.


    • Justin Tadlock

      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.


  8. Mike

    Based on what I have read here, does this explain why I can’t use ACF anymore to add fields to Companies or Contacts? Is there a work around?


  9. Ravi Agarwal

    Extremely helpful for maintaining the dataabase through custom relationship management.


Comments are closed.

%d bloggers like this: