Signs to Walk Away
Answers and behaviours during evaluation that predict how the next three years will go.
Reference
Most of what you learn about a vendor during evaluation is about the product. A few things are about the relationship, and those predict more.
Product signals
Monitoring features as a headline. Screenshots, activity scoring or webcam capture presented as selling points tells you what the product was designed for and how it will be configured by default.
No sandbox during evaluation. A vendor unwilling to let you configure it yourself before signing has answered the question about who configures it afterwards.
Rounding applied at capture, which makes neutrality untestable and a policy change into a migration.
Hard deletion of entries, in a system feeding payroll.
A fixed week start or a rule engine that cannot express your existing rules.
No export of the audit trail.
Commercial signals
A refusal to state processing location.
Training on customer data as a non-negotiable term.
An export fee that appears only when you ask about termination.
Uncapped renewal, in a category with high switching costs.
Automatic renewal with a long notice period, which converts a decision into a deadline you will miss.
Behavioural signals
Answers that change between the demonstration and the written response.
"We can build that for you" for something the requirements called mandatory. A customisation is a dependency and a maintenance liability.
No comparable reference, for the module you need at your size.
Vagueness on support response times, where specific numbers would mean they had measured.
Pressure on timing: a discount expiring before you can complete the evaluation is a technique rather than a coincidence.
The one that matters most
Inability to demonstrate your own hard case.
Not a feature list answer — a working demonstration with your rule, in the product, during the trial. Every vendor says yes to "can it handle split shifts". The demonstration is where you find out what yes meant.
How to decline well
Say specifically what failed, referencing the criteria written before the trial.
Keep the record, because the same product will be proposed again in two years and the file is the answer.
Tell them. A vendor who learns why they lost occasionally fixes it, and the honest response costs nothing.
And concluding no is a successful evaluation. It cost a fortnight instead of a three-year contract and an implementation.
Decline in writing
How to end an evaluation usefully.
Say specifically what failed, referencing the criteria written before the trial.
Keep the record, because the same product will be proposed again in two years and the file is the answer.
Tell the vendor why. A vendor who learns the reason occasionally fixes it, and it costs nothing.
Concluding no is a successful evaluation: a fortnight spent instead of a three-year contract and an implementation.
Ask for the complete operating flow
A polished connection page is not proof of a maintained integration. Use this sample flow to ask who supports each direction, field and failure state.
More in this section