Answer “yes, it works” only when your current product documentation covers the buyer’s exact device, version or integration—and any conditions that apply. If an identifier is missing, ask for it. If the buyer names a model you cannot verify, say compatibility is unconfirmed rather than treating a similar model as proof.
Identify the requirement that could change the answer
Read the buyer’s post as a specification, not a general request for something in the same category. Record the exact product they want to connect or use, the named device model or software version, and the task they need it to perform. “Works with my camera” may need a model and connector; “works with version 4” may depend on the edition or an update. Ask only for the missing detail that could change your compatibility decision.
If the buyer already provided an exact model, do not ask them to repeat it. Check that model first. A follow-up question makes sense when the documentation distinguishes revisions, regions or configurations that the post does not identify.
Match the identifier to documented support
Open the current compatibility list, product specification or integration documentation for the exact offer you would recommend. Compare the buyer’s identifier with the entry itself, then read its conditions: a supported model may still require a particular revision, adapter, software version or feature configuration. Check whether those conditions match what the buyer has said. A category label or adjacent model number is not an exact match.
If the identifier is absent from one list, look for a separate entry, update or support notice before deciding. Absence alone does not establish incompatibility; it establishes that you have not confirmed support from that list. Conversely, if your documentation explicitly excludes the buyer’s configuration, do not soften that into “probably works.” When documents conflict, resolve the conflict with your product team or support information before making a public claim.
Give the answer your check supports
Choose the response based on the exact match and its conditions, not how close your offer seems. State any condition alongside a confirmed match so the buyer can tell whether it applies to their setup.
| What you established | What to tell the buyer |
|---|---|
| The exact configuration is documented as supported, and its stated conditions are met. | Confirm that configuration and name any requirement, such as a minimum version. |
| A missing model, revision or version could change the answer. | Ask for that identifier; do not confirm compatibility yet. |
| The named configuration remains undocumented after your check, or is explicitly excluded. | For undocumented support, say it is unconfirmed. For an explicit exclusion, say it is not supported. |
A similar model is not a confirmed match
Consider a fictional accessory and a buyer who asks, “Will this work with my A-21?” Assume the seller’s current compatibility list explicitly names A-20 but says nothing about A-21. The seller checks a separate support notice and finds no A-21 entry there either. The resulting decision is **unconfirmed for A-21**, not “yes” because A-20 is supported, and not “no” solely because A-21 is missing from the lists.
A useful answer is: “I sell this accessory. Our current compatibility information confirms A-20, but I can’t confirm A-21 from the information I have, so I wouldn’t recommend buying it for that model on that basis.” If the buyer said only “A-series” instead, ask for the exact model before checking. If an A-21 document later confirms support subject to a particular revision, verify the buyer’s revision before changing the answer to yes.
ReachFast surfaces public X requests and prepares a suggested reply that opens in the X thread for you to send from your own account. Treat that draft as a starting point: check the live request and your documentation, replace any unsupported compatibility claim, then decide whether to send. The compatibility decision is yours, not a conclusion supplied by the draft.
For deciding whether a post merits a response at all, see how to qualify product recommendation requests on X. Once you have a supported compatibility answer, the product recommendation reply guide covers the broader conversation.
