Evaluation Checklist
Define what ZENQIX must prove in your environment.
Write the acceptance criteria before the pilot, then record the evidence needed to pass each item.
How to use it
Set the rule before the test.
Give each important question an owner, evidence source and pass/fail condition. Use the capability matrix to keep pilot scope aligned with current product status.
Current stage
Private pilot / demo
This checklist does not expand availability. Capability status remains the authority for platform support.
01
Product truth
Required capabilities are mapped to Available, Preview, Planned or Not available status.
Platform-specific differences are understood before pilot scope is approved.
Preview capabilities have an agreed acceptance method rather than being treated as general availability.
02
Deployment & ownership
Endpoint count, operating systems and site/network constraints are documented.
Service ownership, backup responsibility and rollback ownership are assigned.
Required outbound connectivity, proxy and firewall constraints are understood.
Data-location and retention expectations are agreed for the pilot.
03
Endpoint evidence
Device identity remains stable and can be tied to the correct site or owner context.
Online/offline and last-seen state match known endpoint behavior.
Hardware, OS and supported software inventory can be compared with known facts.
Stale evidence can be distinguished from current observations.
04
Administrative control
Operator roles and tenant boundaries are explicit.
A requested action is distinguishable from dispatch, execution and verification.
Timeout, cancellation and duplicate behavior are understood for actions in scope.
Remote-support access is device scoped and has a clear session lifecycle where included.
05
Verification & audit
The pilot defines what observed state will prove success for each action in scope.
Verification mismatch remains visible rather than being converted into success.
Evidence identifies the finding, authorization, action, observation and final verification state.
Useful audit evidence is available without exposing credentials or secret material.
06
Operations & rollout
Upgrade and rollback procedures are understood before broadening the pilot.
Support escalation can include sanitized device/action evidence.
Known blockers and deferred platform work are recorded at pilot close.
A wider rollout is approved only against written acceptance criteria.
Evidence source
Record the product state, observation or test that proves each criterion.
Acceptance owner
Name who can accept the result: endpoint operations, infrastructure, security or support.
Exit decision
Finish with accepted outcomes, unresolved gaps and the conditions required for wider rollout.
Use the checklist with product evidence.
Review Product Proof, deployment architecture and the Buyer FAQ before finalizing pilot scope.