Must-haves are gates, not just heavy weights
The strongest protection against a vendor scoring around a gap is to treat your true must-haves as pass/fail gates rather than high-point line items. A platform that cannot meet a must-have does not score low on that row and make it up elsewhere. It is out, regardless of its total. Reserve that treatment for the handful of capabilities that would make the platform unusable for your core work or sink the business case for switching. Everything else can live on the weighted scale, where strengths and weaknesses net out the way scoring is supposed to.
The discipline is in keeping the list short. If everything is a must-have, nothing is, and you are back to a flat checklist. Most requirements are nice-to-haves, including a good number that feel important in the moment.
Weight against your own KPIs, not the vendor’s feature list
The cleanest way to set weights is to anchor them to the numbers your team is accountable for: speed to launch, revenue per send, inbox placement, time to insight, cost per campaign, whatever your leadership actually measures you against. A capability that moves a KPI you own earns weight in proportion to how much it moves it. A capability that does not touch any of your KPIs earns very little, however well it demos. This keeps the weighting tied to outcomes you can defend, instead of drifting toward whatever the last vendor made look exciting.
Let current-state friction tell you what is real
The second input is the friction you already feel. Where does your current platform cost you time, errors, or escalations every week? Those pain points are the most reliable guide you have, because the cost is proven and recurring rather than hypothetical. Look for processes where your team is forced to track details outside the platform. Think re-keying monthly campaign rules for a frequent flyer or rewards program, or spending hours combing through error logs to figure out why an execution failed. If a platform lacks built-in instrumentation to automate recurring data reuse, keep tabs on program history, and present easily digestible analytics, your team becomes the human bridge covering those gaps. Weighting your scorecard against this actual friction forces you to prioritize native instrumentation, error-prevention guards, and auditable historical logging over flashy vendor features you will rarely use.
Tie the weights to why you are upgrading at all
The third input is the business case. Someone approved this project to solve specific problems, and the capabilities that deliver those outcomes are must-haves by definition. If the new platform does not do them, the upgrade fails on its own terms, however much else it does well. Documenting the weights against the original justification is also what keeps the evaluation aligned when the process runs long and the team starts falling for features that were never part of the reason for switching in the first place.
Look hard at core operations before you get wowed
This is where enterprise evaluations most often go wrong. Vendors will try to dazzle you with innovative features: the new AI capability or cutting-edge reporting. Bright, shiny objects are easy to over-weight.
But your team doesn’t spend its week on that. It spends its week on building, scheduling, QA, and audience management, the unglamorous work you run thousands of times. A platform that is brilliant at the novel thing and mediocre at the core thing may let your team down every day.
The test is simple. Before any requirement gets a high weight, ask whether it maps to a KPI you own, a friction you feel, or a problem the upgrade was meant to solve. If it maps to none of the three, it is a nice-to-have, and it should be weighted like one, even if it was the best part of the demo.
Where Pinpoint fits
Setting weights well is harder than it looks, because the people closest to the work are also the people most susceptible to a good demo, and the business case tends to live in a few heads rather than on paper. Pinpoint builds the weighting with your team by starting where it should start: your KPIs, the friction in your current operations, and the specific problems the upgrade is meant to solve. We separate the true must-haves from the nice-to-haves, set the gates that keep a vendor from scoring around a gap, and hold the weights to your core operations when the demos start competing for attention.
The result is a scorecard that rewards the platform that fits the work you actually do, not the one that performed best for an hour. Your team keeps the decision, working from weights you can explain to anyone who asks why they are what they are.