Endeavour GTM Architecture

Endeavour is a Dutch full-service digital agency of about 150 people, run by three commercial directors who share one number: 240 leads a month. The agency sells five genuinely different things, strategy, creative, websites, AI products, and data services, and the outbound engine pointed at all of it was one generic machine.

Nobody had a clean answer to what Endeavour was actually selling and to whom. Pointing a single list-and-message setup at five different offerings produced noise instead of signal: a company that looks right for a website rebuild has nothing to do with a company that looks right for an AI product, but the machine was scoring them the same way.

Split the portfolio into separate service tracks and build the GTM architecture per track: each one gets its own pain condition to watch for in the market, its own list-build, its own messaging framework, and its own sending setup, all rolling up into one weekly action report the three directors can read together.

I came in with the number already fixed: 240 leads a month, agreed on by Endeavour's three commercial directors before I looked at anything else. My first question wasn't how to hit that number, it was what a lead even meant here, because Endeavour sells five genuinely different things: strategy, creative, websites, AI products, and data services. A generic outbound engine was already pointed at all five at once, and it was producing volume without producing sense, leads that looked promising for one service and irrelevant for another, all landing in the same undifferentiated queue.

Once that was clear, the fix wasn't a copy rewrite, it was structural. I split the portfolio into service tracks and gave each one its own miniature GTM setup: a pain condition specific to that service, something visible in the market that signals a company might need exactly this and not agency services in general, a list-build method tuned to find companies showing that condition, a messaging framework written for that exact situation, and its own sending infrastructure so the five tracks wouldn't drown each other out.

Building five of these back to back could easily have turned into five separate projects with five separate quirks. Instead I built one reusable skeleton, pain condition, list, message, send, and ran each track through it. That kept the build itself from multiplying five times over, while still letting each track look completely different out in the market: a company with a stale website and a company sitting on years of unused data are showing two entirely different signals, even if the underlying architecture that finds them is the same.

The part that took the most care wasn't any single track, it was stitching five of them back together for the people who actually have to act on the output. Three commercial directors can't watch five separate feeds and reconstruct a coherent picture of the week, so on top of the five tracks sits one weekly action report: which companies showed a relevant signal that week, and for which service.

That's the shift that mattered most. The question stopped being "where are my 240 leads" and became "which companies are showing the pain this specific service solves, this week." It's a harder question to ask and a much easier one to act on.

The campaign is live and learning. Each track feeds its own slice of the weekly report, and refinement now happens per track instead of across one blended list, so a change to the AI products track doesn't ripple into how the websites track gets read.