Pulling Franchise-Level Data Out of a System That Doesn’t Want to Give It Up

How consolidating four disconnected tools across a 19-territory franchise network turned into a lesson about credentials, not code.

By David Henderson • Unwired Web Solutions • Updated September 2026 • 7-minute read

THE NUMBERS 19 territories · 4 disconnected tools consolidated · 12 months of Salesforce history · 3 years of GA4 + GBP history · 40–55 page strategy report generated in ~3 minutes per territory

DIRECT ANSWER When a franchise network’s performance data lives across several disconnected systems, the pipeline is usually the easy part. The actual blocker is organizational: the highest-value data source is often gated behind someone else’s willingness to hand over API access. My team and I built a private platform consolidating Salesforce, Google Analytics, Google Business Profile, and a DashThis subscription for Skedaddle’s 19 franchise territories — while continuing to work around Salesforce data that, months in, still comes out as a manual CSV export.

Why was this franchise network’s data scattered across four tools?

Before this platform existed, performance data for Skedaddle’s franchise network lived in four separate places: Salesforce for job volume and revenue, Google Analytics for website traffic, Google Business Profile for local search performance, and a DashThis subscription stitching some of that into shareable reports.

Getting a real picture of a single territory meant pulling from all four and building a spreadsheet by hand — every time someone needed an answer. Multiply that across 19 territories and it stopped being a reporting process and started being a full-time job nobody had budgeted for.

Why wouldn’t Salesforce just hand over the data?

This is the actual “system that doesn’t want to give it up.” Salesforce data came out as a manual CSV export, not a live feed. A proper Connected App integration was technically straightforward — but it needed someone on the client side to issue the credentials.

Until that clears, no amount of engineering effort makes the Salesforce half of this system faster. The code isn’t the constraint. The person with the login is.

Most “we need an API integration” projects get treated as a technical problem, timelined and scoped like one. In practice, on a franchise account, the actual bottleneck is almost always a person, not a system. A data-consolidation plan that doesn’t account for the credential-holder problem isn’t a complete plan — it’s a plan that works right up until it needs someone else’s cooperation.

What we built instead of waiting on Salesforce

Rather than block the whole platform on one pending approval, we built everything with a legitimate path first: three years of Google Analytics and Google Business Profile history across all 19 territories, consolidated into one structure, with the most recent 12 months of Salesforce data brought in manually while the API request sat with the client’s ops team.

The territory dashboard that replaced four tools with one page

What’s live now, per territory and for the network as a whole:

• An overview page showing all 19 territories with status, revenue, and job counts, plus an interactive network map.

• Individual territory dashboards: trailing 12-month revenue and jobs from Salesforce, species-by-species revenue breakdown against the network average, and top suburbs by revenue and job volume.

• Google Business Profile performance — searches, calls, and website clicks by month.

• Google Search Console data — organic clicks and impressions.

• Seasonal patterns — when each species peaks in that territory’s climate.

Instead of pulling from four different tools and rebuilding a spreadsheet, opening one page now answers the question.

The report that used to eat an afternoon in Google Docs

The Strategy Report Generator now produces a full 40–55 page franchise digital marketing strategy document per territory — the same document that used to get built manually — in about 3 minutes, using Claude Opus 5 against the real, consolidated data.

A few things about how it stays honest rather than just fast: species performance is benchmarked against the real average across all 19 territories, not an assumed one. Suburb-level data only appears where it’s actually been confirmed — Hamilton, Durham, Milwaukee, and Madison, at the time of writing — and everywhere else the report says “Unknown” instead of guessing. And multi-territory franchises are handled correctly rather than flattened into one location: Hamilton alone covers Kitchener, Guelph, Cambridge, Niagara, and Oakville as one territory, which is also why a “19 territories” count and a “60-plus locations” count can both be true about the same network — they’re counting different things.

Showing “Unknown” instead of inventing a plausible-sounding number is the same principle behind everything else on this site: a report that’s occasionally incomplete but always true beats one that’s always complete and sometimes wrong.

Building content proportional to what the data actually says

The suburb-page generator takes a strategy report’s recommendation — build a page for a specific suburb — and produces the actual page content, sized to the real numbers instead of a template. If raccoons account for 38% of a suburb’s revenue, raccoon content gets roughly 38% of the species coverage on that page, not an equal split with every other species regardless of relevance.

Every fact on the generated page is tagged with where it came from — Salesforce, the GBP listing, the client’s own website, a municipal source, or “confirm with franchisor” where nothing backs it up yet — so a reviewer can check any claim before it goes live. Pages move through a Draft → In Review → Approved → Exported workflow before anything reaches WordPress.

What’s still not solved

• Salesforce still isn’t a live connection. The CSV-export workaround stays in place until the Connected App credentials come through.

• Fact-checking suburb claims currently depends on a manually confirmed list (Hamilton, Durham, Milwaukee, Madison). A Sonar/Perplexity research integration is in progress to verify neighbourhood names, county boundaries, and local competitors live, with a source URL attached to every fact — which should close the last real gap in accuracy.

• Google Business Profile posting is still manual. The target is 20–25 posts per territory per month, which is not realistically doable by hand across 19 territories — an automation pipeline for this is planned but not live.

• Approved content still moves to WordPress by hand. A direct push is possible once WordPress REST API credentials are in place.

The real lesson for franchise data teams

Most people building a franchise-scale reporting system assume the hard part is the pipeline — the APIs, the schema, the automation. The genuinely hard part is that a piece of the puzzle usually belongs to someone outside your team, and no amount of good architecture fixes a credential request sitting in someone else’s inbox.

Design around that from day one. Build everything you can with the access you already have — which is exactly why the GA4, GBP, and DashThis consolidation shipped while Salesforce access was still pending — and don’t let one blocked integration hold the rest of the system hostage.

This kind of pragmatic data consolidation is part of how Unwired Web Solutions builds reporting infrastructure for franchises and multi-location organizations. It connects to my broader field guide, “50 Things I Actually Do With AI Inside a Working Agency”, and sits alongside “The Client Dashboard That Replaced a Monthly Reporting Call” as the other half of this data-and-reporting story.

Frequently asked questions

What was the actual bottleneck in consolidating this franchise network’s data?

Not the code. Three of the four data sources — Google Analytics, Google Business Profile, and the reporting layer replacing DashThis — had a clear, buildable path. The fourth, Salesforce, required a Connected App integration that depended on someone on the client side issuing credentials. That approval, not the engineering, set the pace.

How many territories does this cover, and why do different documents cite different counts?

The platform covers 19 franchise territories. Some territories span multiple named service areas — Hamilton alone covers Kitchener, Guelph, Cambridge, Niagara, and Oakville — which is why a location or page-level count elsewhere can run higher than the territory count without the two figures actually disagreeing.

Why show “Unknown” instead of estimating suburb-level data that isn’t confirmed yet?

Because an estimate presented as fact is worse than an honest gap. The report only states suburb-level detail where it’s been confirmed, and says so plainly where it hasn’t — the same standard applied to every claim on this site.

How does the system decide how much content to generate for each species or topic?

Proportionally to real revenue share. A suburb where one species accounts for a given percentage of revenue gets roughly that same percentage of the species content on its page, rather than an even split that ignores what the local data actually shows.

What happens when a Salesforce-style access request is delayed?

Everything that doesn’t depend on it keeps moving. In this case, three of the four data layers were built and live before the fourth cleared, and the fourth was worked around with a manual export rather than left to block the whole project.

Need a unified view of your multi-location data? If your team spends hours switching between tools, exporting CSVs, and stitching spreadsheets together, I can assess the data sources, the access constraints, and the credential-holder problem specifically — then design a pipeline that ships the parts you can build now instead of waiting on the parts you can’t. Primary CTA: Explore the System Build offer Secondary CTA: Subscribe to the newsletter for the next Build Log post.