Persona-based outbound

A different argument for each person in the buying group

Adding a line about someone's recent post is not personalisation. Each role in a security purchase is responsible for something different, carries different risk, and needs a different reason to engage.

Cosmetic personalisation compared with persona-specific content

The same fictional product, an alert triage tool for security operations teams, described three ways.

Generic, with AI personalisation

Hi [first name], loved your recent post about the conference. I noticed [company] is growing fast. We help security teams work smarter with AI-powered automation. Would you be open to a quick 15-minute call next week?

The first line changes. The argument does not. It could be sent to a CISO, an analyst or a finance director.

For a CISO

Your team is triaging more alerts with fewer senior analysts than a year ago. For many security leaders this shows up first in retention, then in response times. The usual choice is between more headcount, extending the SIEM, or changing how triage is done. We can share how comparable teams made that decision and what they measured.

For a SOC team lead

If much of a shift goes on closing alerts that turn out to be nothing, the problem is not effort. The tool groups related alerts and shows the evidence behind each one, so analysts spend their time on the ones that matter. Would it help to see how it handles output from your current SIEM?

Illustrative messages for a fictional product. They are not client work.

Five personas, five different conversations

For each campaign we write down what each role is responsible for, the argument that matters to them, the evidence they will need, and what to leave out.

Founders and CEOs

Responsible for: The direction of the business, board reporting and how much risk the company carries.
The argument: Commercial risk, opportunity cost and strategic relevance. Why the problem matters to revenue, customers or the board, not only to the security team.
Evidence they need: Plain consequences, comparable organisations, and a clear sense of cost and effort.
Leave out: Technical detail they will pass straight to someone else.

Commercial leaders, directors and VPs

Responsible for: Team priorities, budget, process and delivery against targets.
The argument: How the change affects their team's workload, budget and process, and what implementation involves.
Evidence they need: Implementation effort, time to value, effect on existing process, and references from similar teams.
Leave out: Board-level abstraction with nothing practical underneath it.

CTOs, CISOs, Heads of Security and architects

Responsible for: Technical direction, security posture, architecture, and the risk of anything new entering the estate.
The argument: Technical fit, integration, credibility and operational impact.
Evidence they need: How it works, what it integrates with, how data is handled, and who runs it in a similar environment.
Leave out: Vague claims, inflated language and anything that will not survive a technical review.

Analysts and practitioners

Responsible for: The daily work: triage, investigation, engineering and administration.
The argument: Workflow pain, usability, tool fatigue and practical relief.
Evidence they need: A realistic view of the product in use, what it replaces, and the effort needed before it saves time.
Leave out: Treating them as the budget holder, or selling to them as if they own the decision.

Technical founders, early sales hires, early security leaders and MSSP partners

Responsible for: Building something from a small base, usually with limited time, budget and process.
The argument: Practical help that suits a small team: quicker evaluation, fewer tools, and a supplier that can grow with them. For MSSP partners, how the offer fits their service and their margin.
Evidence they need: Simple commercial terms, a contained way to test, and peers at a similar stage.
Leave out: Enterprise process and language they have no use for.

How the channels work together

Sequencing is planned around the persona and the trigger, not a fixed number of touches. Content supports a defined sales motion. It is not written to fill a calendar.

Email: Carries the main argument, written for one role at a time.
LinkedIn: Used for context and familiarity. Connection requests are not used to pitch.
Calls: Used where a conversation will move faster than writing, usually after some engagement.
Follow-up: Each touch adds something new: a relevant point, a piece of evidence or a question.
Adjustment: Campaigns are changed as responses come in, by persona and by message.

Responsible outreach

Every contact is checked for relevance to their role before they are included. Every message makes clear who is getting in touch and gives a simple way to opt out, and opt-outs take effect immediately.

Trust and compliance

Start with a pipeline review

A 45-minute call about your ICP, your current outbound and how opportunities are qualified. You should leave with a clearer view of where to focus, whether or not we work together.