Skip to main content

Intro

The sales knowledge system separates reusable source records from the call sheets generated from them. Start with the persona list, market catalog, and market verticals catalog, then use the sales how-to instructions to define vertical profiles, ICPs, market-persona bindings, problems, solutions, proof, and Q&A.

Persona definitions
  -> Markets
    -> Market verticals
      -> ICPs
      -> Market-persona bindings
      -> Problems
      -> Solutions
      -> Proof
      -> Q&A
        -> Generated call sheets

How to use this section​

Use the global persona list as reusable vocabulary for business functions. Each vertical must explicitly select its relevant personas and bind them to market-specific jobs, problems, solutions, proof, and questions. A persona's title alone does not establish authority, motivation, problem ownership, or transaction role.

Use the market catalog to select the top-level go-to-market motion and route an account to the smallest reusable vertical whose operating physics fit. Market membership and NAICS classification establish scope; they do not prove that an account has a problem or that proof transfers from another vertical.

Use generated call sheets for execution, not as source material. An account or contact may specialize a call sheet with verified facts, but it cannot create a market problem, persona responsibility, product capability, or proof claim.

Authoring rules​

  • Treat fenced YAML records as authoritative when prose and structured data disagree.
  • Give every record an immutable ID, kind, and schema_version.
  • Store each fact in one owning record and refer to it by ID elsewhere.
  • Label hypotheses and render them as questions.
  • Attach evidence to external and customer-derived claims.
  • Use null for unknown values and an empty list only when the field has been reviewed and none were found.
  • Retire or deprecate a published record instead of reusing its ID.

Current documents​