There is no score cutoff that is best for every product and review workflow. A team researching unfamiliar buyer language may need to inspect borderline conversations that a busy reply workflow would defer. Choose the threshold by evaluating the consequences of including and excluding real examples for one project. The method below is a manual evaluation procedure; its sample scores illustrate a decision and do not predict sales or reproduce ReplyRadar's scoring formula.
Start with the action the threshold controls
A threshold for showing a drafting control is different from a threshold for admitting research evidence. Define the affected action first. An item that is unsuitable for a product reply can still contain an important objection or workflow problem.
A higher score is not a probability
Treat the score as an ordering aid within its documented context. A score of 80 does not mean an 80 percent chance of purchase. Product fit, source context, permission, and an unresolved buyer decision still need review.
Review below the line
If you inspect only included items, raising the cutoff will appear successful whenever the feed becomes cleaner. Inspect excluded examples too, especially those near the boundary and those representing known important use cases.
Capacity and quality need separate measures
Record review minutes alongside useful and irrelevant counts. A cutoff can improve the share of useful items while removing more useful conversations than the team is willing to lose. State that tradeoff explicitly.
Compare candidate cutoffs on one reviewed sample
Illustrative worksheet: a fully reviewed sample contains 100 scored conversations, of which 30 meet the defined useful label. These are hypothetical counts, not recommended cutoffs or product benchmarks.
| Focus | Included for review | Useful items excluded | Recommendation |
|---|---|---|---|
| Cutoff 50 | 60 included, 27 useful: 27/60 = 45% useful among included items. | 3 of the sample's 30 useful conversations fall below the cutoff. | Consider this only if the team can review the volume and the extra useful items justify the time. |
| Cutoff 70 | 30 included, 24 useful: 24/30 = 80% useful among included items. | 6 of the sample's 30 useful conversations fall below the cutoff. | Inspect the 3 additional useful losses compared with cutoff 50 before preferring the cleaner set. |
| Cutoff 85 | 12 included, 11 useful: 11/12 is about 92% useful among included items. | 19 of the sample's 30 useful conversations fall below the cutoff. | A high useful share may hide an unacceptable loss of coverage. Do not choose it from precision alone. |
Representative: a research project needs borderline language
The team is studying a new workflow and several useful descriptions contain no tool names or buying verbs.
Why it matters: Use a broader manual research review and label its purpose. Do not force all research evidence through a cutoff designed to suppress weak reply drafts.
Representative: the highest-scoring post is a poor product fit
A buyer has a budget and deadline but requires a capability your product lacks.
Why it matters: Keep the product-fit rejection even if the intent score clears the threshold. The cutoff cannot override a decisive capability mismatch.
Representative: a cutoff looks worse after a profile change
The product audience and project description change, and the distribution of scores changes with them.
Why it matters: Treat the old threshold decision as needing review. Compare examples under the new context rather than assuming old score bands retain the same meaning.
Write the acceptance rule in plain language
For example: the chosen cutoff must fit our review time and retain the known critical use cases in the evaluated sample. Fill in a capacity based on your team's actual schedule and specify which losses require a manual fallback.
Recheck when inputs change
Repeat the comparison after a substantive query, project, source, or scoring change. Preserve a small excluded-item audit between changes. Sample-level retained share does not establish recall across the whole platform.
Know the product boundary
ReplyRadar lets operators set a minimum score threshold for supported extension drafting controls. The worksheet, cutoff comparison, and excluded-item review described here are manual evaluation steps, not an automatic optimizer.
Set the threshold after you understand the useful losses.
Connect the sample review to the setting that controls when a reply draft can begin.
Should every project use the same cutoff?
Only if review evidence supports the same tradeoff. Different product profiles, sources, and actions can make the same numerical cutoff behave differently. Evaluate each project's useful examples and review capacity.