Zendesk Sell - is it a CRM? | HowToUseACRM.com

Every verdict, with its evidence

Core objects

Not at all

Zendesk Sell holds Deal, Contact and Task as separate records, and the associations between them are complete - a deal carries `contact_id`, documented as the primary contact, plus a read-only `organization_id`, and a task carries `resource_type` with possible values lead, contact and deal. The person and the organization are not separate objects. Both are a Contact, told apart by an `is_organization` boolean that "can be set only during creation and cannot be changed later", and both are served by the same /v2/contacts endpoint family, with `contact_id` on a person pointing at the organization Contact and `parent_organization_id` pointing at a parent organization. The customization layer confirms the single object: custom fields are created "separately for leads, contacts, prospects and customers, and deals", with one contacts field carrying "Show on person cards" and "Show on company cards" checkboxes, and the product limits page counts a 500 custom-field ceiling per object type across leads, contacts and deals. Separate person and company cards in the interface do not make two types of one object into two objects.

Source: https://developer.zendesk.com/api-reference/sales-crm/resources/contacts/, https://developer.zendesk.com/api-reference/sales-crm/resources/deals/, https://developer.zendesk.com/api-reference/sales-crm/resources/tasks/, https://support.zendesk.com/hc/en-us/articles/4408838289562-Creating-and-managing-Sell-custom-fields, https://support.zendesk.com/hc/en-us/articles/4408827866266-Product-limits-for-Sell

Verification: Verified

Pipeline stages

In full

A deal carries `stage_id` and `last_stage_change_at`, and the Stage object carries `position`, described as "The stage's position in the pipeline", along with `name`, `category`, `likelihood` and `pipeline_id`. The default set is the active stages Incoming, Qualified, Quote and Closure plus the closed stages Won, Unqualified and Lost, and the account can add its own stages and edit the defaults, up to fifty stages in a single pipeline. Order is therefore held on the stage record rather than on a view.

Source: https://developer.zendesk.com/api-reference/sales-crm/resources/stages/, https://developer.zendesk.com/api-reference/sales-crm/resources/deals/, https://support.zendesk.com/hc/en-us/articles/4408820185882-About-sales-pipeline-stages, https://support.zendesk.com/hc/en-us/articles/4408827866266-Product-limits-for-Sell

Verification: Verified

Status

Not at all

The Deal object enumeration lists `stage_id`, `last_stage_change_at`, `value`, `currency`, `owner_id`, `contact_id`, `estimated_close_date`, `loss_reason_id`, `unqualified_reason_id`, `hot`, `tags` and `custom_fields`, and carries no open-or-settled attribute of its own. Whether a deal is settled is a property of the stage it occupies: the Stage object carries `category`, documented with the values incoming, in_progress, won, lost and unqualified, and `active`, described as an "Indicator whether or not the stage contains finalized deals". The vendor's own stage article splits the defaults into active stages and "closed stages Won, Unqualified, and Lost". Sell's smart lists do offer a Status column, but the vendor defines it as a field that "Indicates what stage the deal is at in the sales pipeline", which is the stage again rather than a second value. Ruled 30 Aug 2026: status and stage must be completely separate values, so an outcome that is a property of the stage is not a status attribute at all.

Source: https://developer.zendesk.com/api-reference/sales-crm/resources/deals/, https://developer.zendesk.com/api-reference/sales-crm/resources/stages/, https://support.zendesk.com/hc/en-us/articles/4408820185882-About-sales-pipeline-stages, https://support.zendesk.com/hc/en-us/articles/4491025590554-Sales-smart-list-fields-reference

Verification: Verified

Resolution

In part

Won and lost are stage categories rather than attributes of the deal. The Stage object's `category` takes the documented values incoming, in_progress, won, lost and unqualified, and the default pipeline ships Won, Lost and Unqualified as terminal stages. The outcome is therefore readable, but only from the stage's own metadata: the deal itself carries `stage_id` and nothing that names the result. The deal does carry `loss_reason_id` and `unqualified_reason_id`, which the vendor describes as the reason a deal was lost or unqualified rather than as the record of the outcome.

Verification: Verified

Value

In full

The Deal object ships `value`, the amount of the deal, alongside `currency`, documented as "Currency of the deal, specified in 3-character currency code (ISO4217) format". Value is also exposed as a smart list field, and where products are attached the vendor sets the deal value from the product total by default.

Source: https://developer.zendesk.com/api-reference/sales-crm/resources/deals/, https://support.zendesk.com/hc/en-us/articles/4491025590554-Sales-smart-list-fields-reference, https://support.zendesk.com/hc/en-us/articles/4408832174746-Using-the-Product-Catalog-to-define-products-and-services-in-Sell

Verification: Verified

Scope of work

In full

Sell ships a Product Catalog, and products from it attach to a deal as line items. The vendor documents selecting products on an existing deal and then, in the add-products dialog, adding "a discount, change the price or currency for the product, and the quantity", with a Products column showing "the products associated with each deal, the total value of the products (converted to the deal's currency), and any discounts you've applied". A "Set products value as deal value" checkbox is selected by default. The API exposes the same structure as Orders and Line Items, where a line item copies name, description, sku and price from the product and carries quantity and a markup or discount `variation`. The catalog is documented as available on Sell Growth plans and above, and Orders and Line Items on Enterprise; a plan tier does not make the capability non-native.

Source: https://support.zendesk.com/hc/en-us/articles/4408832174746-Using-the-Product-Catalog-to-define-products-and-services-in-Sell, https://developer.zendesk.com/api-reference/sales-crm/resources/line-items/

Verification: Verified

Expected close date

In full

The Deal object ships `estimated_close_date`, the date the deal is expected to close, and it appears in smart lists as Estimated Close Date, listed separately from Close Date. The Forecasted Sales report and the Forecast widget are built on deals with a win likelihood and a close date.

Verification: Verified

Actual close date

In full

Sell ships Close date as a standard calculated field, defined by the vendor as the "Date when a deal is moved to one of the closed stages", so the platform records it rather than the buyer entering it. It is available as a smart list field, listed as Close Date and described as "(Deal property) The date when a deal is moved to one of the closed stages", separately from Estimated Close Date. The field does not appear in the Deal object attribute list in the API reference, which enumerates `estimated_close_date` but no closed date.

Source: https://support.zendesk.com/hc/en-us/articles/4408846436378-Sell-standard-calculated-fields, https://support.zendesk.com/hc/en-us/articles/4491025590554-Sales-smart-list-fields-reference, https://developer.zendesk.com/api-reference/sales-crm/resources/deals/

Verification: Verified

Opportunity owner

In full

The Deal object ships `owner_id`, documented as "Unique identifier of the user that the deal is assigned to", held separately from the read-only `creator_id`. Ownership is exposed in smart lists as Ownership, and reassigning ownership is a distinct permission in the role model.

Verification: Verified

Linked buyer

In full

The Deal object ships `contact_id`, documented as "Unique identifier of a primary contact", alongside a read-only `organization_id`. The link therefore reaches a named person rather than only a company, and Contact is the object a person is held in.

Source: https://developer.zendesk.com/api-reference/sales-crm/resources/deals/, https://developer.zendesk.com/api-reference/sales-crm/resources/contacts/

Verification: Verified

Record preservation

In full

Closing a deal moves it to a closed stage rather than removing it, and the closed record stays measurable. The vendor's reporting set includes Total Sales, Sales by Customer and Deal Loss Reasons on all plans, Sales by Owner and Forecasted Sales on higher plans, and Stage Duration Analysis and the loss reason breakdowns on Enterprise, all of which read settled deals. The Funnel report summarizes, per stage, which deals "stayed stationary and did not progress in the pipeline, those that progressed, and how many were unqualified or lost", and the Pipeline Coverage widget is computed from the team's historical win rates, which requires closed deals to persist.

Source: https://support.zendesk.com/hc/en-us/articles/4408846341914-About-reporting-in-Sell, https://support.zendesk.com/hc/en-us/articles/4408834230042-Understanding-the-Sell-Funnel-report, https://support.zendesk.com/hc/en-us/articles/4408842871962-Pipeline-Coverage-widget-Performance-Dashboard

Verification: Verified

Structured lost reasons

In full

The Deal object carries `loss_reason_id`, "Reason why the deal was lost", and a separate `unqualified_reason_id`. Loss Reasons are their own resource with an account-defined `name`, which agents can "create, delete and update", so the field is a controlled list rather than free text. The reasons are reportable: Deal Loss Reasons is a standard report on all Sell plans, and Loss Reasons by Owner and Loss Reasons by Source are Advanced Sales Insights reports on Enterprise. Loss Reason is also a smart list field.

Source: https://developer.zendesk.com/api-reference/sales-crm/resources/loss-reasons/, https://developer.zendesk.com/api-reference/sales-crm/resources/deals/, https://support.zendesk.com/hc/en-us/articles/4408846341914-About-reporting-in-Sell, https://support.zendesk.com/hc/en-us/articles/4491025590554-Sales-smart-list-fields-reference

Verification: Verified

Email sync

In full

A mailbox is connected to Sell directly - Microsoft 365 through OAuth 2.0, Gmail through Google sign-in, and Exchange or a custom domain through SMTP and IMAP credentials - and once connected "email messages in your external email server are mirrored into Sell and paired with your leads and contacts", appearing on the matching lead, contact and company cards. Users compose and send from a lead, contact or deal inside Sell. The sync runs on the inbox and outbox folders and not on subfolders, the initial sync retrieves up to 1,500 messages, and deleting a message on the external server removes it from Sell while deleting it in Sell does not touch the server.

Source: https://support.zendesk.com/hc/en-us/articles/4408838786586-About-using-email-in-Sell, https://support.zendesk.com/hc/en-us/articles/4408821242266-Connecting-your-email-with-Zendesk-Sell

Verification: Verified

Calendar sync

In full

Sell appointments and Google Calendar sync in both directions on the appointment itself: "The appointments that you add or edit in either calendar (Sell or Google), are synced", and "If you delete an appointment in the Sell calendar, it is also deleted in the Google calendar, and vice versa." Sell tasks have their own separate Google connection, documented apart from the appointment sync.

Source: https://support.zendesk.com/hc/en-us/articles/4408843420314-Connecting-your-Google-calendar-with-Sell

Verification: Verified

Schedulable activity types

In part

Tasks are scheduled inside Sell and the Task object carries `owner_id`, `due_date`, `remind_at`, `content`, `completed`, `completed_at`, `overdue` and a `resource_type` of lead, contact or deal - but no type attribute, and no type taxonomy is documented beyond the floating-versus-related distinction. The kinds of work Sell recognizes are fixed by the vendor and shipped as separate constructs: appointments, which sync to the calendar, plus calls, emails, texts, notes and visits, which is the set the Activity Overview report is built on. The fixed set covers meeting, call and task, so the buyer's own categories have nowhere to go.

Source: https://developer.zendesk.com/api-reference/sales-crm/resources/tasks/, https://support.zendesk.com/hc/en-us/articles/4408846341914-About-reporting-in-Sell, https://support.zendesk.com/hc/en-us/articles/4408843420314-Connecting-your-Google-calendar-with-Sell

Verification: Verified

Opportunity reporting

In full

All three reports are native. Stage conversion is the Stage Conversion by Owner report, which "summarizes how the team and individual team members are converting deals throughout the different stages of the sales pipeline", with the team average shown as "the overall average conversion rate for each stage"; the Rep Performance Dashboard carries pipeline conversion rates too. Win rate is reported as such - Deal Source Performance is documented as win rates by deal source, and the Pipeline Coverage widget derives its coverage ratio as "1 / Historical Win Rates of your team". Forecast is the Forecasted Sales report, which compares forecast against actual sales, together with the Forecast widget built on deals with a win likelihood and a close date. The conversion and win rate reports sit in Advanced Sales Insights on the Enterprise plan and the forecast reports on Growth and above; a plan tier does not make a native report non-native. The Funnel report on its own is a distribution - counts and values by stage - and does not carry the verdict.

Source: https://support.zendesk.com/hc/en-us/articles/4408846341914-About-reporting-in-Sell, https://support.zendesk.com/hc/en-us/articles/4408836226074-Stage-Conversion-by-Owner-report, https://support.zendesk.com/hc/en-us/articles/4408842871962-Pipeline-Coverage-widget-Performance-Dashboard, https://support.zendesk.com/hc/en-us/articles/4408834230042-Understanding-the-Sell-Funnel-report

Verification: Verified