Workflow fit
Can the intended users reliably record and finish representative meetings?
Technical pilot framework
How would we evaluate Wislab responsibly?
Start with architecture fit, deploy a bounded environment, test representative meetings, and finish with an evidence-based rollout decision.
For the limited Founding Design Partner Program, see how Wislab works with five organizations during initial rollout.
What question should the pilot answer?
Whether the current product creates enough value to justify its deployment model.
A pilot should test the complete system: Windows capture, local transcription, summary quality, processing-server operations, user workflow, and security-review findings.
Output usefulness
Do transcripts and summaries reduce review effort or improve follow-through?
Architecture fit
Does the data flow satisfy the requirement that motivated an organization-operated server?
Operating fit
Can the organization support endpoints, server availability, models, storage, and updates?
What must be ready before users start?
A bounded pilot still needs production-minded foundations.
The exact topology is agreed during technical review. These are the current product dependencies—not a generic cloud trial checklist.
- Pilot endpoints
- Windows computers able to run Wislab Desktop and the local speech model, with permission to capture meeting audio
- Processing host
- A Python-compatible server operated by your organization with resources for the configured summary model
- Model dependencies
- The required speech-model files on each desktop and a configured language-model path on the processing host
- Network path
- Desktop reachability to the processing API; HTTPS should be used outside isolated development or lab environments
- Authentication
- Portal sign-in plus processing-server JWT validation aligned to the Portal issuer and audience
- Storage
- Capacity and retention decisions for local audio, desktop databases, and processing-server job data
- Calendar integration
- Optional Google or Microsoft read-only calendar connection when calendar-linked workflows are in scope
- Pilot ownership
- A business sponsor, technical owner, security reviewer, and a small group of representative Windows users
Readiness gate
A pilot should not begin until server ownership, endpoint scope, network access, meeting-consent policy, and success measures have named owners.
What happens from first call to pilot decision?
A staged evaluation reduces uncertainty before broader deployment.
Duration is agreed after technical review because server readiness, security review, user count, and calendar or consent scope can materially change the schedule. Wislab does not promise a fixed pilot duration before those facts are known.
Discovery
Define the decision the pilot must support and confirm that the current product scope matches it.
- Users and meeting types
- Expected business outcome
- Architecture and policy constraints
- Out-of-scope requirements
Architecture review
Map the desktop, Portal, processing server, network path, identity configuration, and retention responsibilities.
- Server and model requirements
- JWT configuration
- HTTPS and network placement
- Endpoint and storage controls
Environment setup
Bring up the processing service, configure pilot desktops, verify sign-in, and run a non-sensitive technical test.
- Connectivity and authentication
- Local transcription readiness
- Summary job completion
- Logging and support path
Pilot operation
Selected users test agreed meeting scenarios while the technical owner tracks reliability and support effort.
- Capture completion rate
- Transcript and summary review
- User workflow feedback
- Server and endpoint observations
Completion decision
Compare measured results with the agreed criteria and document blockers, required changes, and operating implications.
- Proceed to rollout planning
- Extend a targeted test
- Pause for a product or infrastructure gap
- Conclude the model is not the right fit
How will we know whether the pilot succeeded?
Agree on observable measures before the first real meeting.
Targets should be set by your organization during planning. The categories below avoid presenting untested performance numbers as promises.
Completion
Share of intended meetings that produce a saved transcript and completed summary without manual recovery.
Usefulness
User rating of whether the transcript and summary reduce review time and preserve important outcomes.
Accuracy review
Observed transcript and summary errors across representative audio conditions and meeting types.
Operational load
Setup effort, support requests, server availability, processing time, and intervention required.
Architecture acceptance
Whether security and IT reviewers accept the documented data flow and assigned responsibilities.
User adoption
Whether pilot users can follow participant notice, recording, finish, review, and export workflows consistently.
Who is responsible for what during the pilot?
Support works best when product and infrastructure ownership are explicit.
Product guidance
Support the evaluation of the current desktop and processing-server workflow.
- Product walkthrough and workflow guidance
- Current deployment documentation
- Product-level troubleshooting
- Clarification of known scope and limitations
Environment operations
Own the systems, policies, and access required for the pilot environment.
- Processing host and network access
- Endpoint deployment and protection
- Secrets, backups, logs, and retention
- User selection, recording policy, and internal approvals
What happens when the pilot ends?
The result is a deployment decision, not an automatic sales handoff.
The closeout should state what worked, what did not, what broader operation would require, and whether the current product is ready for the intended scope.
Review evidence
Compare actual results with the agreed success measures and security findings.
Record gaps
Separate product gaps from infrastructure, policy, training, and support issues.
Define next scope
If proceeding, identify users, environments, owners, controls, and operational changes for rollout.
Make the decision
Proceed, extend narrowly, pause, or stop based on evidence—not sunk effort.
What would your pilot need to prove?
Start with the decision, representative users, and the processing environment your team can operate.