A platform can satisfy a requirements spreadsheet and still be wrong for the organisation operating it. The features exist, yet editors need tickets, integrations need permanent repair and costs emerge after the commercial decision.

The problem is rarely a lack of due diligence. It is due diligence focused on theoretical capability instead of fit: real tasks, people, data, controls, cost and the ability to change direction later.

Define the decision before meeting vendors

Start with the outcomes the organisation needs over the decision horizon. These might include serving a new proposition, improving content operations, consolidating acquired sites, supporting a portal or reducing reliance on unsupported technology.

Describe a small set of representative scenarios. Each should include the user, task, data, volume, permissions and likely change. Scenarios reveal the difference between a feature label and an operable service.

Agree decision principles and deal-breakers. Examples include accessibility, data residency, recovery, editorial independence, integration standards, exit rights and an affordable operating model. Record who owns the final choice and how evidence will be weighted.

Do this before demonstrations. Vendor narratives otherwise anchor the criteria around whatever is easiest to show.

Evaluate fit across seven dimensions

Everyday user work

Ask editors and service operators to create, review, preview, schedule, correct and retire realistic content. Include reuse, localisation, permissions, accessibility and an urgent correction.

Observe where specialist help is required and whether guardrails support or obstruct the work. A powerful system that the available team cannot operate is a dependency, not a capability.

Architecture and integration

Map required systems and flows. Examine interface coverage, documentation, authentication, limits, versioning, monitoring and error recovery. “Has an API” is not a sufficient answer.

Use a proof to test the hardest critical integration. Establish who owns it after launch and how supplier changes are handled.

Security, privacy and resilience

Assess the service against the organisation's real data and risk profile. Review identity, permissions, audit, data lifecycle, incident processes, backup, recovery, supplier access and evidence of assurance.

Responsibility changes across software, platform and infrastructure products. Make the boundary explicit. A certification does not show that the proposed configuration and operating process are safe.

Delivery and operating capability

Identify the people needed to implement, govern and improve the platform. Include product ownership, content design, engineering, analytics, service support and supplier management.

Compare those needs with the team the firm has and can realistically sustain. A future recruitment plan is an assumption, and should be costed as one.

Total cost of ownership

Model licence, implementation, integration, migration, hosting, environments, support, training, upgrades, internal time and continuing improvement. Include likely growth in users, content, traffic and modules.

Ask which features require higher tiers and how pricing can change. Model a range rather than one precise figure. A cheap first year can conceal an expensive operating model.

Vendor and ecosystem

Review product direction, financial position, ownership, support quality, release history, skills availability and partner ecosystem. Consider how an acquisition, strategic pivot or end-of-life decision would affect the firm.

No vendor can guarantee a five-year future. The objective is to understand concentration and preserve options.

Exit and portability

Establish how content, assets, schemas, redirects, users, logs and configuration can be exported. Check formats, API limits, assistance, cost and contractual rights.

Run a small export during evaluation if portability is important. An exit clause without a usable route to the data offers limited protection.

Replace the standard demo with tasks

Give shortlisted vendors the same scenarios, data constraints and time. Ask them to show the work live, including an error, an approval and a change after publication.

Separate configuration available in the product from custom development or roadmap promises. Record prerequisites and recurring cost. Ask who would implement each element.

Limit the shortlist to a manageable number, typically two or three for deep evaluation. A large field produces shallow comparison and exhausts the people whose judgement matters.

Use a proof of concept for high-risk assumptions, with representative data that is safe and authorised for the exercise. Define success and deletion before providing it. A vendor sandbox may still be useful, but it cannot demonstrate every aspect of the client's environment.

Score evidence, not confidence

A weighted scorecard can make trade-offs visible. It should not turn subjective estimates into false mathematics.

For each score, capture the evidence, conditions and confidence. Distinguish observed performance, documented capability, reference testimony and an uncommitted promise. Apply deal-breakers separately; a strong average cannot compensate for an unacceptable security or accessibility gap.

Let relevant owners lead their areas while reviewing the whole service together. Marketing should not decide architecture alone; technology should not decide editorial usability on behalf of users. Finance needs full cost assumptions. Risk owners need the proposed data and workflow.

Record material disagreement and the final rationale. This makes the choice defensible when circumstances change.

The vendor-neutral platform evaluation scorecard available below includes weighting, evidence and comparison fields. Adapt it to the firm's outcomes rather than accepting the default weights.

Evaluate implementation with equal care

Platform and implementation partner form one delivery system. A capable product can be undermined by weak discovery, unnecessary customisation or a team that disappears after the pitch.

Ask to meet the people proposed for the work. Examine comparable delivery, approach to architecture decisions, content and data migration, quality assurance, accessibility, knowledge transfer and support. Speak to references about the period after launch as well as the project.

Clarify incentives and change control. A fixed price can support cost certainty while encouraging narrow interpretation; time and materials can support learning while shifting financial risk. The model must fit the uncertainty and governance.

Plan for client capability. Source, environments, documentation and administrative access should not sit solely with the partner.

For the next procurement stage, see how to write a brief for a digital partner. The discussion of headless and traditional CMS choices can help frame the architecture question, with the vendor-specific context in that article kept in mind.

Work responsibly under time pressure

When a contract expiry or unsupported platform compresses the process, protect the highest-value evidence.

Define outcomes and deal-breakers before vendor contact. Test one representative editorial journey and the hardest critical integration. Build the cost model. Review exit rights. Evaluate the actual delivery team. Record assumptions the timetable prevented you from validating and assign follow-up owners.

Do not create urgency by hiding migration, security or data work. If necessary, negotiate a short extension or phased transition to preserve a safe decision, comparing its cost with the risk of rushing.

The right platform is the one the organisation can use, connect, govern, afford and eventually leave while delivering the outcomes that justified the purchase. Distinction's platform evaluation workshop applies this method with the relevant stakeholders in the room. An independent facilitator can help keep preferences visible, although the decision and its evidence remain the client's.