Program / operations
Own workflow fit, user outcomes, service levels, operational constraints, and acceptance of business behavior.
Seven-stage decision path
Free • No account
A procurement path that produces evidence—not just meetings and demos.
Use this toolkit to move from an unclear technology problem to documented requirements, comparable vendor evidence, an explainable selection, a controlled migration, and a credible exit path. Each stage links to a free Zeph Tech resource built for a specific decision.
The toolkit is product-neutral. It does not require ZephCMS and does not collect contact information to use the decision resources.
- DefineDocument the problem, users, information, constraints, and outcome.
- RequestTurn the definition into requirements and comparable evidence requests.
- ValidateTest material security, accessibility, operational, and migration claims.
- DecideKeep scoring, exceptions, acceptance, and exit conditions explainable.
Seven-stage procurement path
Use the right resource when its evidence can still change the decision.
The sequence is intentionally not “RFP, demos, score, contract.” It starts earlier with operating context and continues later through migration and exit so the organization keeps leverage over the full lifecycle.
- 01
Define the operating problem.
Capture current workflow, users, information sensitivity, desired outcomes, dependencies, constraints, and decision horizon before naming a preferred platform.
- 02
Write comparable requirements.
Translate the operating problem into requirement language and explicit evidence requests across workflow, security, privacy, records, migration, accessibility, delivery, reliability, and commercial exit.
- 03
Validate vendor security evidence.
Ask how identity, data protection, development, infrastructure, detection, vulnerability handling, incident response, third parties, assurance, and exit are actually implemented and evidenced.
- 04
Validate accessibility evidence.
Scope users and workflows, evaluate ACR/VPAT material, test representative interactions and outputs, and make remediation and retesting part of acceptance rather than an afterthought.
- 05
Score the decision transparently.
Compare options through the same weighted criteria and evidence model while keeping mandatory legal, security, accessibility, data, and operational failures outside a misleading aggregate score.
- 06
Prove migration readiness.
Inventory data, files, relationships, access, integrations, validation, cutover, rollback, recovery, exceptions, and acceptance evidence before production depends on the target.
- 07
Preserve continuity and exit options.
Confirm contract rights, data portability, configuration, identity transition, continuity, coexistence, deletion, and closure evidence while the organization still has leverage to require them.
Evidence chain
Every stage should leave behind something the next stage can inspect.
A decision is easier to defend when its artifacts form a traceable chain instead of living in separate email threads, vendor demos, and meeting notes.
- 1
- Context. A documented operating problem, user population, information boundary, priorities, constraints, dependencies, and decision horizon.
- 2
- Requirements. Requirement statements linked to the outcome or risk they address and the evidence expected from each bidder.
- 3
- Claims. Vendor responses, architecture material, reports, demonstrations, test evidence, exceptions, limitations, and remediation commitments.
- 4
- Evaluation. Scores and decisions that point back to evidence, including explicit treatment of mandatory requirements and unresolved risks.
- 5
- Acceptance. Migration reconciliation, security/access validation, accessibility testing, operational readiness, rollback, exceptions, and named approval.
- 6
- Lifecycle. Renewal, change, regression, portability, transition, deletion, and closure evidence that keeps the original decision from becoming permanent by accident.
Use the procurement decision-record workbook to keep the chain in one traceable register
Decision gates
Some failures should stop the process rather than lower a weighted score.
A polished demo can produce momentum that hides unresolved requirements. Define the conditions that require remediation, formal exception, or rejection before evaluation begins.
- Legal and records gate. Required legal, records, privacy, accessibility, and jurisdictional obligations should not disappear inside a composite score.
- Security gate. Critical identity, data protection, incident, vulnerability, or assurance gaps need explicit disposition and authority.
- Migration gate. Unresolved source inventory, file integrity, relationship mapping, validation, rollback, or recovery issues should block production cutover when material.
- Exit gate. Unacceptable ownership, portability, transition, deletion, or closure terms should be negotiated before dependence removes leverage.
Decision ownership
Procurement is stronger when each evidence type has a named reviewer.
One person should not be expected to validate every domain. Assign ownership before responses arrive so important evidence does not become “someone else’s section.”
Procurement / legal
Own solicitation structure, contract terms, renewals, exit assistance, risk language, and commercial comparability.
Security / privacy
Own material control evidence, identity, data handling, incident readiness, third-party risk, and required assurance.
Accessibility
Own applicability, ACR/VPAT review, workflow testing, defect disposition, remediation expectations, and retest triggers.
Data / records
Own source inventory, retention, metadata, relationships, export, reconciliation, preservation, and deletion obligations.
Architecture / integration
Own interfaces, identity federation, dependencies, configuration, migration design, recovery, and coexistence.
Decision authority
Own exceptions, mandatory gates, risk acceptance, final selection, production acceptance, and lifecycle accountability.
After award
Turn procurement claims into implementation and production gates.
The award decision selects a supplier; it does not prove the configured service works in the buyer's environment. Carry every material unresolved claim forward as a named acceptance criterion instead of allowing it to disappear at contract signature.
Implementation-baseline gate
Before configuration and migration dates become commitments, confirm the authoritative requirements baseline, named business and technical owners, environments, integration dependencies, identity model, migration scope, data handling, accessibility scenarios, security responsibilities, training assumptions, support routing, rollback expectations, and unresolved procurement conditions.
A condition is ready to carry forward only when it has an owner, evidence type, test point, due date or trigger, and a defined consequence if it fails.
Migration-acceptance gate
Do not reduce migration acceptance to record counts. Reconcile representative records, metadata, relationships, attachments, dates, identities, permissions, retained history, exception handling, and integrations. Sampling should target difficult and high-consequence cases rather than only clean examples.
When reconciliation thresholds are used, define them before the final cutover and state which classes of mismatch are never acceptable regardless of percentage.
Production-readiness gate
Require representative workflow UAT, defect disposition, role and privileged-access validation, monitoring, backup and restore evidence, incident contacts, support ownership, runbooks, training readiness, accessibility acceptance, migration reconciliation, and explicit business approval. A launch with open material risk should identify who accepted it and under what conditions.
“The project is on schedule” is not production evidence. The gate should answer whether users can perform the work safely and whether operations can detect, support, recover, and govern the service.
Early-life operating review
After the first meaningful operating cycle, compare procurement and implementation assumptions with production evidence. Review failed workflows, workarounds, support volume, response times, recurring defects, administrative effort, accessibility issues, performance, integration failures, security findings, training gaps, and unexpected vendor dependencies.
Material variance should become owned remediation, contract enforcement, a changed operating procedure, or an explicit risk decision—not institutional memory.
Use the same decision vocabulary all the way through.
Keep dispositions small and explicit: pass, remediate, accept with conditions, defer to a named gate, reject, hold launch, or escalate. For exceptions, record the consequence, compensating control, approval authority, expiration or event trigger, and closure evidence. This makes the procurement record usable during implementation, renewal, audit, incident review, and eventual exit.
Use the toolkit
Start with the stage that is still changeable.
If a solicitation has not been written, begin with the evaluation brief. If bids are already arriving, focus on security and accessibility evidence before scoring. If selection is complete, move quickly into migration and acceptance. If a platform is already entrenched, use the continuity and exit worksheet before renewal.