The strongest warning sign is a provider who cannot connect a promise to an observable result and an owner who can act on it. You do not need to understand every technical component to ask for evidence. You need to know what the customer experiences, where the record lands and who can correct it.
These five red flags are reasons to investigate, not automatic proof that a vendor is dishonest. Some answers may reflect an unfinished proposal. Ask the questions, document what remains unknown and avoid treating the missing evidence as a completed capability.
1. Results promised without conditions
Be careful with claims such as every call becomes a job, rankings are guaranteed or an AI engine will recommend you. Ask what population, period and outcome the claim refers to. Does it describe a real comparable deployment, a controlled test or a forecast?
Google says there is no way to request or pay for a better local ranking. A vendor can work on useful information and technical quality, but that does not make a position in search a product they can guarantee.
Ask: what will we measure, what assumptions affect it, and what evidence would show the claim was wrong? If the answer is only more confidence, do not use it in your forecast.
2. A demo that hides the receiving system
A good phone conversation can still end in an unmonitored inbox. Ask to see the actual destination record and the next person who will use it. Check service details, status, timestamps and any appointment reference.
Ask: when this demo says booked, where is the confirmed booking? What happens when the calendar is unavailable? Jobber's booking documentation shows why approval-required requests and confirmed appointments need different wording.
If the provider needs access before demonstrating that handoff, mark it as pending and define the controlled test. Do not quietly upgrade a proposed integration to a verified one.
3. Security or privacy reduced to a badge
Statements such as secure, compliant or Canadian should lead to specific questions about the proposed data flow. Which providers receive transcripts or addresses? Who can access them? What retention applies? What happens when your engagement ends?
Ask for the processor list, access model and deletion/export process. Canadian privacy authorities publish AI principles, but an official guidance page does not establish a particular provider's compliance. Have the responsible people review the actual configuration and obligations.
4. No usable human control
If the owner cannot pause automated action, correct a request or find the exception queue, the process may create an expensive dependence on support. Ask the operator to demonstrate those controls in the intended environment.
Ask: who handles an uncertain enquiry, who is the backup, and what does the customer hear while the issue is unresolved? Include a repeated request and a failed destination in the test. An alert sent to someone is not proof that they can complete the handoff.
5. Measurement stops at the easiest number
Calls answered, website visits and form submissions are useful observations, but they are not interchangeable with qualified conversations, appointments or completed work. Ask how the provider follows a request into the authoritative job record.
Google's campaign URL documentation describes source tagging. It does not establish a later booking by itself. Ask which outcomes can be matched reliably and which remain unknown. Insist that hypothetical examples stay labelled as hypothetical.
Turn the questions into a purchase decision
Record each answer as verified, demonstrated, proposed or unknown. The missing items become conditions for the pilot rather than vague worries. Compare the vendor scorecard with a simpler option such as clearer intake or configuring a tool you already own.
See GlassRiver's approach. Discuss a proposal with the operator scenarios and evidence you want to see. The aim is a decision you can defend, including a decision to wait when the critical handoff is not yet established.