# Sales 101: KISS system memory

| | |
|---|---|
| **Audience** | An LLM or a new engineer who needs the sales domain's shared vocabulary and the shape of the funnel |
| **Human page** | `/playbooks/sales-101` |
| **Role** | **The sales hub.** It is the ONLY sales card in the playbooks library; `working-with-leads` and `working-with-quotes` are reached through it, as cards in its §The playbooks, not from the library index. It defines terms and maps the funnel, and deliberately holds **no** process detail: each stage's mechanics live in its own page. |
| **Last reviewed** | 2026-08-26 |
| **Related** | `/playbooks/working-with-leads`, `/playbooks/working-with-quotes` |

---

## 1. What KISS sells

NFC door locks plus the software that runs them, sold B2B to **self-storage operators**. The base platform is free; revenue is hardware plus optional paid software features. Operators buy **facility by facility**, so expansion into an existing account is a distinct and significant motion, not an edge case.

Deal sizing is roughly **one lock per unit**, so "how many units" is the first sizing question and "which PMS do you run" is the first qualifying question.

## 2. The funnel

| # | Object | Exists when | Playbook |
|---|---|---|---|
| 1 | **Lead** (`0-136`) | Someone decides to work a contact | `working-with-leads` |
| 2 | **Deal** (`0-3`) | A meeting is booked | (this page, §4) |
| 3 | **Quote** (`2-60738190`) | A rep generates one from the deal | `working-with-quotes` |
| 4 | **Order** | The customer signs | (not yet written) |
| 5 | **Onboarding** | Kickoff call onward | (not yet written) |

The lead-to-deal boundary is the only one a rep controls by hand, and it has a single trigger: a meeting is booked, and the deal is created **from the lead record**. See `working-with-leads` §3.

## 3. Glossary

**People and accounts**

- **Contact** (`0-1`): a person. ~16.9k exist. Carries no status by itself.
- **Company** (`0-2`): the storage operator, and the account. ~11k exist, **79 with `locks_purchased > 0`** (that field is a calculated rollup from closed-won deals and is the authoritative "already a customer" signal).
- **Lead**: one attempt to start a conversation with one contact. A work item, not a person, not a status.
- **Deal**: a forecastable opportunity with a value. **One deal ends in exactly one signed quote** (several quotes may be sent while negotiating; only one is signed). See §5.
- **New vs existing business** (Deal Type): stamped at deal creation by a HubSpot workflow from the primary company's lifecycle stage. Customer = existing; anything else, Former Customer included, = new. Reps do not choose it. F21 flags a mismatch at signing (AE/AM credit). Detail: `docs/hubspot.md` § Deal properties.
- **Owner** (`hubspot_owner_id`): the single responsible person. Every record has exactly one.
- **Signer**: an association label on a contact that determines who receives the quote for signature. Falls back to Primary contact, then the first associated contact.
- **Tenant**: the operator's customer, renting a unit, opening the lock with their phone.
- **Guest**: someone a tenant shares access with. ⚠️ `guest` is the locked customer-facing term; `accessor` is retired. See `App\Enums\Access\GrantRole` in kiss-api before coining anything adjacent.

**Money and paperwork**

- **Quote**: the signable offer, generated from a deal by S1. Identified by a **ULID**.
- **Order**: what exists post-signature. Fulfillment and invoicing hang off the order, not the quote. **One quote can produce several orders.**
- **Tranche**: the split when one quote becomes several orders shipping and billing at different times. **The key is `payment_due_date`**: each distinct payment date on the hardware lines books its own order (blank = due on signing). A **deposit is never a tranche**, since a deposit plus a balance is two payment dates for one shipment. Verified against the published F21 workflow 2026-08-27.
- **Deposit**: `deposit_percent` populated on the deal = deposit flow; blank = full amount due on signing. Stored as a **fraction** (25% = `0.25`), valid 20 to 99%.
- **Invoice**: raised against an order, generally at fulfillment rather than at signing (two-track accounting; see `revenue-accounting`).

**Product**

- **Hardware**: SKU prefix **`1xx`**. One-time, invoiced via QuickBooks.
- **Premium Features**: SKU prefix **`2xx`**. Recurring, billed via Stripe subscription. This is the locked customer-facing name. Freemium, so a quote with no `2xx` lines is normal and skips the Features step entirely.
- **Demo lock**: a physical lock shipped to a prospect. Types: `Disc`, `Cylinder`, `Latch`. 237 contacts have received one.
- **PMS**: the operator's property management software (`facility_management_software` on the company). Integration target, and an early qualifier.
- **Facility / Unit**: one site, and one storage space within it. Operators buy per facility.
- **Go-live**: the date a facility starts using the locks in production. Onboarding schedules backwards from it.

## 4. Deal pipeline

Pipeline **`930425200`**, label "Deal Pipeline". Stages set 2026-10-01; ids read from `/crm/v3/pipelines/0-3`.
Every stage is entered on an **observable event**, never on a judgement of how promising a deal feels.

| # | Stage | `dealstage` | Won | Probability | Entered when |
|---|---|---|---|---|---|
| 0 | Evaluation | `1428879448` | no | 10% | A meeting is booked or held with someone who could buy, and the deal was created from the lead. No quote sent. No meeting means it is still a lead. |
| 1 | Proposal Sent | `1428879450` | no | 30% | A billing quote has been sent. Stays here while the customer has not replied. |
| 2 | Negotiation | `1428879449` | no | 50% | The customer has responded to the quote: a change, revision, pricing or terms. |
| 3 | **Signed - Unpaid** | **`1444057732`** | **yes** | 100% | The quote is signed. Set by **F21** at signature. Stays on the rep's board until collected; the rep helps collect and is not paid commission until paid in full. |
| 4 | **Closed Won** | **`1428879453`** | **yes** | 100% | Paid in full. Set by **F22** when every order under the deal is paid. Never set by hand. |
| 5 | Closed Lost | `1428879454` | no | 0% | The customer declined or went silent. A reason is required. |

⚠️ **Two won stages, both `hs_is_closed_won: true`**, so that flag cannot tell signed from paid. Use the stage id.
There is deliberately **no Contracting stage** (signing the billing quote is the contract) and **no onboarding stage**
(onboarding lives on the ticket F21 creates).

**The old `default` "Sales Pipeline" is being retired** (decided 2026-10-01). Reps move a deal across when they next
engage it: Evaluation→Evaluation, Negotiation→Negotiation, Mutual Close Plan→Negotiation, quoted→Proposal Sent;
Discovery/New Opportunity with no meeting go back to leads. Its won stages are `closedwon` (Payment Pending) and
`1230240069` (Paid), followed by the Kickoff/Onboarding stages, which are history only. **F21 and F22 handle both
pipelines**, so a deal signed or paid in either still advances correctly. Anything writing `dealstage` in the old
pipeline must still never move a deal backwards out of its onboarding stages.

## 5. One deal, one signed quote (decided 2026-10-08)

**1 deal → 1 signed quote → 1 ship-to → 1 payment method.** Several billing quotes per deal are fine while it is open
(options, negotiation); once one is signed the deal is done.

- **A reorder is a new deal.** Never generate a second quote on a won deal, and never edit a signed deal's line
  items to build the next quote: S1 builds the quote from whatever lines are on the deal at that moment, so the edit
  silently rewrites the record of the first order.
- **Multi-facility purchases split only when something differs.** One ship-to address and one payer: one deal (use
  tranches for staggered shipments). Different addresses or different payment methods: one deal per facility,
  because a signed quote carries exactly one of each (`quote_signatures`).
- Deliberately simple. If multi-location deals become common enough that this is cumbersome, revisit then.

Downstream, per signed quote: Hive `quotes` row → one or more orders (`invoice_lifecycle`, one per tranche), each with
its inFlow SO, EasyShip shipment, HubSpot Order, onboarding ticket and QBO postings. The company maps 1:1 to its QBO,
inFlow and Stripe customer across all its deals.

**Why:** 2026-10-07, a rep generated a second quote on the already-won "Don Tyree Reorder" deal by editing its line
items in place. F21 regressed the deal to Signed - Unpaid, the deal amount matched neither order, and an older
pending quote stayed signable. Cleaned up by splitting the second order onto its own deal.

## 6. Structure: hub and children

**Sales is a hub, not a row of peers.** The playbooks library index carries one sales card, Sales 101. The child pages still exist at their own URLs and keep their own `.md` companions, but they are surfaced as cards **inside** this page rather than in the library. Adding a sales playbook therefore means adding a card to `sales-101.html` §The playbooks, **not** a card to `index.html`.

This file is a **glossary and a map**. When a term needs more than two sentences, the detail belongs in a child page and this one links to it. Specifically:

- Lead definition, stages, disqualification vocabulary → `working-with-leads`
- Quote generation, editing, voiding, the customer's experience → `working-with-quotes`
- Revenue recognition, deposits, the two-track accounting → `revenue-accounting`
- Portal-side property internals → `docs/hubspot.md` in `kiss-hive`

Do not restate those here. A duplicated definition is a definition that will drift.

## When this file is wrong, fix these

- **The playbook it points at.** If a definition here contradicts `working-with-leads` or `working-with-quotes`, the dedicated playbook wins and this page is the one to correct.
- **HubSpot portal `49584170`**: the `default` deal pipeline for §4. Stage ids and labels are read from `/crm/v3/pipelines/0-3`.
- **`kiss-hive` `docs/hubspot.md`**: property-level truth, including the tranche key in §6.
- **`kiss-api` `app/Enums/`**: before adding any access or identity term to the glossary, take the canonical case names from the enum rather than coining a synonym.
- **F21 (`TR2lWvjE4SwEDnnV`) in n8n**: the booking workflow. Read the PUBLISHED version, not the editor draft, when checking booking behaviour.