How to Choose Enterprise Software That Fits the Work

A software evaluation often begins with a spreadsheet that already contains the wrong answer.

The rows list features. The columns list vendors. Someone adds green, amber, and red cells, then calculates a total. The product with the most green appears to win. Yet six months after the contract is signed, users still keep their old spreadsheets, integration work is late, security exceptions are multiplying, and the supposedly cheaper option needs a small internal team to keep it useful.

The scoring was tidy. The decision was not.

Enterprise software should be selected by how well it supports important work under real constraints, not by how many nouns appear on a feature page. That principle applies to a CRM, data catalog, observability platform, analytics tool, coding assistant, or AI agent platform. It also changes the role of a pilot: the pilot is not a period for admiring the product. It is a controlled attempt to disprove the buying case before the organization becomes dependent on it.

The framework below turns a workflow into evidence, evidence into a decision, and the decision into obligations that survive the sales process.

Start with a requirements-to-evidence scorecard

Do not ask every stakeholder to contribute a wish and then call the combined list “requirements.” Start with a small number of outcomes, failure boundaries, and operating constraints. Then decide what evidence would be strong enough to support each claim.

Here is a reusable scorecard.

The weights are not universal. A hospital system may give reliability and control much more weight. A reversible experiment for a five-person team may emphasize workflow outcome and speed. What matters is setting the weights before the finalists are emotionally established. Changing the weights after a charismatic demo is just preference disguised as analysis.

Some criteria should not be weighted at all. They should be gates. If a product cannot meet a legal requirement, isolate sensitive data, support required recovery objectives, or provide an acceptable contractual control, extra points elsewhere should not compensate. A beautifully usable product that creates an unacceptable exposure is not a close second. It is ineligible.

Define the work before discussing products

A useful requirement describes observable behavior in context. “Has an AI assistant” does not. “A support agent can draft an answer from approved policy documents, show the supporting passages, and route low-confidence cases for review” does.

For each important workflow, write a compact scenario with six parts:

• Actor: the person or system doing the work.
• Trigger: the event that begins the task.
• Inputs: the data, documents, permissions, and context available.
• Outcome: the completed job and the business result it supports.
• Boundaries: actions the product must not take or data it must not expose.
• Evidence: the measure that would show improvement over the current method.

Suppose a company is evaluating an AI-enabled contract review service. A weak requirement says the platform must summarize contracts, extract clauses, integrate with storage, and provide analytics. Almost every serious vendor can say yes.

A stronger scenario says a legal operations analyst receives a supplier agreement in the existing document repository. The system identifies six specified clause types, links every extracted claim to its location, follows the analyst’s access rights, and sends uncertain or conflicting language to review. On a set of previously reviewed agreements, the team will measure missed clauses, unsupported extractions, review time, and the cost per completed agreement.

Now the conversation is about work. A vendor may have fewer features and still perform better on what matters. Another may pass the feature comparison but fail because citations break on scanned documents or permissions do not follow the source repository.

This also creates a clean boundary with the decision in Treat Internal AI Systems Like Products. Whether software is bought or built, someone still has to define the user, the job, the limits, and the ownership model. Procurement cannot outsource product thinking.

Separate selection criteria into gates, scores, and observations

Teams create confusion when every statement in an evaluation has the same status. “Must support single sign-on,” “users like the interface,” and “the roadmap looks promising” are different kinds of information.

Use three categories.

Gates are non-negotiable conditions. They include regulatory constraints, required identity controls, data residency, a minimum recovery objective, or an integration without which the workflow cannot operate. A gate needs a pass condition and evidence. “Enterprise security” is not a pass condition.

Scores compare viable alternatives. Workflow time, administration effort, expected three-year cost, reporting quality, and ease of change can be scored when the scale is anchored. A score of five might mean users complete the task at least 25 percent faster than the baseline with no material increase in errors. Without anchors, a five merely means someone liked the product.

Observations record information that matters but is not yet proven: a promising roadmap item, concern about a new vendor’s support capacity, or unusually good reference feedback. Observations should influence risk discussion, not quietly become points.

Keep an evidence column beside every gate and score. Mark the source: buyer-run test, contract, technical document, customer reference, vendor assertion, or future roadmap. The source affects confidence. A working export performed by the buyer is stronger than a slide saying data is portable.

This is where organizational politics becomes visible. An executive preference, an existing vendor relationship, or a famous brand can be recorded as context, but it should not silently alter the technical result. If leadership chooses a lower-scoring product for strategic reasons, write that reason in the decision record. Transparent judgment is healthier than manipulating the model until it ratifies a predetermined choice.

Make the trial resemble an ordinary bad day

The best product demonstration is one the buyer controls.

Give finalists the same scenarios, representative data, known difficult cases, expected volumes, and time window. Let real users perform the work. Do not allow each vendor to choose the workflow that flatters its product. Preserve a baseline from the current process so that “better” has a reference point.

Then add friction. An enterprise product will not operate forever under demo conditions. Test an unavailable dependency, a malformed file, a revoked permission, duplicate records, a large request, a model timeout, an incorrect user action, or a partial network failure. The exact cases depend on the product, but the purpose is constant: observe the failure, recovery, and support experience.

For AI products, evaluate the whole workflow rather than a handful of attractive outputs. Record quality by failure type, not only an average score. A system that is usually fluent but occasionally invents a policy has a different risk profile from one that refuses too often. Test prompt injection where external content enters context. Check whether tool calls respect authorization. Confirm what is logged, retained, used for model improvement, and visible to the vendor. Establish whether a model or prompt change can alter behavior without a buyer-controlled regression test.

NIST’s AI Risk Management Framework core supports this contextual approach: it calls for documenting the task, application scope, human oversight, and risks from third-party software and data. That is more useful to a buyer than treating “AI” as a single capability with a single risk score.

If the main uncertainty is whether an AI claim survives representative data, use the deeper testing process in How to Test AI Vendor Claims Before You Buy. The scorecard here serves a different purpose: it combines that evidence with usability, architecture, economics, and exit conditions to make the final selection.

Price is a quote; cost is an operating model

The purchase price is often the easiest number to obtain and the least complete number in the decision.

Build a three-year cost model with at least three usage scenarios: expected adoption, slow adoption, and high adoption. Include licenses or consumption, implementation, migration, integration, security review, data preparation, training, administration, support, monitoring, customization, and eventual exit. Include internal labor even when it does not create a new invoice. An engineer spending two days every month repairing an integration is a product cost.

AI services add variable model usage, embeddings, storage, evaluation runs, observability, human review, and sometimes multiple providers. Agentic products can multiply consumption because one user request may trigger several model and tool calls. Ask for the unit cost of a completed useful workflow, not merely the cost of a token, seat, or API call.

The slow-adoption scenario matters because many enterprise agreements assume seats will become active faster than behavior changes. The high-adoption scenario matters because a cheap pilot can become expensive once usage, context size, data retention, and support load grow. Both scenarios should include contractual thresholds, overage prices, minimum commitments, and renewal assumptions.

Avoid false precision in the benefit side. Time saved is not automatically cash saved. If a tool reduces a task from 20 minutes to 15, what happens to those five minutes? Does capacity increase, delay fall, customer experience improve, or does the time disperse into other work? State the mechanism. A defensible range is better than a confident but fictional return-on-investment number.

Security and resilience belong in the buying decision

Security questionnaires are useful, but they often arrive late and become an approval ritual. Product security should shape requirements, evidence, and contract language from the beginning.

CISA’s Secure by Demand guide explicitly places security across the procurement lifecycle: question suppliers before purchase, put appropriate requirements into contracts, and continue assessing security outcomes afterward. That last part matters. Procurement is not a one-time transfer of risk.

Ask how the supplier handles vulnerability disclosure, exploited vulnerabilities, patches, secure defaults, logging, multifactor authentication, and support for older versions. Determine which controls are included and which require a premium tier. Review subprocessors and critical dependencies. Require notification terms for incidents and material changes. Match the depth of review to the product’s access and business criticality.

NIST’s current cybersecurity supply chain guidance explains why this scope is necessary: buyers often lack visibility into how acquired technology is developed, integrated, deployed, maintained, and made resilient. A certification can contribute evidence, but it cannot answer every context-specific question about your data, configuration, and recovery needs.

During the trial, verify controls that affect the real workflow. Can an administrator remove access quickly? Are audit events sufficiently detailed? Can data be deleted and is deletion propagated? What happens when a region or provider is unavailable? Has the supplier tested recovery, and can it share meaningful results? Reliability promises should map to your process, not end at a generic uptime percentage.

Treat customization as debt with a named owner

Configuration changes a supported setting. Customization creates behavior the standard product does not naturally provide. The boundary is sometimes blurry, but the economic difference is real.

A custom connector, plugin, workflow, or prompt layer may be justified. It can also create an internal product hidden inside a vendor purchase. Someone must test it against releases, monitor it, document it, secure it, and repair it when either side changes. Put that work in the cost and ownership model before selection.

Prefer products that fit the organization’s intended architecture through supported interfaces and ordinary configuration. That does not mean choosing the incumbent automatically. Existing platforms can create their own constraints, and a new product may justify architectural change. The decision record should explain the trade: which divergence is being accepted, why the business value warrants it, and what prevents one exception from becoming permanent platform sprawl.

The same discipline helps with the earlier question of whether to build or buy AI software. Buying can reduce the work of creating a capability, but it does not remove integration, governance, product ownership, or change management. If the required customization recreates the core product around the vendor, the team should revisit the original decision.

Negotiate the exit while the vendor still wants the deal

An exit plan is not pessimism. It is part of buying a durable option.

Before signing, export representative records and verify their format, completeness, metadata, and attachments. Ask what happens to derived data, embeddings, logs, fine-tuned assets, configurations, prompts, and evaluation history. Document API rate limits and export charges. Establish deletion timelines and evidence. Estimate the labor and elapsed time needed to move away.

Also inspect commercial exit conditions: renewal notice periods, price protections, minimum commitments, termination assistance, and access during transition. Roadmaps change. Vendors are acquired. Products are discontinued. A model provider may become unavailable in a region. Your own strategy may change even when the supplier performs well.

An “open API” is not an exit plan if the data model is undocumented or extraction takes nine months. The practical lock-in test is whether another team could reconstruct the required business state without the vendor’s cooperation. Avoid AI Platform Lock-In Before It Becomes Expensive examines that problem in depth; during selection, the immediate job is to turn portability into a tested requirement and a contract obligation.

End with a decision record, not a winning score

The score informs the decision. It should not make the decision by itself.

Write a short record that names the chosen product, alternatives, workflow outcomes, gates, weighted results, evidence quality, cost range, major risks, compensating controls, assumptions, dissent, and owners. Include what would invalidate the choice. For example, the selection may depend on a promised identity feature shipping before rollout; if it does not, the decision must be reopened rather than quietly patched around.

Then carry the record into implementation. Convert trial measures into adoption and service measures. Convert vendor commitments into contract checks. Convert identified risks into owned actions. Review usage, outcome, cost, incidents, and supplier changes at renewal instead of asking only whether the business still wants the licenses.

Good enterprise software selection is less about predicting a perfect future than reducing avoidable surprise. Define the work. Distinguish gates from preferences. Demand evidence in your environment. Model the operating cost. Test failure and exit. Record the judgment honestly.

The product with the longest feature list may still win. If it does, it should win because it supports the work and the organization can operate it—not because the spreadsheet rewarded the vendor that knew how to say yes most often.