Explain an Unavailable Feature Without Roadmap Promises
Explain a missing feature with verified current capabilities, honest alternatives and a bounded escalation route, without inventing roadmap dates.
10/24/20263 min read
The customer asks for a feature the service does not currently provide. A well-meaning account manager replies, “It is coming soon.” That phrase may calm the conversation for a moment, but it creates a planning assumption without a verified release commitment. The customer may buy, delay another decision or design a workflow around it.
A better response separates current capability, available alternatives and uncertain future plans. It can be helpful without promising a roadmap date. The essential question is what the customer can responsibly decide using information that is true now.
Confirm the current boundary
Check the actual product, account, subscription and configuration before declaring a feature unavailable. A missing permission, disabled setting or unsupported integration is not the same as a capability the vendor does not offer. Use official documentation and the authorized support route, and identify which environment the answer applies to.
If the answer is uncertain, say what remains to be checked. Avoid telling the customer to upgrade before verifying that an upgrade would provide the needed function. Do not infer an entitlement from a feature name mentioned in a different product or an old sales presentation.
Keep the evidence and its date. W3C's PROV overview explains provenance in terms of information, activities and the people involved in producing it. Applied here, that means distinguishing a current support answer from a salesperson's recollection. The response structure below is an original editorial proposal, not a product guarantee.
A worked capability-boundary response
In this fictional example, a customer asks a reporting-service supplier for an automated export into a particular internal system. The supplier currently provides an approved downloadable report but has not verified a supported connector.
A useful answer is: “We have confirmed that your current service provides the downloadable report. We have not verified a supported automatic connector for your internal system, so I cannot promise that workflow or a release date. If a manual import is acceptable, we can assess it with your system owner, including format, access and data-handling requirements. If automation is essential, we should treat that as an unresolved requirement rather than assume it will arrive.”
The accompanying internal record is specific:
Customer need: reduce manual transfer of the approved monthly report.
Confirmed current capability: downloadable report in the documented service format.
Unconfirmed item: supported automatic connection to the named internal system.
Possible alternative: customer-controlled manual import, subject to feasibility and authorization; not yet tested or promised.
Product escalation: ask the authorized product contact whether any shareable, verified roadmap information exists.
Commercial boundary: no commitment to build, deliver or include a connector in the current price.
The alternative should not be presented as equivalent if it leaves the customer's central problem unsolved. Manual work may be unacceptable for scale, security or operational reasons. “Not a fit today” is a legitimate conclusion.
Handle roadmap information carefully
A feature request, an exploration, a planned item and a released capability are different states. If authorized roadmap information is available, describe its actual status and limitations. Do not turn an indicative period into a guaranteed date or share confidential product plans merely because the customer asks.
When no reliable information is available, explain the escalation route and the next update you can actually control. You can commit to checking with the product owner by an agreed time if you have authority and capacity. You cannot responsibly commit that the product owner will approve the feature.
Protect the customer's decision
Ask whether the missing capability is essential, preferred or optional for the intended use. Record the answer as a requirement, not an objection to overcome. If it is essential, pause claims that the current service meets the full need and offer an honest comparison of the available choices.
The final account note should preserve both the confirmed boundary and the unanswered question. That prevents another colleague from repeating an optimistic promise later. A clear limitation may disappoint the customer now, but it gives them a sounder basis for deciding than an unsupported assurance about the future.
Sources and scope
The worksheet and fictional example are original editorial proposals. References support only the stated research, data or product context, not endorsement or proof of results. Verify any product capability against the actual subscription.