01Requirements come before products
A recommendation starts from the commercial decision the system is meant to improve, the data it has to hold, the workflow it has to support and the people who have to use it. A shortlist assembled before those are written down is a preference, not a recommendation.
02Realistic alternatives are considered
Including the alternative of changing nothing. A recommendation that never compares the incumbent, a cheaper option and doing without has not been tested against the only question that matters: whether the change is worth its cost and disruption.
03Software cost and implementation cost are separated
Licence fees are the visible number and rarely the largest one. Migration, integration, configuration, training, parallel running and the internal time to adopt a system are stated separately, because a cheaper licence with a heavier implementation is frequently the more expensive decision.
04Fit, integration, data portability and total cost govern the choice
Specifically including what happens on exit. If the data cannot be extracted in a usable form, the real cost of the system is not its annual fee — it is the cost of never being able to leave.
05Partnership does not equal recommendation
A commercial relationship with a vendor never makes that vendor the default answer. Where a relationship exists and the product is genuinely the right fit, the relationship is disclosed and the reasoning is shown. Where it is not the right fit, it is not recommended.
06No vendor is called a partner before formal acceptance
Not "in discussion", not "applied", not "we use it". A partnership is a written acceptance from the vendor, and until that exists no partner status, tier or mark appears anywhere — on this site, in a proposal or in a pitch.