I’ve written about Podio a number of times before, including a soppy love song that I wrote last year that serves as a pretty fair introduction to why I love the system, and why I think you will too. If you’re new to Podio, have a look at it.
This article isn’t for the new arrivals to Podio. It’s for people that are using Podio, and want to light a stick of dynamite up their systems and supercharge its performance.
One article can’t do all of that, so today I’m only going to tackle one subject: the power of data hierarchy in Podio.
Let me explain what I mean.
Most users really only see one level of data in their system – the data they see in front of them in their Apps. And that’s true for a lot of functionality. You build a good CRM system, you expect to see the data for companies being held in a “Companies” app. You expect to see the data for people being held in a “Contacts” app. You get the idea.
But that really only scratches the surface to the true power of data within Podio.
When we build Podio, we tend to look at the data involved in the system on three levels:
Foreground Data – This is data that most users actively work with. It’s data kept in apps that are commonly used for common purposes. This is the data that 95% of people will probably think of when they think of their Podio data.
Middle-ground Data – This is data that tends to be used only by a few users in the system. This data tends to work in an administration space and tends to be used to actively trigger/interact/manage the foreground data by actions that are taken by specific users.
Background Data – Finally we have the background data. This is data that sits behind everything (usually in a series of private workspaces) and isn’t interacted with by anyone (or if it is, by an extraordinarily few amount of people) at all. This is data that is held in order to make things happen in other parts of the system. It’s there to facilitate complex workflows and complex data structures, so that the user experience is simplified. In other words, background data allows you to make the sausage without ever showing the users how they are being made.
These three levels of data are critical to understanding how you can build incredibly complex structures in Podio, with a simple combination of drag and drop fields and a set of productivity tools like GlobiFlow (now being further integrated into Podio), Zapier (for some amazing links between external programmes) and the like.
Here’s a direct example:
We’ve built a very large Podio system for a client of ours in the United Kingdom. They are a membership organisation with approximately 2800 members. One of the functions of the organisation is to deliver a series of events (charged individually) to their members on a “first come, first serve” basis.
On the face of it, this is a pretty easy thing to do. All they want is to be able to create events, have members book onto them and run them. Simple, right?
Well, not really. Dig a little deeper and we run into variables:
- Members should have to pay before they access an event
- Members should have their dietary preferences automatically included
- There are only a certain amount of spaces and these should only be given to fully paid members.
Ha. More complicated.
Now you can build a system, using only Podio and a couple of foreground apps, that will deliver a lot of this functionality. The problem is: it’s going to involve a lot of manual input and management. And I mean a lot.
Suddenly our build has become a lot more complicated.
Using a combination of GlobiFlow, Zapier and Podio, as well as a new data structure that is built over all three of the data hierarchies, we built this system to be almost 100% fully automated. No manual intervention is needed except at a few key points.
Let me show you a map of what that looks like (ok this is a rough map, I’m not spending 15 hours drawing every single process step, but you get the idea):
See how simple it is?
Actually it’s not, it’s incredibly complex, but the user experience of it is incredibly simple.
Let’s take a look at that experience:
- They reviewed a list of events
- They selected the event they wanted to go to
- They received an invoice in the manner they requested
- They paid the invoice
- They received a confirmation of payment & the event success confirmation
- Their dietary requirements were automatically sent to them to review and make changes
- The created an event
- They got notified of paid members only
- They didn’t need to chase for payments (the system did)
- They didn’t need to update anyone had paid (the system did)
That’s only possible by thinking a bit differently about your data in Podio.
Anything is possible if you think about your data a bit differently in Podio.
And I mean anything.
Want to find out more?
Send us a message: