> For the complete documentation index, see [llms.txt](https://docs.zero.inc/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.zero.inc/getting-started/key-concepts/records/deals.md). # Deals A deal is a revenue opportunity: something you are trying to close with a company. Every deal belongs to one **Pipeline** and sits in one of its **Stages**, and moving it between stages is what drives your boards, forecasts and reports. A deal belongs to at most one company and links to any number of contacts. ## Why deals are their own records Some CRMs run a sales pipeline as a status field on the company. Zero keeps deals separate, and we'd recommend you do too: * A company can have more than one deal. Renewals, expansions and a second product line each get their own record instead of overwriting the last one. * Real deal records leave a clean history, so conversion rates, sales cycles and revenue patterns still mean something once you scale — including when a board or an investor asks. * A deal carries its own owners, contacts, tasks and next steps, which is what makes a handoff between teams survivable. * Follow-ups, next-step suggestions and pipeline insights work on structured deals; there is nothing for them to reason about in a status field. ## Pipelines and stages * A workspace can have **several pipelines**, one per sales motion or customer journey, each with its own stages. A deal is in exactly one. * Stages are grouped under four statuses: **Lead**, **In progress**, **Won** and **Lost**. Closed deals end in a Won or Lost stage. * One stage is where new deals start. Deals move by dragging on a Board view or by editing the **Stage** property anywhere it appears. * A stage can **require certain properties**. Zero prompts for the missing ones when a deal moves in, and a deal that still lacks them shows an **Incomplete** badge. * With **Weighted deal values** on, each stage carries a **Weight** — how likely a deal there is to close — which turns **Deal value** into a **Weighted deal value** for forecasting. * **Time in current stage** and **Stage since** are tracked for you, so quiet deals are easy to find. Admins configure all of this in **Settings → Workspace → Pipelines**; see [Pipelines](/settings/pipeline-stages.md) for the full reference and advice on designing stages. A deal can also carry quotes built from your product catalog, which work out the contract value and can set the deal's value — see [Products & Quotes](/tracking-context/products-and-quotes.md). ## Keeping your pipeline healthy A pipeline is only as useful as it is honest. A few habits that keep it that way: * **Review it weekly.** Put the review in the calendar and be rigorous about resolving stalled deals and naming the priorities. * **Watch deal age.** Filter or highlight on **Time in current stage** to surface what has been sitting too long — **Add list highlight** in a view's **Options** menu colors the matching rows. * **Close what is dead.** Mark lost deals **Closed Lost** with a reason rather than leaving them open, and don't keep inactive deals around as reminders. Close the deal and schedule a task to revisit it. * **Keep open deals complete.** An owner under **Owners** and a **Next steps** task on every one; a lost reason on every closed-lost one. You will want those reasons later. * **Track next steps as CRM tasks**, not in a personal task manager, so they stay attached to the deal and visible to everyone. With a [notetaker](/settings/call-recorders.md) connected, tasks are created from the action items discussed in your calls. ## Adding deals * **Manually** — **Add deal** at the top of any deal list (and of **Deals**). On a Board view the button moves into the columns: **+** at the top of a stage column, or **Add row** at its foot, starts a deal in that stage. The confirm button is **Create deal**. * **Command menu** — **Add deal** (**Cmd + K**, then **D**). * **From a related record** — **Add deal** in the **⋯** menu of a company header, or **Add to deal** on a contact, which starts the deal with that company and contact filled in. * **Import** — CSV or a migration from another CRM. See [Data Import](/getting-started/data-import.md). * **Agents** — an agent action can create or update deals. See [Agents](/features/agents.md). * **Chat, MCP and the API** — `add_deal` for Chat and MCP clients, `POST /api/deals` for REST. See [MCP](/developers/mcp.md). ## Standard properties * **Name**, **Pipeline**, **Stage** (with **Stage → Type**, **Previous stage**, **Previous stages**, **Stage since**, **Time in current stage**) * **Deal value**, **Confidence** (probability in percent), and the derived **Weighted deal value** * **Close date**, **Start date**, **End date**, **Time to close** * **Company** — a deal belongs to one company * **Contacts** — the people involved * **Owners**, **Lists**, **Tasks**, **Next steps** * **Outcome reasoning** — Zero's explanation of why a deal was won or lost * **Created at**, **Created by**, **Updated at**, **Updated by**, **External ID**, **Archived** Anything beyond this is a [custom property](/settings/custom-properties.md). --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.zero.inc/getting-started/key-concepts/records/deals.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.