Prepared for Ryan Hagan, Jack Ryan Group. A fixed scope, a fixed price, and a clear line between what I build and what has to come from your side.
Rolling 30 days, every active client, plus a roll-up across the whole book. It refreshes on a schedule and lives inside GoHighLevel, not behind a second login.
This is built on the SimpleTalk pipeline already running for the monthly client recaps. The authentication, the per sub-client scoping, and the metrics pull for all 29 accounts are working today. That is why three weeks is a real number and not an optimistic one.
Logs in, scopes to each sub-client in turn, pulls the daily rollup for the trailing 30 days.
Written to a running store so the window can move and history is kept for audit.
Call transcripts scored for hands raised, tire kickers, and unusable numbers.
Rendered as a page and embedded in the GoHighLevel sidebar as a menu item.
This is not a mockup. Every figure below came out of the pipeline, off one of your sub-accounts, from the April data. This is the monthly recap that goes out to each of your agents.
The SimpleTalk access token expires every 24 hours, so a scheduled job cannot rely on a person to hand it a fresh one. The pull authenticates itself against the parent account, which is already in place. The dashboard refreshes whether or not anybody is at a desk.
You asked for twelve. Nine of them are measurable from data that exists today. Here is exactly where each one comes from.
| KPI | Source |
|---|---|
| Human time saved | Dials multiplied by the 144 second per-dial baseline |
| Human payroll saved | Hours saved multiplied by a real estate assistant hourly rate |
| Appointments booked | total_appointments_booked |
| Successful agent transfers | total_transfers |
| Bad numbers removed | call_did_not_connect |
| Hands raised | Transcript classifier, definition set with you in week one |
| Tire kickers removed | Transcript classifier, definition set with you in week one |
| Booking rate | Appointments divided by answered calls |
| AI callbacks pending | Transcript classifier: a callback promised, no later call to that number |
Human payroll saved is hours multiplied by an hourly rate. Human time saved is dials multiplied by 144 seconds. Every tile prints its own assumption on its face, so when a client asks where the number came from, the answer is already on the screen.
These three count records that data enrichment appends to a contact. Nothing appends data today, so there is nothing to count yet. Enrichment is covered in section 06 and billed as an add-on.
This is buildable. It needs a property data source behind it, scoring each contact on the signals that actually predict a move, and that source is the same class of vendor that powers the other three tiles.
It sits with enrichment in section 06 rather than in the three week build, so the scoring model gets built against a data source you have chosen and tested rather than one picked in a hurry.
Built from your reordered notes. Applied at agency level so every sub-account inherits it.
GoHighLevel supports part of this natively and none of the rest. Adding menu links is a real feature and it is stable. Launchpad has an off switch. Several top level items can be gated through the SaaS Configurator.
The renames, and the removal of sub-items like Snippets, Companies, Blogs, and Agent Report, have no native controls at all. They are done with custom styling applied at agency level, which targets GoHighLevel's own interface. GoHighLevel updates that interface regularly and without notice. A change on their side can make a hidden item reappear or a renamed item revert to its old name.
The rebuild is delivered and verified working. Drift caused by GoHighLevel platform updates is covered at no charge for 30 days after delivery. After that it is a support item. I would rather say this now than argue about it in month two.
You asked whether a sale price sits on each contact with commission attached, or whether it gets applied across the board. Neither one works. Here is what the dashboard does instead.
The AI is dialing cold leads. What the system knows about a given contact is a phone number and what happened on the call. It does not know which property that person owns, what it is worth, or whether they own one at all.
So any dollar figure attached to an individual contact would be a number I made up and put a decimal point on.
Falling back to a market average does not rescue it either. A single ZIP code holds a ten million dollar house and a hundred thousand dollar house. An average across that range describes neither of them, and applying it per contact produces a pipeline number that looks precise and means nothing.
Projections fail the same test. Multiplying appointments by a close rate the agent estimated about themselves is an invented number wearing the agent's name, and none of them have a measured close rate on AI-booked appointments yet. So the dashboard shows dollars only where a dollar actually exists in GoHighLevel.
Straight from the daily rollup. This is a counted number, not an estimate. It stands on its own as the result of the calling operation.
When an agent puts a real number on an opportunity, the dashboard reads it and sums it by stage. Entered by a person who knows the deal, not derived by software.
Once appointments have lived a full cycle in the pipeline, closed over booked becomes a real measured rate, per agent. It appears when the data has earned it, not before.
If your agents already type deal values into GoHighLevel opportunities today, the pipeline view lights up in week one and nothing extra gets built. If they do not, the dashboard shows the appointment count alone until values start getting entered. No tile ever shows a dollar figure the system cannot point to.
Three items, all of them agency level. Nothing here sends you agent by agent.
| Needed | If it does not arrive |
|---|---|
| GoHighLevel agency access across all sub-accounts | Nothing multi-client can be built. This is the one hard blocker. |
| Hourly rate for the payroll figure | That tile ships hidden and switches on later. |
| Definitions for hands raised and tire kickers | Those two tiles ship hidden. Nothing else is affected. |
Anything that arrives late ships in the reduced form above rather than pushing the date. Late input costs a tile, not a week.
Property search inside GoHighLevel, with prospect activity and trigger actions, depends on a working IDX feed per client, supplied ready to use. That is your side of the line.
MLS access is granted per broker, per MLS, on signed paperwork, and approval commonly runs 3 to 10 business days per request. Across a book of agents that is a separate approval for each one, each waiting on a different broker's signature. Engineering time does not compress that, and vendors are not permitted to file it for you.
Ask your IDX provider whether their GoHighLevel product already pushes prospect search activity into GoHighLevel as contact events. If it does, this becomes setup rather than development, and it gets cheaper for you.
Four of your KPIs need data that is not in your system today. Here is the vendor, the data it returns, what a 2,432 record run actually produced, and why this gets metered per agent instead of folded into a flat fee.
People Data Labs is a data broker. It sells business profile records, assembled from public web profiles, company sites, resumes, and licensed third party feeds, and it sells them one record at a time. You send an email address, or a name and a company. It sends back a profile.
Here is one real returned record, with the identifying values removed. This is the shape of what you are buying.
| Field | What came back |
|---|---|
| Job title | chief operating officer |
| Employer | Named, with headcount band, 51 to 200 |
| Work history | Six prior positions, each with employer, title, and dates |
| Education | Named university, degree, field of study |
| Skills | 42 tags, including budgeting, contract negotiation, customer service |
| Bio | A written professional summary, 40 words |
| Work email | Present, and it matched the record |
| Phone numbers | Two, both business lines |
| Social profiles | LinkedIn and Twitter, with usernames and profile IDs |
| Location | City, state, country |
| Personal email | Not returned |
| Street address | Not returned |
This is not a demo number. It is a completed production run against People Data Labs, on a list of business contacts, scored afterward record by record.
One in eight records that came back was a different human being than the one requested, and the vendor's own confidence score did not flag it. That is the single most important number on this page.
Coverage across the 500 records that did return something:
| Field | Present |
|---|---|
| Work history | 500 of 500 |
| Work email | 463 of 500, 93% |
| Education | 425 of 500, 85% |
| Mobile phone | 376 of 500, 75% |
| Personal email | 169 of 500, 34% |
| Street address | 159 of 500, 32% |
| ZIP code | 155 of 500, 31% |
That run was against corporate email addresses at named companies. Business contacts are the home ground for this dataset, and it still missed on four out of five. Your agents' databases are homeowners and past clients on personal email. Expect the hit rate to go down from 21%, not up.
Knowing who you are calling before you call them. Where they work, what they do, how long they have been there, what they did before, and where to find them socially. An agent who knows the person on the other end runs a warehouse team and has been there nine years has a better conversation than one who knows nothing. That is real and it is worth paying for.
Two thirds of the paid records came back with no mailing address at all. People Data Labs sells who someone is professionally. It does not sell where they live.
Verified cell phones and mailing addresses come from skip trace vendors, and they are built on completely different source data: property records, deed and title filings, utility hookups, and credit header data. That is the data a listing agent actually wants, and People Data Labs does not sell it.
People Data Labs only charged for the 500 records that matched. The 1,932 misses were free. Skip trace vendors bill per lookup, hit or miss. Run the same list through a skip trace API and you pay for all 2,432, including the four out of five that return nothing.
Your clients arrive carrying their own lists. That is the problem.
An agent who uploads 4,000 contacts is 4,000 billable lookups on day one, before a single appointment exists. The agent next to them with 400 contacts costs a tenth of that. There is no flat monthly number that covers both without either overcharging one or absorbing the other, and the absorbed one is the agent who bulk imports a purchased list the week they sign up.
So it does not sit inside the monthly. It gets metered and charged to the agent who runs it.
A contact gets enriched when it reaches a stage where the extra data changes what happens next. Bulk enriching an entire database on import is how this turns into a four figure bill with nothing to show for it.
Sub-accounts already carry a wallet, and HighLevel already meters usage against it for its own services with an agency markup on top. For an outside vendor like People Data Labs or a skip trace API, HighLevel exposes a wallet charges endpoint that debits a sub-account for a custom amount and checks the balance before the call runs. So a lookup can be priced, charged, and shown to the agent inside GoHighLevel, at your rate, with no separate invoice and no card on file anywhere else.
That turns enrichment from a cost you absorb into a margin line you own. It needs a registered marketplace app to do it, which is scoped and priced with the enrichment build, not with this one.
Whichever vendor you pick, the account is opened by Jack Ryan A.I. and billed directly to you at cost. Nothing routes through me and I take nothing off the top, so you see the true per record price, you can throttle or kill it the same day, and you set your own markup to your agents rather than inheriting mine.
100 real contacts pulled from a live client's GoHighLevel, run through People Data Labs and two skip trace vendors, scored the same way the run above was scored: match rate, correct person rate, and how many usable cell phones and mailing addresses actually land.
You get a cost per usable record for each vendor and then you decide. Quoted as a fixed fee. The enrichment build gets quoted after it, once there is a vendor worth building against.
No enriched field writes to a contact record without a confirmation step. A confident wrong match is worse than no match, and 62 of the 500 paid records were exactly that.
Age, sex, and family status fields are never used for targeting. Enrichment vendors return them. Housing advertising is governed by the Fair Housing Act, and targeting housing marketing on those attributes is the specific conduct that has drawn federal enforcement against major advertising platforms. Those fields stay out of any audience or filter built here.
The clearest way to avoid an argument later is to write down now what this does not cover.
Scheduled pull running unattended, callback field probed, classifier definitions agreed with you.
Dashboard views, the GoHighLevel rebuild, the pipeline view from GoHighLevel deal values.
Client tools, embedding, testing, documentation, handover.
Payment is 50% at signing and 50% on delivery, both tied to the calendar.
Several inputs sit outside both of our hands, including MLS approvals that run on their own clock. Tying the second payment to those would mean the build gets held up by a clerk neither of us has met. What ships on delivery is defined by what arrived by the dates in section 05, and that table gets agreed before work starts.
Handover includes the running system, the source, and written operating documentation.
Signing here starts the clock. Work begins August 8 and delivery is three weeks from that date.
Got it. You will have a confirmation reply shortly with a copy for your records. I start August 8.