When You Can't Answer a Product Question on a Sales Call

Don't guess at a product answer to keep a sales call moving. Say which part you know, which part needs checking, and what you will do about the gap. A precise question with a reliable next step is more useful than a confident answer the buyer can't safely use.

That doesn't mean replying “I'll get back to you” to everything difficult. A rep can often explain the documented part, clarify the buyer's workflow and find out whether the missing detail changes the buying decision. The skill is keeping those things separate.

This guide uses fictional exchanges about an unnamed product. They are examples of handling uncertainty, not statements about Trellus features, customer conversations or results.

Find out what the buyer means by “Can it do that?”

Imagine a buyer asks, “Can it update our renewal field after a call?” The rep recognizes the word “update” and knows the product saves some call information. That isn't enough to answer the actual question.

Which record holds the field? What should trigger the update? Does the buyer mean a suggested value that a rep reviews, or a change made without another action? A broad “yes, we integrate with your CRM” may leave both people thinking they agreed on different behavior.

Ask only for the detail needed to make the question answerable. You don't need to turn a straightforward feature question into a second discovery call.

Buyer: “Can it update our renewal field after a call?”
Rep: “Do you mean the renewal date on the account record, updated automatically when the call ends, or a value the rep reviews and saves?”

If the buyer says they only need a note they can copy, the question has changed. If they need the account field changed automatically, keep that requirement intact when you check. Don't quietly replace it with the easier workflow you already know.

Once you have enough detail, stop asking. More questions won't substitute for finding the answer.

Give the answer you have, not the answer beside it

Sometimes one part is documented and the rest is uncertain. Explain the supported part in a complete sentence, then name the missing part just as clearly.

“I can show you where the call note is saved. I haven't confirmed whether this setup can write that account field automatically. I'll check that specific field and trigger before I tell you it can.”

This response is useful only if the first sentence is true for the product and setup being discussed. Familiarity with another customer, a different platform or an older screen is a reason to investigate, not a substitute for the current answer.

Avoid words that make the gap disappear. “It should,” “normally,” and “I don't see why not” can sound like a promise when the buyer is deciding whether to move forward. If you're giving an estimate or describing something you haven't confirmed, say so directly.

Nor should you guess that the answer is no. “I haven't confirmed it” and “the product doesn't support it” tell the buyer different things. An unsupported rejection can be as misleading as an unsupported yes.

When the current answer is a confirmed limitation, give it plainly. Explain a documented alternative if there is one, including the extra work it requires. A manual workaround isn't the automatic behavior the buyer originally requested.

Decide whether to check now or take the question away

If you know where the relevant documentation is and the buyer has time, offer to look at it together. Read the part that answers their question, including prerequisites and limits. Opening a page with the right product name isn't the same as finding the promised behavior.

Don't make the buyer sit through a long search while you narrate every tab. When the source is unclear, the setup is unfamiliar or the answer needs another person's judgment, agree a follow-up instead.

“I don't have a reliable answer in front of me. Is this a requirement you need resolved before we discuss the rest, or can I confirm it in a follow-up?”

The response should change the call. If the feature is essential and nothing else is useful until it's settled, pause the relevant recommendation. Don't use a meeting booking to stand in for an answer. If the buyer is comfortable continuing, discuss other parts without implying that this question has been resolved.

A live demonstration can help when it uses the intended setup and shows the result the buyer asked about. If you can only show a different example, explain that difference. A nearby screen may help describe the idea; it doesn't settle the buyer's exact requirement.

Keep private account information in its approved location. A question sent to a colleague usually needs a description of the workflow, not a pasted customer record or a full transcript.

Make the handoff specific enough to answer

“Buyer asked about CRM integration” gives the next person a topic, not a question. They may reply with a broad compatibility page and leave the actual uncertainty untouched.

Use a short question card. These are suggested manual notes, not required CRM fields or an automatic Trellus workflow:

• Question: What did the buyer ask, in their terms?
• Intended setup: Which platform, record, field and action matter?
• Required result: What would the buyer need to see happen?
• Answer already given: What did the rep actually say, including any uncertainty?
• Check owner and source: Who will verify it, and what documentation or demonstration would answer it?
• Reply plan: Who will respond to the buyer, by when, and what remains unconfirmed?

Here is a filled fictional example:

Question: Can a completed call automatically update the renewal date on an account record?
Setup: Buyer's named CRM; account date field, not the contact's call note. Exact field configuration still needs confirmation.
Required result: The intended date appears on that account without a separate copy-and-paste step.
Answer given: Rep showed the documented call-note destination but did not confirm the account-field update.
Check: The team's product specialist will check the supported object, field type, trigger and required setup. If the answer depends on configuration, list those conditions.
Reply: Rep sends the answer by the agreed time. No statement that the field update is supported until it has been confirmed.

The last line is a task for the seller, not proof that the buyer agreed to another call. If a callback was actually requested, record that separately using the callback note guide. Don't create an appointment merely because someone needs to check a fact.

Close the question even when the answer disappoints

Reply to the original requirement first. “We found a workaround” isn't a complete answer if the workaround changes who does the work or when the result appears.

A useful follow-up might say: “The automatic account-field update you asked about isn't supported in the setup we checked. The documented alternative is a manual update after reviewing the call note. That adds a step, so it may not meet your requirement.” Use that wording only when the limitation and alternative have actually been established.

If the answer is yes with conditions, state the conditions beside the answer. If a demonstration or further setup check is still needed, keep it on the list of open questions rather than marking the requirement complete.

If you miss the promised reply time, say what is still unresolved and offer a revised time you can reasonably meet. Don't invent a product answer to avoid admitting that the check is late.

And if you realize you already gave an inaccurate answer, correct it directly. Say what you said, what is now established and how that changes the proposed next step. Don't hide the correction in a new document link. The guide to recovering from incorrect sales research covers a different situation—an inaccurate premise about the prospect—but the distinction is useful: an unknown answer needs checking; an incorrect answer needs correction.

Practise the decision, not a polished way to say “maybe”

For a short practice exercise, give a colleague a product question with one missing detail. Let them ask the rep to distinguish a known behavior from an unconfirmed one. Then change the buyer's response: in one attempt the missing feature is essential; in another it is only a preference.

The rep's next action should change. In the first attempt, continuing the recommendation may not make sense. In the second, it may be reasonable to keep talking while someone checks. Don't score both attempts by whether they produce a meeting.

Use the two-sided role-play brief to keep the buyer's instructions separate from the caller's. A fictional exercise can show whether the rep notices uncertainty; it doesn't establish how real buyers will respond.

When you're evaluating a dialer for your CRM or sales engagement platform, bring one question this precise. Ask where the work starts, what the rep does and where the result appears. A clear answer—including a clear limitation—helps you choose a workflow. Confidence alone doesn't.