When a Buyer Needs a Feature You Don't Have Yet

If a buyer needs a feature your product doesn't currently offer, say that clearly before discussing what might be built. Then find out whether the missing capability blocks the job they need to do. The useful outcome may be a smaller purchase, an agreed manual process, a delayed decision or choosing something else.

“It's on the roadmap” doesn't answer whether the buyer can use the product next Monday. Even a real plan can change. If the purchase depends on a capability becoming available, leave that dependency visible instead of treating a possible release as part of today's product.

This guide uses a fictional software evaluation and a reusable requirement note. The feature, people and workflow are invented; they describe no Trellus roadmap or delivery commitment.

Start with the job the buyer cannot complete

A feature request often arrives as a short question: “Can you schedule that?” Before offering an alternative, ask what needs to happen, who needs the result and when. There is a meaningful difference between saving a few clicks and making sure a team receives information while the account owner is away.

Suppose the buyer wants a report delivered to four regional managers before their Monday meeting. Ask whether the managers need the same information, whether someone currently prepares it and what happens when that person is absent. You are trying to understand the requirement, not persuade the buyer that it shouldn't matter.

“How do you handle that today?” can help. “Why would you need that?” can sound like a challenge. Let the buyer explain the work without having to defend the request.

Write down the part that makes the requirement necessary. In this example, the problem could be consistent Monday delivery rather than the format of the report. Or the buyer might explain that no one is available to prepare it manually. That answer changes which alternatives deserve consideration.

Keep today's answer separate from a future discussion

Give the current answer in a sentence the buyer can repeat accurately to a colleague. For example: “We don't offer scheduled delivery of that report today.” Avoid an opening “yes” followed by a long explanation of how a person could do the work instead.

If you aren't sure whether a capability exists, say you need to check the exact setup. Find out before calling it available or unavailable. A feature in another edition, a limited trial or a different integration may not answer the buyer's question.

A future discussion has its own purpose. You can offer to pass along the use case or return with a confirmed answer from the appropriate product owner. Describe that next step accurately. Passing on a request isn't a decision to build it, and a discussion isn't a delivery date.

Don't introduce a release estimate you cannot substantiate just to keep the evaluation moving. If the buyer asks for a commitment or commercial terms that depend on future delivery, bring in the people authorized to make those decisions. An informal sales note should not quietly become a promise.

A fictional conversation: the weekly report cannot send itself

Imagine a seller is demonstrating a product that allows a manual report download but has no recurring delivery feature. The buyer, Morgan, needs the report in four managers' inboxes before 7 a.m. every Monday.

Morgan: “Can we have this sent out automatically every Monday?”

Seller: “We don't have recurring delivery for this report today. You can download it manually. Is someone already responsible for preparing Monday's report, or does the process need to run without a person?”

Morgan: “It needs to run without me. I'm covering two regions, and I'm often away on Mondays.”

The seller has learned something useful. A manual download doesn't meet the stated requirement unless another person can reliably take responsibility. Repeating that the download is easy would ignore the reason Morgan asked.

The next useful question is whether Morgan wants to consider a temporary manual process at all. If the answer is no, the gap remains a purchase blocker. The seller can acknowledge that and stop trying to turn the demonstration into a fit.

If Morgan is willing to explore an interim arrangement, the discussion needs an actual owner and a backup, the information required, access and a check that the result reaches the right people. None of those details is settled by showing a download button.

A manual alternative needs someone willing to do it

An alternative is worth discussing when it solves enough of the buyer's problem at an effort they accept. Walk through it with the person who would perform the work. Do they have the necessary access? Can they produce the right result? How will they handle an absence or a failed step?

For the fictional report, a seller could ask Morgan to involve the proposed reporting owner in one demonstration of the manual process. The owner should see how to select the information, create the file, check it and distribute it. Keep the recipients' access and the company's normal data-sharing rules in that conversation.

Estimate the work from the demonstrated steps, not from “it only takes a minute.” Include preparation and checking, as well as the click that creates the file. Let the buyer decide whether that recurring work is acceptable.

Don't suggest an unverified automation, another paid product or a colleague's spare time as though it were already part of the offer. An additional tool or service needs its own availability, ownership and cost discussion. A proposed alternative remains proposed until the buyer has accepted it.

Give the buyer a purchase decision they can explain

If the missing feature is essential and no acceptable current approach exists, say the product doesn't meet that requirement today. You can ask whether the buyer wants an update if the situation changes. Don't make a follow-up promise that assumes a particular release will happen.

If the product solves a different, useful part of the job, discuss that smaller scope explicitly. The buyer might choose it for one team while retaining another process elsewhere. Confirm that the smaller scope is worth buying in its own right; don't sell it as a bridge to an uncommitted future state.

If a manual process is acceptable for a limited period, record who owns it and when the buyer will review the arrangement. That review can lead to continuing, changing scope or stopping. It doesn't mean the product team has promised to replace the process by that date.

When the issue appears during an existing evaluation, preserve the checks already completed. The guide to changing pilot success criteria explains how to add a requirement without rewriting the earlier result.

A requirement note to send after the conversation

Keep the follow-up short enough that a buyer can correct it. For the fictional reporting discussion, it might read:

Needed: The same report reaches four regional managers before Monday's meeting, including weeks when Morgan is away.

Available today: Manual download. Recurring delivery isn't offered in this example.

Alternative discussed: A named reporting owner and backup prepare, check and distribute the report. Morgan has not accepted this arrangement yet.

Next step: Morgan will decide whether to involve the proposed owner in a demonstration. If a process that depends on a person is unsuitable, this requirement remains unmet.

Future feature discussion: The seller may pass along the use case. No build decision or delivery date has been agreed.

Adapt the fields to the actual conversation. If a statement is unconfirmed, label it as a question. If the buyer rejects the alternative, record that plainly rather than leaving “workaround discussed” as though the issue were resolved.

Return to what the buyer can use

A useful software evaluation ends with a clear account of the work the product supports today. For a calling tool, use the one-week dialer pilot checklist to examine the actual calling, notes and callback workflow. Check the specific CRM or sales engagement platform rather than assuming that a capability shown in one setup exists in another.

A buyer can make a reasonable decision around a known limitation. They can't assess a limitation that has been disguised as an imminent feature. Leave them with the current answer, an honest account of any alternative and a next step that someone has actually agreed to take.