Blog · Alternatives and comparisons
Classify analytics proposal requirements by demonstrable availability, configuration, bespoke development and future intention, with evidence and acceptance boundaries.
Verify analytics features against the exact service you are considering, not against a broad product slogan. A supplier may demonstrate a standard feature, configure an existing measure, propose new development or describe a future intention. Those are different forms of evidence and different purchasing commitments. A feature checklist should preserve the distinction.
This is a focused companion to evaluating an analytics vendor. It owns the question of what is delivered, rather than repeating the wider selection scorecard.
Replace “team collaboration” with the behavior required: two authorized users opening the same agreed dataset, with one permitted to edit a definition and the other limited to viewing a named territory. Replace “auditability” with the particular records and output a reviewer needs to inspect.
Specify the actor, input, action and expected result. Add the proposed plan and environment. A capability shown on an internal development system does not establish availability in the service being purchased. Nor does an available export establish that every report can be exported with its definitions and supporting rows.
Keep requirements short enough that a failure has an obvious meaning. Combine dependent tests only when they must succeed together for the intended task.
This original purchasing classification avoids awarding the same score to four different promises:
| Status | Meaning for the proposed purchase | Evidence to request |
|---|---|---|
| Available | The required behavior can be demonstrated now | Test in the proposed plan or an explained equivalent |
| Configurable | Existing behavior needs agreed setup | Configuration scope, owner and acceptance result |
| Bespoke | New delivery work is required | Deliverables, dependencies, cost and acceptance terms |
| Planned | Future intention without current acceptance | Roadmap description, kept outside available scope |
Add “unknown” when evidence is absent. Unknown is not a fifth successful feature category. It is an unresolved purchasing question. Document a limit even when a requirement is available, such as supported input shape or the scope of a particular view.
DEMO-FEATURE-01 is a synthetic review of ten equally weighted requirements. It is not a review of a named vendor. Four requirements have available evidence, three need configuration, one needs bespoke delivery and two are planned.
The available proportion is 4 ÷ 10 = 40%. If the three configuration requirements are later accepted, the proportion with accepted evidence becomes 7 ÷ 10 = 70%. It does not become 100% because the supplier intends to build the remaining items.
| Stage | Requirements with accepted evidence | Total requirements | Proportion |
|---|---|---|---|
| Initial review | 4 | 10 | 40% |
| After accepted configuration | 7 | 10 | 70% |
This proportion is a coverage description, not a quality score. A single mandatory access requirement may block purchase even if nine less important requirements pass. Mark mandatory requirements before calculating any summary.
A configured result can depend on a clean account identifier, an agreed revenue definition or a human-prepared mapping. List those conditions next to the requirement. Clarify who performs the setup and who maintains it after a new source or product appears.
Use the setup-fee deliverables guide to separate included configuration from chargeable new work. A fixed setup fee should not conceal an unlimited promise to support every future question, source or workflow.
Where the evidence is a demonstration, label its data and assistance. The demo, trial and pilot distinction helps explain which conclusion the observed result can support.
Do not remove a failed row because it is inconvenient. Record the observed behavior, expected result and proposed resolution. A temporary manual workaround can be useful, but it should retain its own status and owner.
Avoid language that makes planned features sound delivered. “Can be built” and “is included today” create different expectations. Likewise, a business login does not itself prove shared datasets, row-level restrictions, scheduled delivery or recovery capabilities. Each requires its own evidence.
Use the synthetic customer-growth report example to identify the output you want, then contact Covirage with the behaviors that matter to your users. Agree the required evidence, configuration responsibilities and review scope for the proposed output.
It identifies a claim to investigate. Confirm the proposed plan, environment, limitations and evidence for the tasks your users need.
No. Ask whether the work uses existing supported behavior or requires new code and a separate delivery obligation. Record the distinction in the proposal.
No. Keep it as future intention unless a separately agreed delivery scope, evidence and acceptance condition change its status.