WHY YOU NEED A
Platform Operations Dashboard
If you take a look at the TribePUB Tech Stack you will see that we have the Platform Operations Dashboard (“POD”) at the center of our WordPress Ecosystem configuration. The reason that it is in the center is because it is in fact the central connection and data access point inside of our Platform Unified Business system.
When we began our move in 2015 from our proprietary custom coded platform, that we had spent the prior 15 years and millions of dollars to create, we found that the WordPress Ecosystem had functionality and features that not only matched everyone of ours but exceeded it. If you saw the WordPress Stats on the Tech Stack page then this should come as no surprise now that WordPress has fully matured since its inception in 2003.
Yet, there was one key component that the WordPress Ecosystem did not provide that our proprietary platform did and that is our POD. Our custom membership platform was built with over 4.5 millions lines of code that comprised the CMS, LMS, CRM, Gamification, Social, Commerce and every other feature fully integrated into one code base. So it was very easy to provide our enterprise level clients with custom dashboards and metrics that spanned the entirety of their Platform Unified Business and member user experience.
To get our legacy clients to make the move with us we had to provide the types of metris, dashboards and functionality that they were used to in our enterprise level solution. We looked high and low through the WordPress Ecosystem to see if there was some already off the shelf pre-built solution to our and our clients needs. But alas there was no solution to be found. So, since we already knew how to code it … we did.
You see in our Tech Stack diagram the the POD is its own standalone sixth key component to our technology solution. This actually represents its actual position within our PUB. We have designed it in such a way that virtually all custom code resided inside of the POD and not in the other parts of the PUB. There are two primary reasons for this.
First, it is best practice in the WordPress world to not make custom code changes to WordPress itself, your parent theme or the plugins. If you do you always run the risk of a WordPress, theme or plugin update either not being able to update or overwriting or breaking the custom code. This is not a position we wanted to be in or that we wanted to put our clients in.
One of the main factors of choosing the WordPress ecosystems is the 10s if not 100s of thousands of coders around the world making constant improvements and updates to WordPress, the theme and the plugins. If we put custom code in these elements then we would be losing all of that benefit as well as making our clients unable to get support from the creators of WordPress, their theme or their plugins and they would be constantly dependent on us. And believe it or not … that is not our goal.
Our goal is to reduce complexity, cost and risk for our clients. And if we were to make custom code part of the broader tech stack then we would be increasing all three of those areas versus reducing them. So, we make all custom code changes inside of the POD which consists of our own plugins and code additions to the child theme (which can be customized at no risk).
Second, we made the POD a standalone feature because we wanted our clients to be able to turn it off or turn it on without impacting the rest of their platform. While we hope that every client stays with us forever, that is not always the case. And if a client wanted to switch IT Contractors then we wanted them to have the ability to continue on with the WordPress Ecosystem under different or self management without any negative impacts.
There are multiple functionality enhancements, reporting, metrics and dashboard resources that the POD provides to our clients.
First, is the ability to track user engagement across all core aspects of your platform. Learning, Social Interaction, Purchases / Subscription, Gamification, and much more. While each sub-component of the WordPress Ecosystem exceeded the features and functionality of our custom platform those components do not be default talk to each other or have a centralized dashboard and reporting mechanism.
As you see in the Tech Stack diagram illustrated by the dotted lines the POD is connected to the other key five components of the system and share data back and forth. This data is then used to track and provide reporting across all touch points. While each sub-component has its own reporting. That reporting is often very limited and always limited to just that sub-component. The POD unifies the data and makes it available in very useful ways.
Second, because we can track and report on the data that is generated by your members we are then able to discover where your members get stuck in your onboarding and engagement flow so you know when, where and how to fix the roadblocks. This is one of the most critical missing pieces to any membership platform that is not using our POD.
For traditional ecommerce sites all they have to worry about is lead generation and to some degree lead conversion. The product or service is not fulfilled within the platform itself. With membership sites and learning communities the products or service primarily is the site or at minimum is almost exclusively housed with the platform. And how well the member is able to onboard and engage with the product or service will determine churn, chargebacks, refunds and on the positive side one-time and recurring revenue.
The POD allows you unparalleled insight into the onboarding and fulfillment processes that are critical to a membership sites’ success.
Third, housed within the POD is our proprietary Gampify System and Engagement Matrix. Because we have been early adopters of user engagement and gamification going all the way back to our first platform we have had two decades to really explore, research and refine what works and does not work in gamification and user engagement. While we use GamiPress as the gamification engine we use or Gamplify and Engagement Matrix reporting framework to really perfect gamification and user engagement.
Finally, the POD allows us to bolt on other business and reporting models onto your membership site. Because we support many not-for-profits, ministries and charities we have a version of the POD that is a a fully functional donor management system that uses WooCommerce as the primary donation engine. We have other models in planning and development currently.
The POD is an indispensable part of starting, growing and scaling into an enterprise level membership site.