Every Portfolio Company Reinvents the Wheel

You have ten portfolio companies. Each one is hiring its own head of sales ops, buying its own tools, building its own outbound infrastructure from scratch, and making the same mistakes the last three portcos made.

One portco picks HubSpot. Another picks Salesforce. A third uses Attio. None of them connect their CRM to signal data. None of them have documented playbooks. None of them can tell you, with precision, what their cost per qualified meeting is.

This is the default state of GTM at most venture-backed and PE-backed B2B companies. Every new investment starts at zero. The fund writes the cheque, the founder hires a VP Sales, and six months later the board is asking why pipeline is still unpredictable.

The problem is not the people. The problem is that there is no shared GTM infrastructure across the portfolio. Each company is funding its own R&D into something that should be a solved problem: how to build a repeatable, signal-led outbound and inbound system that produces pipeline within 30 days and transfers to the internal team within 120.

GTM engineering for portfolio companies is the practice of designing a standardised go-to-market system, then deploying it across multiple companies in a fund's portfolio so that each portco reaches pipeline production faster, at lower cost, and with consistent reporting back to the fund.

This article breaks down what that looks like in practice: the system, the case studies, the economics, the timeline, and the common mistakes that derail portfolio-wide GTM.

The Real Cost of Starting From Zero: Why 5-8 Months Per Portco Kills Portfolio Returns

The hidden cost of the "each portco figures it out" approach is not just money. It is time, and time compounds across a portfolio.

Here is what the typical timeline looks like when a portco builds GTM from scratch:

• Months 1-2: Post-close. The founder is still celebrating. GTM planning has not started. Maybe someone writes a job spec for a VP Sales or Head of RevOps.

• Months 2-4: Recruiting. The average time to hire a senior revenue operations leader is 3-4 months. During this period, pipeline generation is either nonexistent or handled by the founder making warm introductions.

• Months 4-6: Onboarding. The new hire arrives, audits the existing (usually broken) CRM, selects tools, negotiates contracts, and starts building. They are learning the ICP, the product, and the market at the same time.

• Months 6-8: First real output. The system starts producing pipeline. But it has not been tested, iterated, or optimised. The first sequences are version one. The signal definitions are guesses.

That is 5-8 months per company before anything meaningful happens. Now multiply that across a portfolio of 10 companies. That is 50-80 company-months of dead time. If the average portco has a monthly burn of $200K-$500K, the portfolio is burning through $10M-$40M in runway before GTM infrastructure is even functional.

And every one of those portcos is making independent mistakes. One discovers after four months that their email domain reputation is destroyed because nobody set up proper domain warming. Another realises their CRM lifecycle stages do not match how their buyers actually purchase. A third burns $50K on an agency that delivers a spreadsheet of unqualified contacts and calls it "pipeline."

These are not hypothetical failures. They are the standard experience for B2B companies building GTM from scratch. The fund is paying for each portco to learn lessons that were already learned at the last three investments.

The portfolio-wide approach eliminates this waste. The system is designed once, proven once, and deployed across every qualified portco. The second company gets a system that has already been refined by the first. The fifth company gets a system refined by four previous installs.

What Portfolio-Wide GTM Engineering Looks Like

Most funds think about GTM as a headcount problem. A portco needs pipeline, so it hires salespeople. When pipeline is still inconsistent, it hires more salespeople. Or it brings in an agency that rents SDR seats and delivers a spreadsheet of "leads" with no system underneath.

GTM engineering treats go-to-market as an infrastructure problem. The question is not "how many people do we need?" but "what system do those people need to operate inside?"

It is not more outbound. It is an operating system for outbound.

The difference matters because infrastructure scales. Headcount does not.

A well-designed GTM system has three layers:

1. The Outbound System

This is the engine that identifies in-market accounts, enriches contacts, and routes them into personalised sequences. It runs on signal data (funding rounds, executive changes, hiring patterns, tech installs, website visits) rather than static lists.

When built properly, this system means an SDR opens their CRM to a prioritised queue of accounts that are already showing buying signals. They spend their day selling, not researching.

2. The Inbound Engine

Every hand-raise (demo request, form fill, inbound email, LinkedIn message, webinar registration, referral) gets captured, enriched, qualified, routed, and responded to within minutes. Not hours. Not "whenever the AE checks their inbox."

AI-assisted triage classifies the request, suggests the next step, and drafts the first response. The rep reviews, personalises, and sends. Speed-to-lead is measured and reported.

3. The Command Layer

CRM architecture, dashboards, lifecycle stages, attribution, playbooks, and SOPs. This is what makes the system survivable. When someone leaves, the system keeps running because the logic lives in documented infrastructure, not in someone's head.

These three layers are not novel. Every good VP Sales would build some version of this. The problem is that building it takes 6 to 12 months when you start from scratch, and most portcos do not have that runway before the board wants to see results.

Why VCs Should Think About GTM as Infrastructure, Not Headcount

Funds invest heavily in product infrastructure. They advise portcos on engineering practices, security posture, and cloud architecture. They have opinions about which database to use and how to structure the engineering team.

GTM gets none of this rigour.

The typical approach: hire a VP Sales, give them a budget, and wait. If it works, great. If it does not, replace the VP Sales and try again. This cycle burns 12 to 18 months per iteration.

There is a better model. Treat GTM the same way you treat product infrastructure. Define the reference architecture. Build it once. Deploy it across every portco that meets the readiness criteria.

This means:

• Standardised CRM architecture so every portco reports pipeline the same way, and the fund can compare performance across the portfolio

• Shared playbooks so lessons from one portco's outbound motion feed into the next

• Consistent tooling so the fund builds institutional knowledge about what works, rather than starting fresh with each investment

• Faster time-to-revenue because the portco is not spending its first six months figuring out infrastructure

The fund benefits too. When every portco reports pipeline using the same definitions, the managing partner can actually compare GTM performance across the portfolio. "Pipeline created" means the same thing at Company A and Company B. "Qualified meeting" has the same criteria. Attribution works the same way.

This is not theoretical. It is how operating companies with multiple business units have worked for decades. The only reason funds have not done it is that GTM has historically been treated as art rather than engineering.

Case Studies: The System Working Across Different Industries

The portfolio-wide GTM model works because the underlying system has been proven across different verticals, deal sizes, and company stages. Here are five engagements that demonstrate the system's adaptability.

m3ter: Usage-Based Billing SaaS (Series A, $35.7M raised)

The situation: m3ter needed to build pipeline against a specific ICP of finance and engineering leaders at SaaS companies evaluating usage-based pricing. They had Salesforce Ventures backing but needed a system that could scale outbound and ABM simultaneously.

What AC built: A combined LinkedIn Ads and phone-first outbound ABM system targeting 312 named accounts across 3 ICP segments. Signal infrastructure detected when target accounts were actively evaluating billing changes. Lead routing was configured to sub-90-second response times.

The results:

• $2.4M pipeline created

• $7M+ total pipeline influenced

• 42 meetings booked

• CPL reduced from $5,171 to $334 (4.71x ROAS)

• $447K closed-won revenue

The outcome: m3ter was subsequently acquired by Salesforce. The GTM system ran through to acquisition, meaning it remained operational and producing pipeline during the entire acquisition process.

"Advanced Client didn't just run ads for us. They built the entire go-to-market system." - John Griffin, CRO, m3ter

Portfolio relevance: This is the model for a Series A portco with strong product-market fit and a technical ICP. The system scaled from zero to $2.4M in direct pipeline, and the architecture was robust enough to operate through an acquisition.

Verifile: Background Screening (Established B2B Services)

The situation: Verifile had zero outbound infrastructure. No sequences, no signal data, no dedicated outbound tooling. They needed to reach HR Directors and Heads of Compliance at enterprise organisations, including FTSE 100 companies.

What AC built: A phone-first outbound system using Clay, Instantly, Prospeo, and Attio. Built from zero to live in 28 days. The system was designed for complete handover from the start.

The results:

• $312K new revenue

• 17 FTSE 100 meetings booked

• System live in 28 days from zero infrastructure

• 100% system handover

The outcome: Verifile runs the system independently. No ongoing AC involvement. The playbooks, sequences, and signal definitions are fully owned and operated by Verifile's internal team.

"From cold to FTSE 100 in 90 days." - Steven Davies, Sales Manager, Verifile

Portfolio relevance: This is the proof point for rapid deployment and full ownership transfer. 28 days from zero to live. 100% handover. The portco operates independently. This is what "install, not retainer" means in practice.

The Cosine: Architectural Design Practice

The situation: The Cosine needed outbound that sounded like the founder, not like a sales team. Their market is high-value architectural projects where relationships and voice matter more than volume.

What AC built: Cold outbound (email and LinkedIn) powered by Clay, written in the founder's voice. The system used AI-assisted drafting with human QA to maintain the founder's tone across all sequences.

The results:

• $500K to $850K retainer closed (largest in company history)

• 137 calls booked

• 4-10 meetings per week

The outcome: The system proved that signal-led outbound works in professional services, not just SaaS. The largest deal in company history came from cold outbound.

"We just closed our biggest retainer ever. Minimum $500K, likely closer to $850K." - Matt Schroeder, Co-Founder & CEO, The Cosine

Portfolio relevance: This demonstrates the system working for a non-SaaS portco. Professional services, high-ACV, relationship-driven sales. The same architecture adapts to the company's voice and market.

Studio X: Creative Agency

The situation: Studio X had built their entire revenue base on referrals. Zero outbound capability. They needed a systematic way to create pipeline without depending on inbound word-of-mouth.

What AC built: A complete outbound system from scratch, including signal infrastructure, contact enrichment, sequence library, and CRM architecture.

The results:

• $5.7M pipeline value

• 50+ sales opportunities

• Built from zero outbound (previously referrals only)

Portfolio relevance: This is the model for a portco that has product-market fit and strong delivery but no outbound motion. The system creates a second revenue channel that does not depend on the founder's network.

RAIN Group: Sales Consulting

The situation: RAIN Group needed a signal-led outbound system built inside their existing Salesforce instance, with full ownership transfer so their team could operate it independently after the engagement.

What AC built: 7 tools built and transferred, 3 buying conditions modelled, approximately 15 live buying signals detected. The entire system was built inside RAIN Group's Salesforce.

The results:

• 12-week build to full handover

• 7 tools built and transferred

• 100% owned by RAIN Group post-engagement

The outcome: RAIN Group owns and operates the system independently.

"Outstanding quality, tailored to our business." - Jason Murray, CSO, RAIN Group

Portfolio relevance: This shows the system working for a mature consultancy. The 12-week timeline to full handover proves that even complex B2B organisations with established Salesforce environments can absorb the system.

The Standardised RevOps Stack: What Gets Installed at Each Portco

Here is the full standardised GTM install when deployed across a portfolio. Every portco gets the same architecture, customised for their ICP, market, and existing tooling.

The key principle: everything is built inside the portco's own tools, on their own domains, with full documentation. When the engagement ends, the portco owns the system completely. They are not renting infrastructure from an external provider.

It is not a new tool. It is the way your current tools run together.

Portfolio Operating Partner's Checklist

If you are the operating partner responsible for GTM across a fund's portfolio, here is the framework for evaluating and deploying a standardised GTM system.

Phase 1: Portfolio Assessment (Week 1-2)

• Audit each portco against the readiness criteria (see "What Makes a Portco Ready" below)

• Categorise portcos: ready now, ready in 3 months, not yet

• Identify which portcos share similar ICPs or verticals (shared learnings will compound faster)

• Assess existing CRM and tooling across the portfolio. Note which portcos use the same CRM

• Review each portco's current outbound efforts. Document what has been tried and what failed

• Estimate the cost of the current approach: total spend on agencies, tools, and RevOps hires across the portfolio

Phase 2: Pilot Selection (Week 2-3)

• Select 1-2 portcos for the pilot. Choose companies with confirmed product-market fit and AEs ready to work pipeline

• Confirm founder/CEO buy-in at the pilot portcos. The system requires access to CRM, domain, and sales team

• Define success metrics for the pilot: pipeline created, meetings booked, time to first pipeline, cost per meeting

• Set the reporting cadence: what the portco sees weekly, what the fund sees monthly

Phase 3: Deploy and Measure (Month 1-4)

• Execute the 120-day build at the pilot portcos

• Track results against the defined success metrics

• Document what needed customisation vs. what was standard across installs

• Prepare the portfolio-wide rollout plan based on pilot learnings

Phase 4: Scale Across Portfolio (Month 4-12)

• Deploy to the next cohort of 2-3 portcos per quarter

• Feed pilot learnings into each subsequent install

• Establish the portfolio-level reporting dashboard

• Review and update the readiness criteria based on what you have learned

Phase 5: Ongoing Portfolio Operations

• Quarterly portfolio GTM review: compare pipeline metrics across all portcos

• Share winning sequences, signal definitions, and playbook improvements across the portfolio

• Reassess "not yet" portcos against updated readiness criteria

• Track portfolio-wide ROI: total pipeline created, total cost, and time saved vs. independent builds

Staggered Rollout Timeline: How 5 Portcos Get Deployed Over 12 Months

You do not try to install the system at five companies simultaneously. You sequence it so each deployment benefits from the previous ones.

By Month 12, all five portcos are running on standardised GTM infrastructure. The fund has a real-time portfolio view of pipeline performance across every company, and each portco owns its system completely.

The stagger also manages risk. If something in the playbook needs adjustment, you discover it at Portco 1, fix it, and the correction is built into every subsequent install. By Portco 5, the system has been refined through four iterations.

ROI Model: AC Install vs. Independent Hiring Across a 5-Company Portfolio

The economics are concrete. Here is the comparison for a fund deploying across 5 portcos.

Scenario A: Each Portco Hires Its Own RevOps Team

Midpoint estimate: $286K per portco, $1.43M across 5 portcos (using conservative salary + tools + recruiting only, excluding opportunity cost and mis-hire risk).

Scenario B: Standardised GTM Install via AC

Midpoint estimate: $50K per portco, $250K across 5 portcos.

The Delta

The cost saving is significant. But the real return is the 5-7 months of compressed time-to-revenue per portco. For a fund with a defined hold period, getting each portco to predictable pipeline 6 months earlier changes the return calculation on every investment.

For context: AC's engagement with m3ter alone created $2.4M in direct pipeline and $7M+ in total pipeline influenced. Even if each portco generates $500K in additional pipeline from the system (well below the m3ter result), that is $2.5M in pipeline across 5 portcos from a $250K investment.

What Makes a Portco Ready: Detailed Criteria

Not every portfolio company is ready for a GTM system install. Deploying infrastructure before the foundations are in place wastes time and money. Here is how to assess readiness in detail.

Must-Have Criteria (All Required)

1. Product-market fit confirmed
This means customers are buying and retaining, not just trialling. Look for: positive unit economics, reference customers who would take a call from a prospect, and a product that solves a problem the buyer is actively trying to fix. If the portco is still iterating on what they sell or who they sell to, the GTM system will be built on a shifting foundation.

2. ACV of $10K+ per deal
The signal-led outbound system is designed for considered B2B purchases where there is a buying committee, a defined evaluation process, and a sales cycle measured in weeks or months. Self-serve products or low-ticket transactions do not produce enough return per deal to justify the infrastructure investment.

3. At least 2 AEs or account managers who will work the pipeline
The system creates pipeline. It does not close deals. If there is nobody to take the meetings, the system generates activity that goes nowhere. Two AEs is the minimum to ensure pipeline gets worked consistently and there is enough data to measure conversion.

4. A TAM of 5,000+ addressable accounts
The signal-led approach filters a large universe of accounts down to those showing buying intent right now. If the total addressable market is only 500 accounts, signal-based filtering removes too many targets. The system works best when there is a large pool to filter from.

5. B2B SaaS or B2B services business model
The system is designed for B2B selling motions with multi-stakeholder buying committees. B2C, consumer, e-commerce, and marketplace models require fundamentally different GTM infrastructure.

Strong Readiness Indicators (Not Required, But Accelerate the Build)

• Existing CRM with some data (even if the architecture is messy). Starting with a CRM that has historical deal data is faster than building on an empty instance

• A founder or revenue leader who can articulate the ICP (even if it is not formalised). If someone in the company can describe who buys and why, the ICP definition phase takes days instead of weeks

• Previous outbound attempts that underperformed. This usually means the problem is infrastructure, not market fit. The demand exists; the system to capture it does not

• Series A or later funding. Sufficient runway to execute a 120-day build without existential pressure

• A competitor's customers who are dissatisfied. Signal infrastructure can detect when competitor accounts show signs of evaluating alternatives

Not Ready Yet (Defer Until Milestones Are Met)

• Pre-product-market fit. Still iterating on the product or the buyer persona. Build the system after the product is proven, not before

• ACV under $10K. The economics do not support the system. Consider product-led growth or inbound-first motions instead

• No sales team at all. The system creates pipeline that needs to be worked by humans. Hire at least 2 AEs first

• B2C or consumer business model. The entire architecture is designed for B2B buying motions

• Founder is not committed to outbound. If the CEO views outbound as "spammy" or is not willing to invest the time to define the ICP and review messaging, the engagement will stall

A portfolio assessment takes one to two weeks. AC reviews each portco against these criteria and produces a prioritised deployment sequence: which companies first, which later, and which need to hit certain milestones before they qualify.

Common Mistakes VCs Make with Portco GTM

After building GTM systems across 30+ B2B brands, patterns emerge. Here are the seven most common mistakes funds make when trying to accelerate portco go-to-market.

1. Treating GTM as a Hiring Problem Instead of a Systems Problem

The reflexive response to "we need pipeline" is "hire a VP Sales." But a VP Sales without infrastructure is a strategist without an army. They spend their first 6 months building the system that should have been waiting for them. Hire the person after the system is built, and they become productive from day one.

2. Letting Each Portco Choose Its Own Stack Independently

When portco A uses HubSpot, portco B uses Salesforce, portco C uses Pipedrive, and portco D uses Attio, the fund loses all ability to compare performance, share learnings, or build institutional knowledge. You do not need to mandate a single CRM, but you do need standardised architecture and reporting definitions that work across different platforms.

3. Confusing Agency Retainers with System Building

An agency retainer rents you activity. Emails get sent, calls get made, a report appears monthly. But when the retainer ends, you own nothing. No playbooks, no signal definitions, no CRM architecture, no documented process. You start from zero again. The question to ask is not "how many meetings did the agency book?" but "what system does the portco own after the engagement?"

4. Deploying GTM Before Product-Market Fit Is Confirmed

Signal-led outbound amplifies what is already working. If the product does not solve a problem buyers are actively trying to fix, no amount of outbound infrastructure will create genuine demand. Push portcos to confirm PMF first, then deploy the system. Doing it in reverse burns money and creates false signals about market fit.

5. Not Measuring Across the Portfolio

If each portco defines "qualified meeting" differently, reports pipeline in different formats, and uses different attribution models, the fund has no way to compare GTM performance. The managing partner sees five different dashboards that cannot be cross-referenced. Standardised reporting is not bureaucracy. It is the only way to identify which portcos are performing and which need intervention.

6. Waiting Too Long After the Investment

The best time to install GTM infrastructure is the first 90 days post-close, while the founder is still in "build mode" and the team is small enough to adopt new systems without change management friction. By month 6, the portco has already hired someone, bought tools, and built a system (or a mess). Retrofitting is harder and more expensive than building from the start.

7. Optimising for Speed Without Building for Transfer

Some funds push for "get meetings fast" without caring how the meetings are generated. This leads to short-term plays (mass email blasts, purchased lists, outsourced SDR farms) that produce activity but not infrastructure. When the activity stops, pipeline stops. The system should be designed for transfer from day one: built inside the portco's tools, documented, and handed over so the portco operates it independently.

Reporting and Visibility: What the Fund Sees Across All Portcos

When every portco runs on the same GTM architecture, the fund gets a portfolio-level view that is impossible to achieve when each company reports independently.

Portco-Level Reporting (Weekly)

Each portco's internal team sees:

• Pipeline dashboard: New pipeline created, pipeline by stage, pipeline velocity, deals progressing vs. stalled

• Activity metrics: Sequences sent, reply rates, positive reply rates, meetings booked, show rates

• Signal performance: Which buying signals are converting to meetings, which are not

• Channel attribution: Pipeline from outbound vs. inbound vs. ads vs. referrals

• Speed-to-lead: Time from inbound request to first response, measured and benchmarked

Fund-Level Reporting (Monthly/Quarterly)

The operating partner or managing partner sees:

• Portfolio pipeline summary: Total pipeline created across all portcos, broken down by company

• Cost per qualified meeting by portco: Direct comparison using standardised definitions

• Conversion rates by stage: Which portcos are converting pipeline to revenue efficiently, and which have bottlenecks

• System health: Are playbooks being followed? Are signals being acted on? Are sequences being updated?

• Deployment progress: Which portcos are live, which are in build, which are in the assessment queue

• Shared learnings log: What worked at one portco that should be rolled to others

What Makes This Possible

The reporting works because the CRM architecture is standardised. "Pipeline created" means the same thing at every portco. "Qualified meeting" uses the same criteria. Lifecycle stages map to the same definitions. Without this standardisation, the fund is translating between five different reporting frameworks every quarter, and the comparisons are approximate at best.

How to Pitch This to Your Portfolio

If you are an operating partner and you see the value in portfolio-wide GTM, you still need buy-in from portco CEOs and revenue leaders. Here is how to frame it.

What to Say to the Portco CEO

Lead with the time saving, not the cost saving. Most founders care more about speed than budget. Frame it as: "You can have a working pipeline system in 30 days instead of 8 months. Your AEs start getting meetings next month instead of next year."

Address the control concern immediately. Founders worry about losing control of their GTM. Make it clear: "The system is built inside your tools, on your domains, with your team trained to operate it. You own everything. Nothing is hosted externally. When the build is done, you run it."

Use a peer example. If Portco 1 has already been through the process, ask their CEO to take a 15-minute call with Portco 2's CEO. Peer validation from another portfolio company is more convincing than any slide deck.

What to Say to the VP Sales or Revenue Leader

Frame it as an accelerator, not a replacement. "This is the system you would build if you had 6 months and an unlimited budget. You are getting it in 30 days, fully documented, so you can focus on strategy and closing instead of building plumbing."

Show the playbook, not just the pitch. Revenue leaders want to see what they are getting: the CRM architecture, the signal definitions, the sequence templates, the dashboards. Walk them through the deliverables, not the theory.

What Not to Say

• Do not position it as "the fund is standardising your sales process." This triggers resistance. Position it as "the fund is giving you infrastructure so your team can sell faster."

• Do not compare portcos to each other in the pitch. That comes later, in reporting. In the pitch, each portco should feel like they are getting a bespoke system (they are, the architecture is standardised but the ICP, messaging, and signal definitions are tailored to each company).

The Advanced Client Model: How AC Works with VC and PE Firms

Advanced Client installs AI-powered go-to-market systems for B2B companies. The company was founded in 2023 by Tom Grainger (CEO) and Louis Young (COO), and both founders work on every engagement personally. There is no account management layer and no offshore fulfilment.

AC's standard engagement runs three motions:

1. LinkedIn Ads: ABM-led paid demand against named accounts, with attribution via Fibbler showing which accounts moved from cold to engaged

2. Outbound RevOps: A Clay-led signal engine that identifies in-market accounts, enriches contacts, and routes them into personalised sequences

3. GTM Sync: Both motions running against the same target account list, warming accounts with ads before outbound reaches them, feeding one unified pipeline

For VC and PE portfolios, the model adapts. Rather than engaging each portco as a standalone client, AC works with the fund to define the reference architecture, pilot it at the first portco, then deploy it across the portfolio in a staggered rollout.

The underlying system is proven. AC has built and operated these systems across 30+ B2B brands, creating 8 figures+ of extra pipeline and booking 2,000+ sales meetings. The case studies above demonstrate the system working at different stages and in different verticals.

The portfolio model applies this same structure at scale. The fund gets a single partner (AC) deploying a proven system across multiple companies, rather than each company independently hiring agencies, consultants, or ops hires and hoping for the best.

It is not an agency retainer. It is a fixed-scope install.

Timeline: 120 Days per Portco, Staggered Across the Portfolio

The standard deployment timeline for a single portco is 120 days from kickoff to full system ownership.

Getting Started: What a Portfolio GTM Assessment Looks Like

The first step is not a sales pitch. It is a portfolio assessment.

AC reviews the fund's portfolio against the readiness criteria: which portcos qualify today, which are close, and which need to hit milestones first. The output is a prioritised deployment plan with a recommended sequence and timeline.

From there:

1. Pilot agreement: Select 1-2 portcos for the initial deployment. Build the full system, measure results, and refine the playbook.

2. Portfolio rollout: Deploy across the remaining qualified portcos on a staggered schedule.

3. Ongoing optimisation: Shared learnings across the portfolio. Signal definitions, sequence templates, and playbooks improve with each deployment.

The managing partner or operating partner is the primary contact. Portco founders and revenue leaders are involved during their company's deployment, but the fund-level relationship is what drives the portfolio-wide strategy.

To discuss a portfolio assessment, contact Tom Grainger directly at advancedclient.io.

Frequently Asked Questions

What size fund is this designed for?

This model works for funds with 5 or more B2B SaaS or B2B services companies in their portfolio. The portfolio-wide benefits (shared playbooks, consistent reporting, compounding learnings) increase with the number of portcos. Seed-stage funds, growth equity firms, and PE operating groups all fit the model, provided the portcos meet the readiness criteria: product-market fit, $10K+ ACV, and an existing sales team.

Do you replace the portco's existing sales tools?

No. AC builds inside whatever CRM and tooling the portco already uses. If they are on HubSpot, the system runs on HubSpot. If they are on Salesforce, it runs on Salesforce. The principle is infrastructure ownership: the portco keeps full control of their stack, their data, and their domains. Nothing is hosted on AC's platform.

What happens after the 120-day engagement ends?

The portco owns the system completely. All playbooks, sequences, signal definitions, CRM architecture, and dashboards live inside their tools with full documentation. Their team operates it independently. Optional post-engagement support is available for ongoing optimisation, but it is not required. Verifile is a direct example: they run their system independently after a full handover, booking FTSE 100 meetings without AC's involvement.

How do you handle portcos at different stages?

The readiness assessment sorts portcos into three categories: ready now, ready soon (need to hit specific milestones), and not yet. The deployment sequence starts with the most ready companies. This also means the pilot portcos generate learnings that improve the system before it reaches earlier-stage companies. A Series B portco with 10 AEs gets a different configuration than a Series A company with 2 AEs, but the underlying architecture is the same.

Can the fund see pipeline performance across the whole portfolio?

Yes. When every portco uses the same CRM architecture and reporting definitions, the fund gets a genuine portfolio-level view. Pipeline created, conversion rates, cost per qualified meeting, and attribution all use consistent definitions. This means the managing partner can compare GTM performance across companies without translating between different reporting frameworks.

What if a portco already has an outbound agency?

The system replaces agency-rented infrastructure with portco-owned infrastructure. Most outbound agencies operate on a retainer model where the agency owns the tools, the domains, and the data. When the retainer ends, the portco starts from zero. AC's model is the opposite: the system is built inside the portco's tools and transferred with full documentation. If the existing agency is producing results, AC can assess whether the system architecture is transferable or needs to be rebuilt.

How is this different from hiring an operating partner to oversee GTM?

An operating partner provides strategic guidance. They advise on hiring, review board decks, and connect portcos with their network. They do not build the system. AC builds and operates the actual infrastructure: the signal engine, the sequences, the CRM architecture, the dashboards, and the playbooks. The operating partner and AC are complementary. The operating partner sets the strategy. AC installs the system that executes it.

What is the minimum portfolio size for this to make sense?

The portfolio-wide approach starts delivering meaningful advantages at 3 portcos. Below that, the shared learnings and standardised reporting benefits are limited. The economics work at any number (even a single portco install at $30K-$50K is significantly cheaper than hiring), but the compounding effects of shared playbooks and cross-portfolio learnings accelerate at 5+ portcos.

How do you handle portcos in different verticals?

The architecture is the same across verticals. The customisation layer (ICP definitions, signal weighting, messaging angles, sequence tone) adapts to each company's market. AC's case studies span usage-based billing SaaS (m3ter), background screening (Verifile), architectural design (The Cosine), creative agencies (Studio X), and sales consulting (RAIN Group). The system works because the infrastructure is vertical-agnostic; only the targeting and messaging layer changes.

What if the portco's CRM is a mess?

Most are. The CRM architecture phase (Week 1-4) includes an audit and restructure of the existing CRM. Objects, fields, lifecycle stages, and ownership rules get cleaned up and documented. This is often one of the highest-value parts of the engagement, because it fixes a problem that has been compounding since the portco first started using the CRM without a plan.

Can this work for PE roll-ups where multiple acquired companies need unified GTM?

Yes. PE roll-ups face the same challenge as VC portfolios, with an added layer: the acquired companies often have conflicting GTM systems, different CRMs, and no shared reporting. The standardised install gives the platform company a unified GTM architecture across all acquisitions, which accelerates integration and makes portfolio-level performance visible.

How do you handle data privacy and security across multiple portcos?

Each portco's system is completely isolated. AC builds inside each company's own tools, on their own domains, using their own data. There is no shared database across portcos. No portco's data touches another portco's system. The fund gets aggregated reporting (pipeline numbers, conversion rates), not access to individual portco's contact databases or CRM records. This structure means data privacy is handled at the portco level using their existing security and compliance frameworks.