There’s a pattern I see over and over again inside WordPress membership ecosystems, especially when we’re talking about LearnDash, BuddyBoss, CRM integrations, gamification, automations, all of that.
Everything starts out great.
✔ The plugins are working.
✔ The courses are loaded.
✔ Members are coming in.
✔ Automations are firing.
✔ Everybody’s excited.
And then all of a sudden, six months later, every little improvement feels risky. 😮
The current membership platform is just too heavily coded; it’s too fragile, it’s too brittle. If you’re doing improvements or running initiatives on the platform, you know, you have to patch and band-aid, and it’s just difficult to maintain.
And the reality is, most of the time, it’s not really a LearnDash problem.
It’s an architecture problem.
The User Table Problem Nobody Thinks About Early Enough
One of the first things I look at when I come into a platform is how the plugins are storing their data.
Because in WordPress there’s a primary table called a user table, and inside of that user table there’s what’s called serialized data. Meaning a lot of the plugins will either do one of two things: they’ll either store the data themselves and create new data tables on your WordPress server, or they’ll just jam it into that user table.
And there are pros and cons to both.
We like plugins that don’t jam it into the user table because that’s serialized data and serialized data doesn’t perform when you’re querying it at the same level of table-based or key-based data.
And we don’t really like overpopulating the user table because then it slows all operations down.
That’s one of the reasons we like WooCommerce above other commerce platforms because WooCommerce uses its own data structure outside of those serialized user tables. Same thing with Gravity Forms, which is what we often use when we’re doing forms, quizzes, and surveys because it stores its data outside of the user table as well.
What happens over time is plugins get layered on top of plugins, data gets scattered everywhere, and all of a sudden nobody really knows where the data lives anymore.
Now you’ve got:
- reporting issues 😶
- performance issues 😑
- automation issues 😯
- maintenance issues 😪
And every new feature creates another layer of complexity.
The Custom Code Trap
Another big issue is custom development scattered all around the ecosystem.
Our philosophy is to only do custom development when we absolutely have to.
We do our absolute best not to do any tweaks to the themes or to the plugins.
We do that for multiple reasons.
One, when the plugin developers and themes are pushing updates, we never even have the opportunity of conflicts. Even though you can develop in each side and they all have the ability to do add-on code that shouldn’t ever bother them, it’s still always there as a risk.
And then secondarily, you may want to have someone else other than me maintain the system. And the less there’s custom code tucked all around the site, the more that anybody can come in and maintain this and take over the keys and run it without having the Wizard of Oz kind of lead them through that.
That’s a huge point that most organizations don’t think about until much later.
A platform shouldn’t require tribal knowledge to operate.
The only custom piece that we’re developing is the Operations Hub.
And the reason for that is because we want to see our data and interact with our data in a different way. So we push all of that interaction into the Operations Hub so there’s just one little place for all of that to happen.
CRM Dependency Eventually Creates Operational Fragility
This is probably one of the biggest pain points I see across membership businesses.
Probably 50% of my clients are in that pain point of some form of transition.
They’ve outgrown the CRM.
The integrations became messy.
The automations became layered.
Nobody knows where failures are happening anymore.
And what happens is you end up with these multi-tiered complexities where you don’t know:
- did Zapier fail?
- did Salesforce fail?
- did the API fail?
- is it a communication issue?
- is it a load issue?
- is it a data issue?
That’s why one of the opportunities is to center up your functionality inside of the platform.
While everything is fully integrated with the CRM, it doesn’t have to be dependent on the CRM, whether it’s billing or even tag management.
What that allows you to do is change CRM with less challenge.
And the goal is that if the billing system and everything is inside of it, you literally could unplug the CRM to some degree and this would still operate.
That’s a completely different way of thinking about architecture.
The CRM still gets all the data. ☺
The automations still happen. 😉
The tags still flow. 😁
But the platform itself is no longer held hostage by the CRM.
Most Membership Sites Have No Real Onboarding Architecture
The onboarding and UX, the current system has little to no onboarding or processes for new members. What onboarding exists is currently being done through email prompts, which obviously is very disassociated from the user experience. And oftentimes people aren’t reading their emails.
Members get lost and confused, overwhelmed, churn, customer support, all of that goes up. We want to not do that.
This is one of the biggest hidden problems in online learning ecosystems.
Most organizations think onboarding is:
- an email sequence
- a welcome email
- a few automations
But onboarding is actually the architecture of the member journey.
We found that the key tools of welcome videos, help tours, key popups, prompts can go a long way towards helping a member feel comfortable when they’re not lost.
And onboarding is much simpler than some people often complicate it.
Simple things:
- dripped content
- timed unlocks
- guided progression
- contextual prompts
- onboarding videos
All of that is part of how we time out the user journey.
Because the reality is people disengage when the experience feels fragmented.
The member needs to feel like the platform itself is guiding them.
Not their inbox.
Most WordPress Ecosystems Operate Blind
One of the downsides to a traditional WordPress ecosystem is there’s no cohesive metrics dashboard.
You’ve got to go into WooCommerce to see commerce.
You’ve got to go into LearnDash to see progression.
You’ve got to go into GamiPress to see badges.
You’ve got to go into the CRM to see customer activity.
Everything is fragmented.
And that’s really kind of the heart of the systems that we build: an Operations Hub.
Show their learning data, show their badge data, show their commerce data all in one heads-up display, and then also click into that and have a graphical representation of their onboarding journey and what stage they’re in.
Because once you can actually see the member journey, now you can start improving it.
You can:
- reduce churn
- increase retention
- decrease refunds
- decrease customer service load
And that’s really where this starts becoming more than just a course website.
The Future Is Behavioral Architecture
At least the vibe that I’ve gotten with you guys so far is that you want to go a little bit deeper with that and really get into this user journey and user experience from a 360 perspective.
That’s really the shift.
The future isn’t just:
- courses
- memberships
- plugins
- automations
It’s behavioral architecture.
Relevant interactions.
Relevant responses.
Making sure people are going through the process without getting overwhelmed.
The member journey, we’re going to map that completely, make sure it’s smooth.
Every stage.
Every trigger.
Every onboarding point.
Every engagement transition.
Because the member driving the member experience is the driving force behind all of this.
And the reality is, that requires architecture.
Not just plugins.
Do you need a LearnDash developer? Contact us!
