Ideal customer profile for midsize and enterprise buyers
Who we target across all products, how to spot them, and what they must see before they buy. Every demand-gen and sales play assumes this buyer.
Summary
- Target: midsize and larger organizations that buy through a committee, run a security review and route the deal through procurement.
- Not the target (for paid spend): students, hobbyists, solo freelancers and job seekers. They are welcome on free and community tiers, but we don’t bid for them or build offers around them.
- What wins them: proof that we’re safe, supported, scalable and easy to buy. Feature lists alone don’t win midsize+ deals.
Details
Firmographic signals
| Signal | What to look for |
|---|---|
| Size | Hundreds of employees or more, multiple teams or business units |
| Structure | Dedicated IT/security function, formal procurement, legal review of terms |
| Tech | An existing stack we plug into (.NET, JavaScript frameworks, cloud provider, SSO identity provider, CRM, data warehouse) |
| Regulation | Finance, healthcare, insurance, government, manufacturing and other regulated or audited industries |
| Deployment needs | Asks about on-premises, private cloud, data residency or air-gapped installs |
| Buying behavior | Visits the security, pricing and contact-sales pages; downloads procurement documents; asks for a trial extension for a pilot |
Intent signals worth acting on
- Several people from the same company domain sign up or attend a webinar.
- Searches or ads clicks on “enterprise”, “on-premise”, “SSO”, “SOC 2”, “migration”, “alternative to”, “embedded”.
- Contact-sales or demo requests that mention security questionnaires, RFPs or a pilot.
- Existing community or small-tier customers whose usage or headcount crosses into a higher tier (see pricing and licensing).
What these buyers need to see
Each product site should answer these on a findable page. The website buyer-fit audit checks them.
| Need | Proof that satisfies it |
|---|---|
| Security | A security/trust page: encryption, hosting, access controls, vulnerability management, pen-test policy |
| Compliance | Certifications and attestations we actually hold, with how to request reports (TODO: verify per product) |
| SSO and identity | SAML/OIDC SSO, SCIM or user provisioning, role-based access |
| Deployment options | Cloud, on-premises, private cloud or embedded, with clear architecture notes |
| SLAs and uptime | A published SLA or uptime commitment for cloud products, and a status page |
| Support | Support tiers, response times, named contacts or premium support where offered |
| References | Case studies by industry and company size, customer logos (only with approval) |
| Procurement docs | Standard terms, DPA, security questionnaire answers, W-9 or vendor forms, invoicing and PO options |
| Price predictability | A clear pricing model and a clear path to an enterprise or custom quote |
| Vendor viability | Company history, scale and roadmap signals |
TODO: add a real example of a midsize+ deal that was won on proof rather than on features.
Disqualifiers and redirects
- No budget owner and no plan to deploy in the next two quarters: nurture, don’t chase.
- Individual developer evaluating for a personal project: point to the free or community option.
- Reseller or partner enquiry: route to the partner team.
Sources
- Internal GTM direction from leadership, recorded in
tasks/initial-gtm-build.md(target buyer: midsize and larger organizations). - Product security, pricing and deployment facts live in the positioning files under
_reference/positioning/and in pricing and licensing.
Used by
- Personas
- Google Ads strategy
- Website buyer-fit audit
- Competitive selling
- Every
products/<slug>/gtm-plan.md