Subscribe
Share
Share
Embed
Welcome to our podcast, where we dive into everything Go High Level—from mastering the basics to tackling the most complex tasks. I use GHL daily in my business and rely on Google NotebookLM to stay ahead of the curve, keeping up with all the latest GHL features, tools, and innovations. This podcast is powered by AI, fueled by the research and insights I personally curate to bring you the most valuable and up-to-date content.
Copy this link for a free trial of Go High Level - https://www.gohighlevel.com/highlevel-bootcamp?fp_ref=amplifi-technologies12
Imagine trying to fit uh like a multi-million dollar commercial property, complete with all its maintenance schedules, tenant histories, complex lease agreements into a single first name field on a standard contact form. Oh, man. That is yeah, that's just a recipe for disaster. It's an absolute nightmare. And you know, if you run an agency, you know exactly how fast that kind of work around just completely falls apart. So, welcome to the deep dive. I am thrilled you're joining us today because we are tearing down the basic CRM. We really are. Is it's time to move past the basics. Exactly. But, uh, before we jump into the architecture of all this, I have something massive to share with you right now. You can get a free 30-day Go High Level trial. Which is huge, by the way. It's double the standard trial length. And the link is waiting for you right down in the show notes below. You are definitely going to want to grab that by the end of this conversation because today's mission is custom tailored specifically for you, the digital marketing agency owners out there looking to scale your services, you know, justify premium pricing and just completely lock in client retention. Right. Which is basically the holy grail for any agency. Yeah, I know. And to get there, we're analyzing a stack of sources today from the official high-level support portal to some really brilliant agency strategy blogs. And they are all focused on one incredibly powerful capability, which is custom objects and company objects. Okay, let's unpack this because for the longest time, a standard CRM was well, it's basically just a digital rolodex. Yeah, a really expensive address book. Right. It tracks people. John Doe, his phone number, his email address. But today, we're exploring how you can use high level to track things. We are moving from tracking the who to tracking the what that actually drives a specific business. And that distinction, that's the exact feature that transforms a basic off-the-shelf software tool into a highly profitable bespoke system for your clients. But, you know, before an agency can go out and sell this custom system, you have to understand the underlying architecture of the data itself. Because every agency owner hits this wall eventually. I mean, you land a client, their business model has some nuanced complexity, and you just find yourself trying to cram all their weird specific data into basic contact or opportunity fields. Yep. We've all been there. High Level recognized this, which is why they provide structures beyond the standard contact. So let's uh let's start with the built-in company object. Right. So the company object is specifically focused on business level data. So the client organizations, vendor relationships or partner agencies comes pre-built into the system and it automatically uses company name as the primary key. Let me pause you there for anyone who isn't like a database engineer. A primary key is essentially the digital fingerprint for that record, right? The one unique identifier the system uses to keep track of it. Spot on. It's how the database prevents confusing two companies that might have really similar names. Yeah. Now, the company object comes with default fields like phone and email. But it has strict governance rules. What do you mean by strict governance? Well, it is meant to be used with contacts only and each contact can have only one company association. So it's a very fixed, rigid structure designed specifically for managing B2B organizations. Which makes sense for standard B2B relationships. But Yeah. Uh, what if a client's business revolves around something that isn't a person and isn't a company? And that is exactly when we introduce custom objects. These allow you to define brand new record types literally from scratch. You model the business specific data that absolutely does not fit into those standard boxes. And, according to the support matrix, custom objects are available on all Go High Level plans. Though, we definitely need to be clear about the limits here. The documentation outlines that you can have up to 10 custom objects per location. Right. And then within each of those objects, you are allowed up to 10 unique fields. Yeah. So things like single or multi-line text, numbers or phone numbers. Yeah. And uniqueness is strictly enforced across the entire sub account. Meaning if you try to put the same serial number in twice for like a piece of equipment, the system throws an error and stops you? Which is fantastic for keeping the client's data clean. The source also mentioned you get up to 10 unique association labels between any two objects. I was uh I was trying to wrap my head around that one. Yeah, that can be a little tricky. Think of an association label as the definition of a relationship. Instead of the system just knowing that John Doe and a specific commercial property are connected somehow. Right, like just a generic link. Right. The label tells you how they are connected. Are they the buyer of that property? The listing agent for it, the previous tenant? The label just makes the nature of the connection perfectly clear. I love that. You know, I was trying to visualize this while reading through the blogs. Using a standard CRM is kind of like using a basic two-dimensional filing cabinet. You have a folder for a person and you just shove every single piece of paper about their life into that one folder. Yep, just a messy stack of paper. But using custom objects, it's like building a three-dimensional relational database. The folders don't really talk to each other. They exist independently, but are connected by these invisible threads. What's fascinating here is how this allows an agency to map the CRM directly to a client's real-world physical reality. You no longer have to force the client to change how they talk about their own business just to fit the software. Oh, that's such a good point. The software molds to them. You treat their actual physical assets, their properties, their pets, their ongoing projects as independent records with their own distinct life cycles. But, you know, just because you can build a custom object for every little thing doesn't mean you should. Definitely not. If I'm an agency owner, how do I avoid turning my client's CRM into just a convoluted unusable mess? That is a very real risk, and over-engineering is a trap a lot of agencies fall into. The rule of thumb we pulled from the documentation is this: If the data doesn't naturally belong to a person or a company and it requires structured repeatable records, then it's a prime candidate for a custom object. Think about the sheer variety of businesses an agency serves. If you're working with, say, a veterinary clinic, tracking a standard contact just isn't enough. You need to track the actual patients. Exactly. Max the golden retriever. Right. Max needs his own medical record independent of his owner. He has a breed, a weight history, a rabies vaccination date, a temperament score. That is a perfect use case. Or think about a gym tracking equipment maintenance schedules. Every single treadmill and rowing machine becomes a custom object with its own warranty expiration date and service log. But the sources are equally clear on what they call not recommended use cases. For example, the documentation practically yelled that you should never use custom objects for event attendees or internal notes. And the reason why comes down to the underlying mechanics of the software. Standard objects like your contacts, they are hardwired into the platform's core communication features. Custom objects are not. Wait, what does that mean? It means they do not support email campaigns, bulk SMS, calendars, the conversations UI or payments and invoicing. Hold on. I need to push back here on behalf of everyone listening. If I can't email them or text them, doesn't that defeat the entire purpose of a CRM for a marketing agency? I mean, why would I build something that can't be put into an email sequence? Okay, that's a crucial misunderstanding we really need to clear up. You aren't losing the ability to email the person. Oh. The human being the contact, they still exist in the system and they still get the email campaigns. The custom object just holds the data about the thing they own or interact with. You email the owner, you store the data in the property. Ah, okay, okay, that makes total sense. But that brings up another question. I can hear agency owners right now saying, wait, why not just make a bunch of custom fields on the standard contact record and call it a day? Why go through all the hassle of building an entirely new architectural object just for a pet or a house? It's a really fair question. And honestly, it's the exact shortcut most people try to take at first. But it completely falls apart when you start dealing with complex relationships. Specifically, one to many and many to many relationships in a database. Break that down for me. What does that actually look like when it fails? Let's use your veterinary clinic example. Mhm. One contact, the human owner might own three different pets. If you rely on custom fields on the contact record, how do you actually build that? I guess you'd just keep adding fields. Right. You have to create fields for pet one name, pet one breed, pet one weight. And then you have to create duplicate fields for pet two name, pet two breed. Oh, wow. Yeah, that gets ridiculous immediately. What if they have five pets? What if they adopt a new one? You're constantly having to rebuild the form and add new columns to your database just to accommodate the outliers. The data structure literally shatters. Or, consider real estate. One commercial property might have multiple tenants, three different owners, and a leasing agent. If the property data is just a field on a person's contact record, you have to duplicate all that property data onto the tenant's record, the owner's record, and the agent's record. If the property price changes, you are manually hunting down three different contact files to update it. Which is a complete nightmare for data consistency. Somebody is going to forget to update one of those fields and suddenly the CRM is just lying to you. Exactly. With the custom object, the property exists exactly once. It is a single source of truth. You simply link it, using those association labels we discussed earlier, to the owner, the tenant, and the agent. You update the property's price once and that reality is instantly reflected everywhere it's connected. Okay, I am completely sold on the architecture. We know what to build and what to avoid. But, you know, a database is totally useless if it is just a static vault. How do agency owners actually get data into these objects seamlessly and how do they automate the processes around them? This is where the magic happens, but it requires paying really close attention to the rules of the builder. Here's where it gets really interesting. When we were reviewing the source material, there was this glaring discrepancy. One of the agency strategy blogs explicitly stated that you cannot directly integrate custom objects into forms yet. The author outlined this elaborate workaround using what they called transient data. Which is a brilliant concept for a workaround, to be fair. It was very clever. It is. Basically, agencies had to create dummy custom fields on a contact record, catch the information from the form, use a workflow to push that data over to a custom object via API, and then erase the dummy field so it was ready for the next person. I mean, it was exhausting. Oh, yeah. A lot of heavy lifting. But then, you look at the official high-level support documents today and they explicitly state that custom objects are now fully natively supported in forms, surveys, and quizzes. I wanted to highlight this for you listening because it just shows how aggressively High Level's development team moves. What was a frustrating, code-heavy limitation just a few months ago is now a native drag-and-drop feature. It is natively supported, yes, but you can't just throw everything into a blender. There are strict rules for how you build those forms. The biggest one, you can only use one object type per form, survey or quiz. So if I'm setting up a form, I can't just drag and drop a mix of standard contact fields and custom object fields to get all the data from a new client at once. Actually, no, you can't mix object types like that. The system will literally throw an error. If the form is built for a custom object, it has to stay focused on that object. Furthermore, you must configure the associations immediately within the builder. Meaning what, exactly? When someone hits submit, the system needs to know exactly how to link that brand new custom object record to the specific contact who is actually filling out the form. Right. And there's a protective rule about the primary field, right? Yes. Every custom object requires a primary field, like the pet's name or the property address. The system automatically adds this mandatory field to your form. If you try to delete it, the builder actually clears all the other fields out and you have to start completely over. Wow, it really forces your hand. It does, but it ensures you don't accidentally create orphaned, nameless records just floating around in the database. Okay, so the client fills out the native form, the custom object record is generated, and it's perfectly linked to their contact file. What happens next? Like how do we put this data to work? You build what the documentation calls an object-based workflow. Instead of the workflow running on the contact, the automation runs directly on the custom object itself. That is incredibly powerful. What actually triggers it to run? The primary native triggers are when a custom object is created or changed. So, a new property is added or a pet's vaccination status is updated from current to expired. But you can also trigger it via an inbound webhook. For the non-developers listening, an inbound webhook is basically a digital catcher's mitt, right? It just waits to catch data thrown by an external software system. That's a really great way to visualize it. Say your client's gym uses proprietary software on their treadmills that pings an alert when a motor needs servicing. The webhook catches that ping from the treadmill and automatically updates the treadmill for custom object right in high level. And once it's triggered, what kind of actions can the agency automate from there? The possibilities are extensive. You can automatically create or update associated records. You can send the custom object data directly to a Google Sheet for the client's reporting. Or, you can fire off a custom webhook to push that data out into yet another platform, like a dedicated billing software. Because these automations can run entirely in the background, the client never has to lift a finger. And that hands-off operational reality, that completely changes what an agency is actually selling. If we connect this to the bigger picture, these workflow capabilities are the key to building seamless operations. The data flows in, updates the reality of the business in the CRM and triggers the next operational step automatically. Which brings us to the ultimate bottom line for everyone listening to this right now, translating these highly technical features into agency revenue and client retention. Because understanding the database architecture is only half the battle. Selling it to a local business owner is the other. And you definitely don't sell it by talking about relational databases and inbound webhooks. No. No, you would put them right to sleep. But the agency blog source we reviewed had this brilliant core insight. It essentially stated, Custom objects allow you to stop selling a generic CRM and start selling a custom-built business system. That phrasing completely shifts the perceived value. Custom-built business system. Let's play out a scenario. Think about a local tutoring center. If you walk in as a standard agency and say, hey, I can set you up with a CRM to track your inbound leads and manage your sales pipeline, you sound like every other marketer who has cold emailed them this week. Exactly. You are a commodity. You are selling a tool they could just go buy themselves for 99 bucks a month. You are competing on price at that point. And that is a race to the bottom. If you approach that same tutoring center and say, I have built a specialized educational management system. It tracks individual student progress reports as independent records and automatically links those academic reports to the parent's billing profile. When a tutor updates the progress report, the system automatically logs it and texts an alert to the parent. You are no longer selling a marketing pipeline. You are selling the operational nervous system of their entire business. You are replacing three different messy spreadsheets and a part-time administrative assistant. And you can charge significantly more for that. It is a totally different tier of value. So here is a practical immediate action step for you listening today pulled straight from the experts. Step one. Pick one specific niche you currently serve. Step two. Write down three to five types of specialized data they desperately need to track that absolutely do not fit into standard contact fields. Things like active construction projects, insurance policies or fleet vehicles. Step three. Log into High Level this week and actually mock those up as custom objects, build the framework, see how it looks and feels. Even if you don't roll it out to a client immediately, having that framework ready completely changes the confidence you have in your sales conversations. Oh, 100%. So what does this all mean? It means you are moving from being an easily replaceable software vendor to an irreplaceable operational partner. This raises an important question for every agency owner listening. What is your current churn rate? Think about the typical agency cycle. You win a client, you run their Facebook ads, ad fatigue sets, and after month three, the client looks at your monthly retainer and they decide to quote-unquote pause your services. Uh, it is the most frustrating cycle in the industry. It happens to everyone. But imagine how deeply integrating a client's unique operational data changes that math. When you hold the underlying architecture of their business, their active property listings, their entire database of pet medical histories, their equipment maintenance logs. When all of that is built natively into your agency's high-level setup, the conversation changes. They can't leave. Or rather, the friction of migrating that highly structured customized relational database back to a generic platform or a messy spreadsheet is massive. The client becomes essentially sticky for life. You aren't just running their top of funnel marketing. You are housing their day-to-day operational reality. They literally cannot run their business without your system. It is a brilliant strategy. You are building a massive data-driven moat around your agency. And remember, you can get started on building that moat today. Do not forget, the link for the free 30-day Go High Level trial is right there in the show notes. That is double the standard time. It gives you an entire month to mock up these custom objects for your specific niche, build the native forms, test the workflows, and actually pitch it to a client before you even pay a single dime. It is an incredible runway to test these concepts without any financial pressure. Yeah. And uh, I want to leave everyone with one final thought to mull over. As we discussed, High Level's development team is moving aggressively. The support matrix and the documentation listed a few things under the coming soon category that should completely blow your mind. Oh, yes. The one that caught my eye was dynamic binding for funnels and websites. Explain what that implies for the future. Right now, we're talking about using custom objects internally, right? Strictly for the business to organize its operational data. But dynamic binding means the data inside the CRM will be able to directly populate public-facing web pages. So, if I'm understanding this directly, imagine a future where your client's websites dynamically build themselves based purely on the custom object data in the background. Precisely. A real estate agent updates the status, the price, and the photos of a property custom object in their CRM. Instantly, without anyone touching a single line of code or opening a website builder, a live formatted listing page is generated or updated on their public website. That is mind-blowing. It essentially turns High Level into a full-fledged content management system driven entirely by relational data. Think about how that will completely change the web design services your agency can offer. You won't just be designing static landing pages. You will be building living, breathing digital ecosystems for your clients. The possibilities are literally endless when you move beyond a flat two-dimensional database. It's so true. It all comes back to that basic filing cabinet. It is time to take your client's data out of that flat paper folder and build them the three-dimensional reality their business actually needs to thrive. Thank you so much for joining us on this deep dive. Get out there, click that link in the show notes for your free 30-day trial and start building your mode. We will see you next time.