Core concepts

In development Last updated

The vocabulary of Skip the Sell in one page — sellers, buyers, agents, offers, rules, configuration versions, deals, quotes, gates, contracts and done-conditions.

In development. The vocabulary below covers the whole product. The whole deal journey is live today: discovery, deals, quotes, versioning, gates, approvals, the NDA ceremony and built-in e-signature, orders and contracts, payments through the seller's Stripe, the provisioning callback, usage events, escalations, version-honoring decisions, the deal event log, webhooks, API keys, tenant settings and the audit feed (the OpenAPI document is the live registry). Later sections below still describe decided-but-unshipped ground where they say so.

Skip the Sell is self-serve enterprise checkout. A seller configures what may be bought, at what price, under which terms. A buyer — or the buyer's agent — configures a deal, sees deterministic pricing, passes the seller's gates, signs, pays through the seller's Stripe, and gets provisioned. No sales team in the loop, unless someone wants one.

We are our own first customer ("tenant zero"): we sell this product through the same system our sellers use, so if buying from us is awkward, the product is awkward.

The parties#

  • Seller — the vendor selling through us. A seller is a tenant: an isolated account holding all of its data.
  • Seller user — a human member of a seller's account, with permissions from the scopes their roles grant.
  • Seller agent — software acting for a seller through scoped API credentials. Configuring offers and rules is expected to be agent-driven.
  • Buyer — the organization purchasing from a seller.
  • Buyer user — a human at the buyer working on a deal. On that deal they hold one or more roles: requester, approver, signer, billing contact. In a small deal one person may hold all of them.
  • Buyer agent — software acting for a buyer user, usually through a deal URL. It reasons on the buyer's own compute; we run no inference.
  • Operator — us, running the hosted platform; also the human support of last resort when a seller has bought escalation support from us.

What a seller sells#

  • Catalog — everything a seller offers: products, price components, add-ons, terms and clauses.
  • Product — a thing the seller sells: a SaaS plan, a support tier, a professional-services package.
  • Price component — one atom of pricing: flat recurring (say $1,000/mo), per-unit (seats), usage-metered, per-event (say $5 per successful deal), one-time, or a tiered variant. A price is a combination of components.
  • Offer — a purchasable arrangement of products, price components, terms and rules that a buyer can configure.
  • Variable — a named input to an offer that the buyer or seller chooses: seats, term length, hosting model, currency, logo rights granted, and so on.
  • Term — a commercial parameter of the contract: length, billing frequency, payment terms, renewal, SLA.
  • Currency — USD, CAD, EUR and GBP.

Rules#

  • Rule — a seller-defined entry in a rules document: a phase, an optional condition over variables, and typed effects. Rules constrain choices, compute prices and discounts, require gates, or make some terms depend on others.
  • Effect — a typed outcome a rule declares: line, discount, surcharge, require, gate, clause, document, supersede, chain, schedule. Effects are data; the engine sequences them — never the other way around.
  • Give-get — a rule that ties a concession to a commitment, for example a discount that applies only if the buyer grants the seller the right to use their logo.

See the pricing rules primer for how sellers build with these.

Configuration and versions#

  • Configuration — a seller's complete setup: catalog, offers, rules, templates, gates, integrations and policies.
  • Draft — an unpublished set of configuration changes, simulatable before publishing.
  • Configuration version — an immutable, published snapshot of a configuration. Every change creates a new version; a rollback creates a new version with the old content. Versions can be diffed, rolled back to, and simulated against.
  • Simulation — a hypothetical deal run against a draft or a version, with no side effects, to see the resulting quote, gates and documents.

Every deal is pinned to the configuration version it started on, so a buyer is never surprised by mid-deal changes. See how a deal works.

Deals#

  • Deal — one buyer's purchase in progress with one seller, pinned to one configuration version.
  • Deal URL / deal token — a private, expiring, revocable link that grants access to one deal, usable by humans and buyer agents alike. A token is a delegation from the buyer user who minted it: it never exceeds that person's roles on the deal. A deal may hold several live tokens, revoked independently.
  • Quote — a deterministic, priced snapshot of a deal's current variable choices. The same inputs always produce the same quote.
  • Gate — a step that must be satisfied before the deal moves forward: an NDA signed, an approval granted, a payment method verified, a human signature for larger deals.
  • Gate policy — seller configuration on a gate saying whether a human must satisfy it: always, never, or above <amount>/yr.
  • Approval chain — the ordered buyer-side roles that must approve. In a small deal, one person may hold every role.
  • Escalation — handing a deal, or one question within it, to a human. Available at any point.
  • Order — an accepted quote: what the buyer is committing to buy.
  • Contract — the signed set of documents for an order (MSA, order form, DPA). Always retrievable by both parties for as long as the account exists.
  • Template — a seller's document template, with placeholders filled from the deal. A clause is a section of a template; it may carry pre-approved alternatives the buyer can pick without escalating. A redline — a change that isn't pre-approved — always goes to a human.
  • E-signature — our lightweight built-in signing, or the seller's own provider.
  • Done-condition — what "closed" means for a seller: any combination of signed, paid and provisioned.
  • Provisioning — the seller setting up the buyer's account in the seller's own product, triggered by our webhook and confirmed through the API.

Where next#