Live transcript
Recent transcript segments appear in the recording overlay so the user can confirm that transcription is progressing.
Processing occurs on the desktop.Product workflow
What would employees actually use?
A Windows desktop workflow for recording meetings, following a live local transcript, and reviewing AI-generated summaries.
Does it require a meeting bot or a new conferencing platform?
Users join their meetings normally, then record from Wislab Desktop.
Wislab captures microphone audio on the user’s Windows device and can include meeting-output audio when system loopback capture is available. It does not join the call as a participant, and it does not replace Zoom, Microsoft Teams, Google Meet, Webex, or another meeting application.
1
Choose a meeting
Start an ad-hoc recording or select an upcoming Google or Microsoft calendar meeting shown in the desktop application.
2
Confirm participant notice
The recording flow reminds the user to notify meeting participants before capture begins.
3
Record from the desktop overlay
The compact recording window shows capture status, elapsed time, and the developing transcript.
4
Finish or discard
Finishing saves the local recording and transcript. Discarding removes the in-progress capture without creating a meeting record.
Current scope
The packaged desktop application is currently built for Windows. macOS and Linux desktop applications are not presented as available products.
Where does speech become text?
Transcription runs locally while the meeting is being recorded.
A speech model on the user’s device processes captured audio and updates the live transcript. When recording ends, the transcript is finalized and stored in the desktop database alongside the local recording.
Saved transcript
The completed transcript includes timed text segments and can be reviewed or exported from the meeting detail view.
Stored with the local meeting record.Accuracy
Transcription quality depends on audio quality, speaker clarity, device resources, and the local speech model. A pilot should test representative meeting conditions rather than assume uniform accuracy.
What does the AI produce, and where is it produced?
The configured processing server turns transcript text into a structured meeting summary.
After local transcription finishes, the desktop sends transcript text to the processing server your organization operates. The server generates the result and returns it to the desktop.
Summary
A condensed account of the discussion, organized into readable sections.
Section-based format
The summary uses fixed sections so reviewers can scan overview, decisions, and key topics in a consistent layout.
Decision-oriented output
Decisions can be identified when the transcript contains a clear decision.
Copy and export
Users can copy summary text or export the summary and transcript from the desktop.
- Sent to the processing server
- Transcript text, optional timing segments, and meeting identifiers used by the workflow
- Not sent by the summary endpoint
- The meeting audio file
- Returned to the desktop
- Job status and the completed structured summary
- Stored locally
- Recording metadata, transcript, summary, and the local audio file path
How do users return to a meeting after it ends?
Recordings, transcripts, and summaries are organized in the desktop workspace.
Users can open a past meeting, switch between summary and transcript views, rename or delete the meeting, copy the summary, and export available outputs.
Find the meeting
Browse the meeting list or search by meeting title.
Review the result
Open the summary or the timed transcript in the meeting detail view.
Use the output
Copy summary text or export a transcript or summary file.
Manage local history
Rename a record or delete its local audio, transcript, and summary.
Search scope
The current desktop search filters meetings by title. The site does not claim semantic search, organization-wide knowledge retrieval, or transcript-content search.
What components would our team need to operate?
Three components have distinct responsibilities.
The desktop handles capture and local transcription. The Portal handles user sign-in. The processing server handles summary generation and optional collaboration workflows.
Wislab Desktop
- Windows meeting capture
- Live local transcription
- Local audio and meeting history
- Calendar meeting display
Account Portal
- Browser-based sign-in
- Desktop access and refresh tokens
- Portal account services
Processing server
- Authenticated transcript intake
- Summary job processing
- Session and consent data when enabled
- Server-side job storage
What should we not assume is included?
Current product scope, stated plainly.
A credible evaluation needs clear boundaries. These are capabilities the website does not present as part of the current product.
No meeting bot
The product records from the desktop; it does not join calls as an automated participant.
No macOS or Linux desktop release
The current packaged desktop product and installer are for Windows.
No claimed enterprise RBAC
The website does not promise organization-wide roles or granular meeting permissions that are not implemented.
No semantic knowledge platform claim
The current library supports local meeting history and title search, not a company-wide semantic search service.
No automatic task-system integration
Automatic synchronization to external task tools is not claimed.
No Wislab-hosted inference claim
The current deployment model requires a processing server configured and operated for the organization.
Would this workflow fit a representative team?
A pilot can test capture, local transcription, summary quality, server operations, and user adoption with real meeting conditions.