What Should Your GTM Stack Have Before Your First SDR Starts?

What should your GTM stack have in place before your first SDR starts?

Five things: a CRM with clean account and contact records, a written ideal customer profile with a target account list, a reliable way to find and verify contact data, a sending setup that protects your domain, and simple reporting on activity and meetings. Without these, a new SDR spends their first months building systems instead of selling.

Founders usually hire the first SDR when the founder can no longer keep up with outbound. That is the right trigger. The mistake is assuming the new hire will arrive, open a laptop, and start booking meetings with whatever tools exist.

In practice, the first SDR inherits whatever the founder was doing by hand: a spreadsheet of prospects, a personal inbox, notes scattered across tools. A capable SDR can make that work for a while, but they will be slow, and their results will be hard to measure. A little GTM engineering before day one changes that.

Why does the stack matter so much for a first SDR?

Because the first SDR is also your first test of whether outbound can be repeated by someone other than the founder. If their results depend on systems that do not exist, you cannot tell whether a slow start is a people problem, a targeting problem, or a tooling problem. A basic stack removes the tooling variable.

Founders sell on credibility and context that no new hire has. The SDR does not know which accounts the founder has already talked to, which messages worked, or which industries never reply. A stack that captures that knowledge is how you transfer it.

If you are still deciding whether the first hire should be an SDR at all, my piece on whether a founder should hire an SDR or an AE first covers that decision. This article assumes you have decided on an SDR.

What does the CRM need before day one?

Accounts and contacts the founder has already touched, each with an owner and a last activity date, plus deal stages that match how you actually sell. The SDR needs to see who is already in conversation so they never cold email a warm prospect. HubSpot or any mainstream CRM works, as long as it is the single source of truth.

The most important step is getting the founder's history into the CRM. Export the founder's recent prospect conversations, match them to accounts, and log them. It is tedious work, and it prevents the most embarrassing first-month mistake: an SDR pitching a company the founder spoke to last week.

Keep the pipeline simple. A first SDR does not need a ten-stage pipeline with complex rules. They need a clear definition of what counts as a meeting booked and when a lead passes to the founder or an AE. Everything else can come later.

How clear does the ideal customer profile need to be?

Clear enough that the SDR could build a list without asking you. That means specific firmographics, the roles you sell to, and the problem you solve for them, written down in a page or less. Add a starting list of target accounts that fit, so the SDR begins with good accounts rather than guessing.

Founders often carry the ICP in their head. They know a good fit when they see one, but they cannot describe it precisely. The act of writing it down usually exposes vague spots, such as "mid-sized companies" with no defined size range, or "marketing leaders" with no defined title.

Include a short "not a fit" section too. Telling an SDR which accounts to skip saves as much time as telling them which to pursue. Industries that never buy, company sizes that churn, and roles that cannot sign all belong on that list.

How should contact data and enrichment work?

The SDR needs one approved way to find contacts and verify emails, tied back to the CRM. That might be Apollo, Clay, or another provider, but it should be one documented process, not a personal collection of browser extensions. Data should land in the CRM with a source noted, so you can judge its quality later.

The choice of tool matters less than having one process. I compared the two most common starting points in whether to start with Clay or Apollo at seed stage. Either can work for a first SDR. What does not work is three overlapping tools with no shared rules.

Set a credit or budget limit before the SDR starts, and agree how verification works. Bounced emails hurt your sending reputation. A first SDR who sends to unverified addresses can damage the domain that every future hire will depend on.

What sending setup protects your domain?

Separate outbound sending from your main company email, warm up the sending accounts before volume starts, set up email authentication, and keep daily volume per inbox modest. Your primary domain carries your customer email, invoices, and support. A first outbound hire should never be able to put that at risk.

Many teams use a secondary domain for cold outbound, with its own inboxes, for exactly this reason. Whatever approach you choose, make sure SPF, DKIM, and DMARC are set up correctly on every sending domain before the first campaign. These are standard email authentication records and every serious sending tool expects them.

Agree the sequence structure and approval process too. In the first weeks, I would have the founder review new messaging before it goes out. That is not micromanagement. It is how the SDR learns what the founder knows about tone and positioning.

What reporting does a first SDR need?

A simple weekly view of activity and outcomes: accounts worked, contacts reached, replies, meetings booked, and meetings held. Pull it from the CRM, not from a spreadsheet the SDR maintains by hand. The goal is a shared, honest picture of what is working, reviewed together each week.

Keep the metrics few. A first SDR measured on twenty numbers will optimize for whichever ones are easiest. Meetings held with ICP accounts is the number that matters most. Activity metrics are useful for coaching, not for judging.

The handoff between SDR and founder or AE also needs a defined format. What does the SDR record about a booked meeting? What does the next person need to know? I wrote a checklist for this in how to write a lead handoff checklist for SDRs and AEs. Have it ready on day one.

What can wait until after the first SDR starts?

Advanced lead scoring, complex routing, AI SDR tools, intent data, and detailed attribution can all wait. Those systems make sense once you have a repeatable motion and enough volume to tune them. Building them before your first SDR starts is optimizing a process that does not exist yet.

This is a common trap for technical founders. Building systems is fun, and it feels like progress. But a first SDR needs a working basic setup far more than an elegant advanced one. Get the five essentials right, then let real activity show you what to build next.

The exception is anything the founder already does manually and repeatedly. If the founder checks a list of website visitors every morning, or researches every account the same way, that routine is worth documenting or automating before the SDR inherits it.

What should you do next?

Before your first SDR starts, move the founder's prospect history into the CRM, write the ICP and a not-a-fit list, choose one contact data process, set up protected sending, and build a simple weekly report. Then plan the first two weeks of onboarding around those systems, with the founder reviewing messaging.

A first SDR is a big investment for an early company. The stack around them decides how quickly that investment pays back, and whether you can tell if it is working at all.

If you want help setting up the GTM stack before your first sales hire, or reviewing what you have, let's chat. Building these systems is the core of the GTM engineering work I do.