7 steps · 12 min read

Vendor recommendation post response playbook

A seven-step workflow for answering a public vendor recommendation request with clear disclosure, useful criteria, and response-led follow-up—not a pitch.

Who this is for: B2B founders and lean GTM teams deciding whether a public recommendation request calls for a disclosed answer, one clarifying question, an invited private handoff, more research, or no response.

A vendor recommendation post can reveal a real evaluation job, but it does not automatically create a referral, a private-message invitation, or permission to pitch. The useful response verifies the request, discloses the vendor relationship, answers the stated criteria, and lets the requester’s next action control the follow-up.

This playbook starts after discovery. Use the vendor recommendation post verification guide first when the source, requester, buying job, fit, freshness, or thread state is still uncertain.

Step 1. Reopen the original recommendation request

Work from the live post and full thread, not an alert, screenshot, summary, or keyword label. Preserve the URL, visible author, date, exact request, audience, community rules, replies, edits, and any resolution. Confirm which words belong to the requester and which belong to commenters, quoted posts, link previews, or tagged people.

Source state	What it can support	What it does not support alone
Broad “what tools do you use?” question	Category learning or one useful clarification	An active shortlist, budget, or immediate sales call
Current workflow plus named requirements	A criteria-first public answer with fit and non-fit	Authority, purchase timing, or a private route
Vendors explicitly invited to reply	A disclosed vendor answer in the requested channel	Concealed promotion or parallel outreach elsewhere
Peer-only group or no-promotion thread	Research, product learning, or no action	A workaround through a connection request, DM, or email
Named introduction with permission from both sides	A real referral handoff carrying the stated context	Extra claims about need, authority, budget, or urgency
Resolved, stale, deleted, or closed request	Historical learning and measurement	A live recommendation-response workflow

Step 2. Prove the decision job, requester, and fit

Translate the request into a decision job before writing copy. Record what the requester is trying to accomplish, their present workflow, must-have constraints, acceptable tradeoffs, exclusions, decision owner, and any stated timing. Do not turn a category question into a problem statement the author never made.

Requester: is the author buying, researching for a colleague, collecting market examples, creating content, helping a client, or simply starting a discussion?
Decision job: what outcome, workflow, or comparison does the post actually ask people to help with?
Constraints: which channel, team size, approval, integration, geography, data source, or operating rule is explicit?
Fit: can your product materially satisfy those requirements today without stretching a roadmap item into a feature?
Non-fit: which stated requirement should make you say no, qualify the answer, or recommend another approach?
Invitation: did the author ask peers, customers, operators, vendors, or anyone with relevant experience to respond?

Use the free Buyer Intent Signal Prioritizer to review source strength, fit, likely ownership, freshness, and the smallest justified next action before a response enters a queue.

Step 3. Separate a public request from a referral

A public recommendation request and a referral are different states. A post asks a network for decision help. A referral carries a specific person-to-person introduction or permission to invoke a name. Do not manufacture borrowed trust by treating a tag, comment, or public post as a mutual introduction.

Event	Relationship state	Safe next action
The author asks the public for options	No referral exists	Answer the criteria publicly with affiliation disclosed
A commenter tags your product or profile	Attention or a possible suggestion	Verify the request and add a useful disclosed answer if permitted
Someone says “talk to Maya” without Maya’s input	Possible route, permission unresolved	Ask whether an introduction is welcome before invoking the name
A trusted contact introduces both sides with context	Referral with a defined handoff	Thank the referrer, preserve the context, and let the new person confirm the job
You already know the requester through an active thread	Existing relationship	Continue in that relationship without pretending the public post created it
A like, repost, or second-hand screenshot surfaces the request	Discovery only	Reopen the original source or stop

Never write “you were referred by” unless the named person actually made or authorized that introduction. The referral context is evidence to preserve, not a name to drop for attention.

Step 4. Build the recommendation response brief

Keep one short record beside the draft so another reviewer can reopen the source, see why the answer fits, and understand what must happen next. A score or recommendation-post label cannot replace this brief.

Field	Question to answer	Do not infer
Source and requester	Who asked what, where, when, and for whom?	That a tag, alert, or commenter is the buyer
Decision job	Which outcome, workflow, and constraints are explicit?	Private pain, budget, authority, or purchase stage
Fit and non-fit	Which requirements can and cannot be met honestly today?	Capability from category membership or roadmap plans
Affiliation	What employment, ownership, payment, partner, or customer relationship must be clear?	That the audience already knows the relationship
Decision help	Which criterion, tradeoff, example, or limitation helps every reader?	That a product mention alone answers the request
Route and invitation	Is the next action public, clarification, invited private, referral, learn, hold, or stop?	Private permission from public visibility
Expiry and stop state	Which resolution, reply, contradiction, rule, opt-out, or date closes the route?	That silence keeps the recommendation window open

Step 5. Choose the route before writing the pitch

Match the route to the request and thread state. A public question normally deserves a public answer because the decision help remains available to everyone. Private outreach should be a response to an invitation or established relationship, not an escape from disclosure or community rules.

Current state	Primary route	Transition rule
Criteria are clear and your product materially fits	Disclosed public answer	Move private only when the requester asks for relevant detail
The category is clear but the decision job is vague	One useful clarifying question	Answer the reply before mentioning your product
Private examples, pricing, or technical detail are invited	Invited private follow-up	Deliver the requested detail before proposing a broader next step
A real introduction connects the requester and a new owner	Referral handoff	Preserve the introduction and let the new person confirm the need
Your product misses a must-have requirement	State the non-fit, offer neutral criteria, or stay out	Do not reframe the requirement around your strongest feature
Peer-only rules, sensitive context, stale request, or opt-out	Learn, hold, or stop	Private contact is not a workaround

Step 6. Write an answer that improves the decision

A useful response does five jobs in order: disclose the relationship, reflect one stated requirement, offer a decision criterion, show fit and non-fit, and leave a proportionate next step. Avoid borrowed trust, invented customer results, unsupported superlatives, false urgency, and a meeting ask that is larger than the requester’s commitment.

Hidden pitch

“Funkel AI is the best option. We help teams triple replies, and a mutual connection said I should reach out. DM me today for a quick demo.”

This version hides the relationship, invents a referral, uses an unsupported performance claim, ignores the stated criteria, and forces the conversation private.

Disclosed, criteria-first public answer

“I build Funkel AI, so this is a vendor answer. If your main requirement is keeping the original buyer signal beside each draft, compare whether every option preserves source, likely owner, approval, and stop state through follow-up. Funkel AI is designed for lean teams running reviewed LinkedIn, X, and email workflows; it is not a bulk contact database.”

Useful clarification before a product answer

“Is the harder part finding relevant accounts, identifying the person who owns the problem, or controlling follow-up after a reply? Those lead to different tool categories, so the answer changes.”

Invited private handoff

“Thanks for inviting the message. Here is the comparison checklist you asked for: original source, problem owner, review step, channel route, and stop state. If you share which handoff is failing, I can point to the relevant section without expanding the scope.”

Honest non-fit

“I build Funkel AI. It can help with reviewed, signal-led outreach, but it is not the right fit if your primary requirement is a large standalone contact database. I would compare coverage, verification source, refresh policy, export controls, and suppression handling across the data providers in this thread.”

Pre-response review

Can a reviewer reopen the original post and full thread?
Which words belong to the requester?
Who is the requester researching for?
What decision job and constraints are explicit?
Is the request still current, open, and unresolved?
Does the platform or community permit a vendor answer?
Which relationship or material connection must be disclosed?
Which requirement does the response answer directly?
What useful criterion applies even if the reader chooses another option?
Which non-fit or limitation should be visible?
Is there a real referral, a private invitation, or neither?
What reply, resolution, correction, opt-out, rule, or expiry stops the route?

Step 7. Let the response state control follow-up

Reopen the response brief before every next action. The requester’s latest state overrides a preset schedule, even when an automation still has tasks queued.

Useful public reply: answer the new question where the conversation already works. Do not force a private move.
Private invitation: deliver the promised evidence, checklist, pricing, or technical answer before suggesting a call.
Referral: carry the exact context, confirm permission to invoke the referrer, and let the new person restate or reject the job.
Choice made or request resolved: congratulate, learn, and close the old route rather than arguing for another evaluation.
Correction, objection, or non-fit: update the record and stop using the earlier assumption.
Opt-out, complaint, deletion, or moderator warning:stop and preserve the suppression across future alerts and channels.
No response: do not turn silence into permission for a connection request, DM, email, or repeated public mention. Close or wait for genuinely new evidence.

Use the free Campaign Follow-up Planner to turn the actual response state and still-valid reason into a dated continue, hold, reroute, or stop plan.

Three recommendation-response examples

Public answer, then invited product detail

A founder asks for an outreach tool that keeps source evidence and human approval attached to every draft. You disclose that you build Funkel AI, answer those two criteria publicly, and state the bulk-data non-fit. The founder asks for the workflow view in a private message. Send that requested detail and keep the original criteria attached.

Broad request, clarification, then no fit

An operator asks for the “best sales tool” without a job or constraint. You ask whether the need is contact data, signal discovery, sequencing, or CRM control. They answer that standalone contact coverage is the priority. State that Funkel AI is not the primary fit and leave a neutral data-provider comparison checklist.

Peer-only thread, no vendor workaround

A private community member asks peers for first-hand customer experience and the rules prohibit vendor promotion. The source is useful for product and market learning, but you do not reply, request a connection, hunt for an email, or ask a customer to post on your behalf.

How Funkel AI fits this workflow

Funkel AI can use configured public LinkedIn and X sources in a reviewed workflow, compare a surfaced person with a buyer profile, and keep the original reason, draft, route, approval, and stop conditions together. It does not access private communities, prove the requester owns a purchase, turn a public question into a referral, supply a lawful basis, create permission for private contact, independently verify every claim, or make every recommendation post appropriate for outreach. See how Funkel AI keeps evidence and human review attached to the next action.