Masterclass Summary:
In this Supercharged! Masterclass Jordan dives into a core concept behind Podio system design: building based on single objects. this very simple concept is something that he sees all the time in new systems and leads to bad data integrity and bad Podio workflow.
In this masterclass you’ll learn:
- The concept of single object data planning
- A practical example of how this principle works in practice
- Why single object planning means you have a better view of how your data interacts around your Podio system.
Transcript
Narrator 0:01
You’re watching another supercharged masterclass with Jordan, Samuel Fleming your opportunity to learn the ins and outs of Podio design and development from one of the top Podio partners in the world.
Jordan Fleming 0:14
Hey, everybody is Jordan Fleming here with another supercharged masterclass. And today, I want to dive in to something I care very deeply about when I’m talking about poor design. And that is the concept of aggregating to single objects. That’s kind of a techie kind of way of talking about it. But really, what it means is that you want to design a system. So that single things are things single things, right? A person is a single record in your car in your Podio system, a property is a single record, a project is a single record, a task is a single record. That matters, because one of the mistakes I see new people building in Podio do all the time is designing a system where essentially they are taking core information like a person or, or a project or a property. And they are putting that data on each individual app as separate bits of information. And what that means is that, you know, like take an example, in a sales process where you’ve got to lead, the turns in a prospect turns into a lead turns into customer. Jordan Fleming comes in, and he’s a prospect. If you then create a new lead card for Jordan Fleming, and you just transfer the data, the information on Jordan over Jordan exists in two places. And that becomes a real problem for your data integrity, and how you really want to be able to keep your data set up in Podio, for reporting. So let’s dive into Podio bit and have a look at what I mean.
Okay, so before we dive into Podio, I thought I’d take a moment to illustrate this. In some diagrams, essentially, we’ve got a bad data structure and a good data structure on how to build it in Podio, drawn out here, now, if we look at the bad data structure, what we basically have is three apps, prospect app, delete app and a customer app. And what we’re doing is we’re hard placing the data about that person, Jordan Fleming and his phone number. We’re putting them in his fields in each app. That means that Jordan Fleming and his contact data exist as bits of information on each single app. While there’s a problem to that. And I can give a very good example, from a project management point of view, Hey, are you using Podio to manage your real estate investment business Wait, click the link to find out why 1000s of real estate investment professionals are using Podio plus smartphone to make more calls, send more text, and close more deals, click the link or a real estate point of view. So if you’ve got a project management system where you were logging who a project leader is, and you hard code, their code their information in the app, does that mean that Jordan Fleming is only ever going to do one project? Well, no, probably not. In which case, if Jordan Fleming is involved in 10, or 15 projects per year, you’re gonna have Jordan Fleming hard coded data on each individual projects. But you’re not really going to have any way of understanding, though, to tell totality of what Jordans done uses them. Because his data’s on each of the apps separately. Real Estate point of view, if you’ve got a seller coming in, and they’ve got a property to sell, well, what happens if they’ve got a second property to sell? What happens if there are a buyer in your system and they want to buy five or 10 houses, if you are hard coding that data on the apps, you are missing out the whole view, which is why we tend to talk about aggregating to the single objects and that means in my view of good Podio design, you should be building your system to make sure that single objects are always built, you know that your your app system is built to identify singular objects. A person is a person a task is a task, a project is a project. A deliverable is a deliverable a property is a property, etc, etc, etc. That means that you can use the power of relationship fields to link them together. So if I task if I have a task app, because tasks are singular, and I have a person’s app, because people are singular, I can link them and I can link them multiple times. So one person can be linked to hundreds of different tasks. That means if we look at the good data structure in the second diagram, that means that in instead of hard coding that data, I am using a relationship field to link back. And in Podio, this is critical for good design, because it then allows you to see all the things that Jordan Fleming has done across your system. And let’s pop on into Podio. And take a look at that. So here I have an example of a property in my Podio system and I can see that a primary seller is here. And it has a relationship field I’ve not embedded William smarts information in here I am using a relationship field to link this property is linked via the primary seller field to a contact. That means when I go to William sparks contact here, I can see a lot of different things. I can know that actually, William smart has one property where he is listed as the seller. Okay, great. And I can see three offers we have sent to William seller, William smart. Okay, hands up who’s using Podio for real estate, and they don’t want more Leads. Nobody. You want more Leads closed Well, checkout smartphone for Podio, the only phone system fully built for Citrix Podio. With an fully integrated power dialer and our amazing mobile apps, it means wherever you are, you can make more calls, love to Podio, send more texts, love to Podio and close more deals, all logged to your Podio CRM, click the link, check it out, I can see all sorts of documents contracts we have sent and what stage they’re in. And if I scroll down to the bottom,
every app has this at the bottom of it, which is what are related items to this unique item. And I can see here that William smart has been involved in 141 communications to smart dialer camp leads, six documents that we’ve sent him 12 tasks and involved in him three offers one transaction one property and 20 formatters that some more new seven sequences, eight sequences for the seller, and on and on and on. That kind of information, that understanding how the one person relates to many things in my system is only possible if I design my Podio system in a way that those singular objects are what we linked to. And so when you start to think about how to design your Podio system, I strongly urge you to think about what all those singular options our objects are, and how they relate to each other. Because if you just draw yourself a map like that, if you literally I used to do this, when I was drawing out big systems, if I was designing a really big system, I would draw out a map of the workspaces and apps. And I would link them the apps together, I would do it in a programme like Lucid Chart like you’ve seen here. And they sometimes do these huge diagrams, but what they would allow me to do is think through the data structure, and make sure that I’m always aggregating data to those singular points. It becomes an incredibly useful data analyzation tool. And it really will allow yourself, your system to have a lot of clarity, when you start thinking about that. So I strongly urge you to think about this. What about how to aggregate your system to the singular objects, a person is a person or using Podio. With call rail, there’s a better way, click the link, find out why hundreds of businesses have moved over to using smartphone, the only phone system built for Podio. Make more calls, send more texts and close more deals. Click like a person’s details shouldn’t be just, you know a person shouldn’t be here, here, here here. Jordan Fleming should exist wants a new system. And maybe Jordan is a buyer. And maybe John’s a seller. And maybe Jordan has these tasks, and maybe he has these projects. But Jordan Fleming has a singular object. A task is a singular object. And maybe it’s devoted to this many people. A property is a singular offer, which which has sellers and realtors and buyers and contracts and tasks and sequences and all these things. But they are singular objects linked together. It’s a really critical part of what I feel to be good Podio design, and it’s something you really should think about if you’re starting your own Podio design system setup. agree disagree, head over to YouTube comment on the video. While you’re there, hit the subscribe button to make sure you’re notified of any other videos that I post up. We’ll be posting quite a lot of them. Of course head over to your favourite podcast platform and so Subscribe to my super charged podcast. Give it a like give it a review, please, please, please do these things. I’m not charging for this. I’m just asking you to support the show the podcast and the masterclass by liking, subscribing, giving reviews, spreading the word and of course engaging on the YouTube channel. You got something you want me to talk about? Let me know. You got one big guest in the podcast, you build Podio you live with Podio love Podio hate rodeo, drop me a line and let me know. Thanks very much.
Narrator 10:30
Thanks for watching this Supercharged masterclass with Jordan Samuel Fleming CEO of smartphone don’t forget to hit the subscribe button on our YouTube channel to be notified of new podcast episodes Podio masterclasses and in depth Podio extension reviews
Add comment