A profile that says your software helps every business save time gives a reviewer little basis for rejecting a conversation. Write the profile around a particular person doing a particular task, with enough capability detail to explain both a match and a mismatch. This guide provides a manual brief and a three-case check. The invoicing product below is fictional; its capabilities illustrate the method and are not ReplyRadar features.
Describe work before a market category
Start with who performs the task, what triggers it, and what they currently do. Solo consultants chasing overdue invoices is more useful than businesses needing productivity. A category can help discovery, but the task explains why the conversation might matter.
Separate present capabilities from plans
List what someone can use today. Put requested integrations and roadmap ideas outside the current capability statement. Otherwise a strong buying signal can produce a confident recommendation for a requirement you cannot satisfy. Confirm important claims against the actual product, not an old headline.
Keep pain language distinct from buying intent
Repeating reminders describes a problem; asking which invoicing tool to choose describes a decision. Keep both in the brief without treating them as interchangeable. A relevant complaint can justify research while still giving you no reason to recommend a product.
Write a reason to say no
Include decisive boundaries such as an unsupported workflow, required integration, or team setup. Use observable requirements rather than assumptions about a person's budget or identity. A useful brief narrows the recommendation without pretending to know facts that the thread does not supply.
A filled product-fit brief
Representative fictional example: a simple invoice-reminder app. Replace every detail with a checked fact about your own product. The manual brief is broader than any one application's settings form.
| Focus | Too broad to guide a decision | Useful profile entry | Recommendation |
|---|---|---|---|
| Buyer and task | All small businesses that want automation. | Solo consultants who send a small number of invoices and manually follow up on late payments. | Name the user and recurring task. Do not add an industry unless it changes the workflow. |
| Supported job | Streamlines finance. | Tracks invoice status and sends reminders using the app's supported invoice workflow. | Check the exact workflow and any dependencies before using this claim. |
| Pain phrases | Productivity, growth, efficiency. | Chasing invoices; forgetting reminders; checking which invoices are overdue. | Treat these as suggested phrases until real conversations confirm the vocabulary. |
| Fit boundary | Better than complex tools. | Does not provide payroll or multi-entity accounting in this fictional example. | A payroll requirement is a rejection reason, even when the author wants to buy immediately. |
| Alternatives | Every finance application. | A spreadsheet plus manual reminder emails; other tools the buyer actually names. | Distinguish a current workaround from a verified competitor capability comparison. |
Representative: accept the task, then verify the dependency
A consultant asks for a way to stop forgetting invoice reminders, but the thread does not say which invoicing system they use.
Why it matters: The task fits. The dependency is unknown. Check compatibility or ask a useful clarifying question before recommending the fictional app.
Representative: reject a tempting buyer
An agency wants to replace its finance stack this week and requires payroll for several entities.
Why it matters: The buying motion is strong, but the required capability fails the brief. Keep the rejection even if several pain phrases match.
Representative: keep research separate
A freelancer describes how awkward it feels to chase payments but says their existing software works well.
Why it matters: Save the language if it helps understand the problem. Do not turn emotional frustration into an assumed software replacement decision.
Run the three-case check before expanding discovery
Choose a clear fit, a clear mismatch, and an ambiguous thread. Write the expected decision and the supporting sentence before checking a score. If the profile cannot distinguish these cases, revise the missing task or capability detail. Keep the same examples for checking the edit, then review fresh examples to avoid tailoring the brief to only three posts.
Correct the imported profile
ReplyRadar can import product information from a website. Review the audience, description, pain points, keywords, and competitors available in project settings. Remove stale claims and unsupported alternatives. Keep any extra evaluation notes in your own worksheet; this guide does not imply every brief field has a dedicated product control.
Keep changes explainable
Record the old wording, the edit, the mismatch that prompted it, and the review date. Change the profile when product facts or repeated fit evidence warrant it. Do not rewrite your target buyer after every unusual post, and do not describe your product as serving a new segment simply to increase match volume.
Give each match a product-fit reason you can check.
Review how ReplyRadar uses your project context before relying on a score or drafting a reply.
Should I add every keyword from my homepage?
No. Keep words that help identify the buyer's task or a meaningful requirement. Broad benefit language can be useful marketing copy without being a useful matching signal. Evaluate the resulting conversations rather than the length of the keyword list.