Join Now

Click here to join our
growing community:

JOIN LOGIN



Blog

Latest News
Recent Posts
Search
Archives


Comments

Infrastructure
September 4
The Command Center
August 17
Roses and Page Names
August 13



Copyright © 2020
Terms of Use
Privacy Policy
BoltWire

Membership Vs CRM

Posted 09/18/20, by Dan Vis

Today I put together most of the pieces for the new membership system I've been promising. Only, I stopped short of the full goal. In today's blog, I discuss the change in my thinking...

Ultimate Memberships.

Member data drives a membership site so managing it well is important. One of my big goals for BoltWire 7 was to overhaul how that worked. I had a couple specific goals in mind.

First, I wanted to change the core so it stores member data vars in a protected directory that is only accessible via special BoltWire functions to really tighten down the security on that super sensitive information.

Second, wanted to store things as info pages organized by field, rather than by member id, so you don't have thousands of files on a large site, and can process/sort/search data lightning fast. 

In other words I wanted to make BoltWire more secure, and more scalable. I've more or less achieved both of these goals and am just testing and debugging things at the moment. Version 7.01 will be coming out soon.

My other goal however, was to switch to an email based system with double opt in email verification and the like so you could easily use BoltWire's built in email capabilities to communicate with your members.

That's what I do on my site, and I have all the code for it. But I have to tell you--it's not easy. And of course, it requires you to have email sending capability via your site, which presents its own challenges.
 
I originally thought about having two systems, so you could use the simpler approach initially, and then switch to the other when desired, but that added double the complexity all the way around: duplicate code, duplicate system pages, and duplicate documentation. Way more than work than I wanted!
 
So I decided to pursue an interesting partial solution to this third goal...

A New Approach

There's actually another reason I didn't make a full change. And that was a blog post I read over at Blog Marketing Academy, that got me rethinking things:

Basically David Risley argues the way most membership sites are designed is backward. Many, like mine, manage all the membership info in the site, and then try to keep things in sync with a crm/email marketing tool on the back end. The better approach, is to let your crm/email marketing tool manage the data, and use its api to determine site access.

You may want to read what he wrote for the full article, but it was pretty revolutionary to me...

Essentially, what he's saying is that your crm is better suited to store, manage, and use your membership data. You never have to worry about keeping things in sync. And the membership system then doesn't have to handle all your email confirmations, subscriptions, email sequences, segmentation, and whatever else their platform can do. Your site only has to communicate back and forth with the crm. Which is relatively simple.

Let's say someone wants to become a member and subscribe to my blog. I use the crm to do the double optin and even store their password there. When they login, I check to see if they are subscribed in the crm and if the password matches what is in their records.

Or let's say someone joins a class for example. BoltWire tags them in my crm as being in the class rather than storing that information somewhere in BoltWire. When they go to access the class, BoltWire just checks with the crm to see if they have that tag and grants or denies access based on that. When they finish the class, I remove the tag, or tag them as a graduate.

In other words, the idea is to have BoltWire store my member data in the crm and then access whatever information it needs to do its thing via their API, rather than keeping that information squirreled away somewhere in my site. The crm thus stays permanently in sync (in fact it becomes the repository) and BoltWire can function without having to replicate all those features available in the crm. All BoltWire needs is access to a simple api to subscribe, unsubscribe, and read/write tags. And the crm does all the database storage on the back end.

What This Means

I was just working on the BoltWire site today, and took a preliminary stab at this. And it was amazing how easy it was to setup the double optin. I have the code on my main site to manage all that, and I could have imported it, but it would have taken all day to test and tweak it. Through the crm, it was a 15 minute job.

This doesn't mean I'll be removing any functionality currently in BoltWire. And this approach is not even going to be the primary approach used in the core. I will actually be upgrading the existing membership system so Boltwire can do even more internally--and I won't be stripping anything out. It will likely be the approach I use with the Hosting Service, as it dramatically simplifies things for me and for the client, while simultaneosly expanding what they can do. All I need to do is provide a crm module and explain how to use it.

It does mean, the new membership system doesn't have to have all the bells and whistles I've been planning and is pretty much ready to go right now (7.02). I can just keep using the same quick and easy approach BoltWire has always used.

I did make one big change toward that third goal however. I managed to switch to an email login system by default in the core, which will further make that transition to a crm engine easier. The core won't do double optins, so it's quick and easy like before. But it does gives you a way to reach out with transactional emails. I may eventually go ahead and provide an email confirmation plugin (as that's super important) and a password reminder plugin (also quite important), and include those in the core for those who want them, but they won't be required for BoltWire to work. And they won't be needed if you use a crm type approach.

And if you are worried about all the changes, you'll be happy to know I'm adding a "simple login" plugin to 7.01, so users can upgrade existing sites and keep their current login and registration systems if they wish.

I've completely rewritten the membership section in the Welcome Tour to explain in detail how it all works. And I will be adding more documentation to the Handbook shortly. Please feel free to read the information there. Feedback welcome. 


Comments

So what do you think of the new and improved membership system? What's your opinion about the benefits of running your membership site through tight integration with a crm? Feel free to leave a comment below...




No comments yet...



Join Us

To read more posts, or to leave a comment, join our FREE community...

JOIN NOW