Fraud filtering and CRM: protecting genuine customer enquiries

After a suspicious-enquiry filter is enabled, the report looks better: fewer junk submissions and less time spent checking contacts. What happened to genuine customers the system also rejected? Unless those enquiries are retained for review, the loss is invisible in the CRM.

In iConText Group's account of its T2 project on Cossa, the authors describe the risk of incorrectly rejecting mobile traffic when the same rules apply across different channels. This is the project participants' account of acquiring app installs, rather than an independent evaluation of all fraud filtering. It is a useful prompt to review your criteria while preserving the distinction between an app install and a CRM enquiry.

The analysis below concerns how lead review is organised. It does not replace an advertising-fraud specialist's work or suggest applying timing thresholds from mobile acquisition to website enquiries.

What a “suspicious” flag actually means

A system may stop an enquiry for three different reasons: signs of automated submission, failure to meet technical requirements or failure to meet commercial criteria. Calling all three fraud prevents the team from choosing the right response. An invalid telephone number may be a typing error. A repeat enquiry may mean the customer received no answer.

Keep the review status separate from the sales status. One explains how the system assessed the event; the other records what the team learned in conversation. Even a confirmed lack of commercial interest does not retrospectively make the visitor fraudulent.

Imagine several employees using one corporate network to enquire about a similar task. A filter detects repeated technical characteristics. That is a reason to inspect the records, but does not prove fraud. Equally, a successful first purchase does not guarantee that every future action by the contact will be legitimate.

Check event quality before changing thresholds

Reconstruct the path of one enquiry: submission, server receipt, rule evaluation, transfer to the CRM and salesperson action. Keep an event identifier and time at each stage. Distinguish another delivery attempt for the same event from a new customer request, or a reliable retry after a failure will look like spam.

Account for system clocks, time zones, transfer delays and missing data. Using the CRM record's creation time instead of the original submission time misrepresents customer behaviour. A missing value must not automatically become zero and a confirmed anomaly.

Check the rule version separately. Without it, you cannot explain why a similar event was accepted yesterday and rejected today. Retain the decision reason and configuration version for disputed records, with access and retention limited according to the agreed process.

Bring sales feedback into the review

The CRM can show which contacts are reachable, which problems fit the service and where work stopped. A filter review needs rejection reasons as well as the final status. Sales may have failed to reach the person, the customer may have chosen another solution or an integration may have lost a message. Each requires a different correction.

Send outcomes to analytics only after verifying identifier matching. Metrica's documentation includes reporting on offline conversion matching and reasons for failure. A missing matched outcome may therefore be a transfer-data problem; it cannot immediately be read as no deal.

The CRM is not an unquestionable source of truth either. Missing rejection reasons, premature closure and several records for one enquiry change the findings. Before using statuses as training or evaluation labels, review a sample manually and agree their meanings with the responsible staff.

Test before permanently rejecting enquiries

For some uncertain events, consider an observation mode: the rule records its proposed decision while the actual action goes through a controlled review. This is appropriate only where the team has assessed the risk and can handle those enquiries safely. Confirmed dangerous scenarios do not require weaker protection for an experiment.

Review accepted and rejected records. Looking only at accepted enquiries shows sales workload but cannot reveal genuine contacts behind the filter. Each reviewed record needs evidence that distinguishes a wrong decision from insufficient information.

Assess changes from both sides: how many unwanted enquiries got through, and how many suitable ones were incorrectly stopped. These measures require a known manual review procedure. Show unreviewed records separately. Overall rejection percentage is useful for monitoring but insufficient for judging quality.

Breakdowns by source and period help reveal a changing traffic mix. If one placement starts attracting a different audience, an aggregate can hide the problem. Record configuration changes and retain a way to restore the previous version, keeping evidence for later review.

The practical business outcome is an explainable decision chain from advertising event to salesperson response. CRM integration and reliable enquiry delivery provide its foundation.

Preserve context before judging lead quality

At Dent-Picks, I connected incoming IVR calls to lead creation in GoHighLevel and added AI analysis of who called and why. This is a documented example of retaining enquiry context. It is not an antifraud case: the public description makes no claim about fraud detection or false rejection rates. For lead quality review, that context can support a separate human decision rather than automatically justify rejection.

The accompanying guide to moving from spreadsheets to a system follows a data source, responsible owner and exception path. That map helps separate missing information, transfer failures and disputed lead assessments before a record is labelled suspicious. Each of those cases needs its own verification route.

Sources

• iConText Group, Cossa: T2 and mobile traffic checks.
• Yandex Metrica: submitting and processing offline conversions.

Sources checked on 7 October 2026.