Sales Assist: Which Signal Is Worth a Human, and What That Human Does

A support ticket arrives from a free account asking whether single sign-on is available on a paid plan. The account has forty-one people signed up on the same email domain, eleven of them active weekly, and nobody at the company has ever spoken to anyone there. Support answers the question accurately in nine minutes and closes the ticket. That was the whole opportunity, and it was handled by somebody whose queue is measured in resolution time.

Sales assist is the function that exists to catch that ticket. It is the human layer a product-led company puts between a self-serve funnel and an enterprise sales team, and most of the difficulty in running one comes from the fact that it is defined by what sits on either side of it rather than by anything of its own.

The function, and why nobody agrees what to call it

The vendors publishing on this subject describe the same thing in almost the same words. Dock's guide says sales assist is "a blend between sales and customer success, usually put into place at PLG companies to remove friction from the purchase and adoption process", and adds that the role "is there to help people who are already using the product". Pocus describes the team as offering "a human touchpoint for users who are potentially good sales opportunities and need help solving their problem, getting value out of the product, or making a purchase decision". Reprise's version is that the role exists to "improve the user experience with the product, streamline the purchase process, and generally reduce friction and user pain".

What none of them agree on is the job title, and the disagreement is informative rather than cosmetic. Dock's page states that the phrase is "the term used to describe the function of the sales force at PLG businesses, rather than the job title for the role", that "Most people working in a sales-assist role have a different title", and that they might be called a "product specialist, account manager, or product advocate". Pocus draws the same distinction, writing that "Sales-Assist is the function, whereas the other names are the titles", and gives two examples from its own reporting, Vidyard's "Video Coach" team and Superhuman's "onboarding specialists". Reprise's page lists four more: "success coaches at HubSpot, onboarding specialists at Airtable, enterprise advocates (Atlassian), and user operations at Asana".

Six companies, six titles, and not one of them says sales. That is a deliberate design choice about how the first message reads to somebody who has not asked to be sold to, and it is the clearest signal available about what the function is for.

The boundary, which is the entire operating question

The role is defined by two edges, and Pocus's page draws them more precisely than anything else published on the subject. The questions sales assist handles are "typically more complex than typical support questions" and "less complex than enterprise sales questions", and where one arrives at the wrong edge the team routes it to support or to enterprise sales.

That is a workable definition and it has an awkward consequence. A function scoped by exclusion has no natural stopping point, so it absorbs whatever the two neighbouring teams find inconvenient. Pocus states the guardrail directly: the role "should not be to talk to every single user that comes through the self-serve funnel." A sales-assist team with no threshold becomes a second support queue staffed by more expensive people, and it will look busy the entire time.

SupportAnswers the question asked

• Triggered by the user raising a ticket
• Measured on resolution time and volume
• Optimised to close the conversation
• Cannot see account-level usage while answering
• Has no reason to ask who else is involved

Sales assistRemoves friction from a purchase already forming

• Triggered by a usage or intent signal, not only by a ticket
• Measured on pipeline influenced and friction removed
• Optimised to keep the conversation open
• Arrives knowing what the account already does with the product
• Asks who else is affected, because that is the expansion

Enterprise salesRuns a committee purchase

• Triggered by deal size or procurement
• Measured on closed revenue
• Optimised to reach a signature
• Handles security review, legal and multi-year terms
• Uneconomic below a deal-size floor

Which signal is worth a human

This is the design decision that everything else follows from, and it is a threshold problem rather than a scoring problem.

Our own definition page for product-led growth makes the point in the context of the product qualified lead, and it applies with more force here because a person's calendar is the resource being spent: a threshold set at signup rather than at a genuine outcome turns a sales team into a support queue. Sales assist is where that mistake becomes expensive, because the cost of a badly placed threshold is not a misreported metric, it is somebody spending their week on conversations that were never going to move.

Three signal classes behave differently and are worth separating before any of them is wired to a person.

A raised hand. Somebody asked about pricing, plans, invoicing, procurement or a paid-only feature. This is the highest-value trigger available and the cheapest to detect, because the user has already declared intent. Dock's page gives the archetype: a sales assist might jump in to support "a prospect who wants to purchase an enterprise license but needs to buy via purchase order rather than with a credit card". Nothing about that conversation is a sale. It is an obstacle being removed.

Account shape. Several people from one company, using the product independently, none of them talking to each other about it. This is the signal a support team cannot see, because a ticket arrives from a person and the opportunity belongs to an account. It is also the signal most likely to be worth a human, since the work of the conversation is introducing colleagues to each other.

Trajectory. Usage crossing a boundary that predicts a plan limit, or falling off after a strong start. The second is the one teams under-use and it is genuinely valuable, because a promising account going quiet is recoverable for about a fortnight and then is not.

What does not belong on the list is a raw activity score with no shape behind it. A user who has clicked a great deal has told you they are busy.

The first conversation, and the three ways it goes wrong

The opening move decides the rest, and the failure modes are consistent enough across the published accounts to name.

It arrives as a pitch. The user did not ask to be sold to, and the entire premise of the function is that they are already using the product. Pocus puts the intent plainly: the goal of sales assist "isn't to push a sale, but to pull forward revenue". A first message that opens with a demo offer converts a person who was going to upgrade in six weeks into a person who now associates the product with being chased.

It arrives too late to be about anything. The signal fires, it sits in a queue, and somebody reaches out eleven days later about an evaluation the user has already finished one way or the other. A slow sales-assist team is a reporting artefact.

It answers the question and stops. This is the subtle one and it is the failure the function was invented to prevent. Somebody asks whether SSO is on the paid plan, gets told yes, and the conversation ends without anyone establishing that eleven people at that company are already using the product and none of them knows about the others. The question a user asks is almost never the size of the opportunity behind it.

Before you put a person behind the signal

• ✓Yes: The trigger is written down, and somebody can say what does NOT qualify
• ✓Yes: There is a response-time commitment, and it is measured in hours
• ✓Yes: The handoff into enterprise sales has a named threshold, not a judgement call
• ✓Yes: The handoff back to support has one too, in the other direction
• ✓Yes: The role has a title the recipient will not read as a sales approach
• ~Depends: Somebody owns the feedback loop into product, with a place to put it
• ✕No: The team is compensated only on closed revenue it personally sourced
• ✕No: Every self-serve signup is contacted

Measuring it without breaking it

The compensation question is where the function most often gets quietly converted back into a sales team.

Pocus is explicit that measuring the team "can't just focus on closed/won revenue", and the reason is structural rather than cultural. A sales-assist conversation frequently ends with a user upgrading themselves through the same checkout they would have used anyway, or with an account routed to enterprise sales and closed by somebody else, or with a friction point being fixed in the product so that nobody has to have the conversation again. All three are the function working. None of them is attributable revenue in the way a quota expects.

The measurements that survive contact with that reality are pipeline and opportunities referred, response time against the commitment, and the conversion rate of accounts that received a touch against comparable accounts that did not. That last one needs a holdout to mean anything, and a holdout is unpopular precisely because it makes the answer checkable.

The wider design principle is the one our page on sales rep incentive programs sets out: an incentive moves behaviour inside the person's control that completes inside the window. Almost nothing a sales-assist person does satisfies both halves of that test, which is an argument for a smaller variable component here than an account executive carries, not for a larger one.

Where outbound sits beside it

Sales assist is a demand-capture function by construction. It works on accounts that already have people inside them using the product, which is a genuinely privileged position and a bounded one.

Two populations sit outside it permanently, and both are worth naming because a company that has staffed sales assist well tends to assume it has covered the ground.

The first is the segment that cannot arrive through a self-serve funnel at all, because nobody there can start alone. That is a targeting decision rather than a funnel problem, and the channel arithmetic by deal size is in outbound lead generation for B2B SaaS.

The second is the set of accounts where the product is already in use and the person who could buy it properly has never heard of it. Contacting a decision-maker there is outbound with an unusually strong premise, because something checkable about their own organisation is already true, and the qualification question it raises is the one worked through in what a qualified lead actually has to demonstrate.

Two boundaries from our own practice apply to that second motion and are worth stating, because the temptation to automate it is strong. We run one message per campaign, with no bumps and no thread replies, and a fresh campaign on a new premise rather than a reminder. And a meeting counts when it meets criteria agreed in writing before anything sends, which for this motion means deciding in advance whether a champion who already uses the product qualifies or whether the named budget holder is required. That conversation is much cheaper before the campaign than after it. The onboarding-side sibling of the same discipline is in the sales onboarding process, and the sequencing question of when a human should enter a technical evaluation at all is in proof of concept sales.

The short version

Sales assist is the human layer between a self-serve funnel and an enterprise sales team, staffed by people whose titles almost never say sales, and scoped by the two functions on either side of it. Define its trigger and both of its handoff thresholds in writing before hiring anybody, because a function defined by exclusion absorbs whatever its neighbours do not want.

Point it at raised hands first, account shape second and trajectory third, and keep it away from raw activity scores. Respond in hours. Treat the question a user asked as the smallest part of the opportunity behind it. Measure influenced pipeline and response time rather than personally closed revenue, and expect the best outcomes to be unattributable.

It captures demand that already exists inside accounts you are already in. The accounts that will never appear in a self-serve funnel are a separate motion, and we will build one campaign against that list so you can read the replies.

Definitions and role descriptions verified against Dock's sales-assist guide, Pocus's sales-assist role article and Reprise's sales-assist post, all fetched 23 August 2026. Publishers revise these pages; confirm the current text before relying on it.