Scribe turns meeting audio and video into structured business documentation. It identifies requirements, decisions, actions, processes, owners, risks and dependencies within the conversation, then organizes them into useful documents. SOPs, business requirements documents and project charters give that information a working form, rather than leaving teams with another recording or transcript to interpret.
03 / THE PROBLEM
Meetings contain more than notes.
A transcript preserves what was said, but not necessarily what matters. Requirements can be scattered across an hour of conversation, decisions can depend on earlier context, and actions can have owners without a clear structure. Turning those details into a business requirements document, SOP or project charter still requires someone to understand, organize and rewrite them.
04 / Defining the product
Find the meaning before giving it form.
I separated the work into understanding the conversation, identifying meaningful information and building a structure for the intended document. A decision, a requirement and an action may appear in the same discussion, but they serve different purposes. Those distinctions need to survive the transformation from meeting content to working documentation.
01Capture meaning, not just words
Identify decisions, requirements, actions, processes, owners, risks and dependencies as distinct information, rather than treating every passage as material for a summary.
02Keep context attached
Ownership, dependencies and the context around a decision remain useful when the information moves out of the transcript and into a document.
03Structure before generating
Organize the information for the intended output, then generate a document that a person can review, edit and refine.
05 / Designing the system
From conversation to working knowledge.
Audio and video become a transcript, then extraction and classification identify the information that matters. Structure connects that information to the needs of a business document before generation begins. Human review follows, with an editable output rather than a final answer that assumes the conversation supplied every detail correctly.
01Audio + transcript
02Extraction
03Classification
04Structure
05Document generation
06Review
Raw conversation → meaningful information → structure → business document
06 / Key product challenges
The decisions that shaped the product.
One conversation, several document purposes.
01The thinking
A summary organizes a meeting around what was discussed. A business document organizes information around what people need to do with it. Using the same outline for every output would preserve words while losing that purpose.
02The decision
Separate meaningful information from the final document structure. Requirements, decisions, owners and dependencies are organized for the chosen output before the wording is generated.
03The result
The information model supports different document purposes while keeping review focused on the meaning that needs to survive the transformation.
07 / The solution
Give the conversation a useful working form.
JOURNEY 01
A good summary isn’t a good BRD.
The output’s purpose determines what the conversation needs to become. A person choosing a BRD, SOP or project charter is choosing an information structure, not just a different format for the same summary.
01Business requirements document
Organize requirements with their context and dependencies. Decisions and unresolved questions need to remain distinguishable so a discussion does not become a falsely settled requirement.
02Standard operating procedure
Organize process information into an actionable sequence, keeping the relevant roles and responsibilities attached to the work.
03Project charter
Bring scope, ownership, risks and dependencies into a shared project context. The structure should expose what the conversation established and what still needs clarification.
JOURNEY 02
Refine the output, keep the meaning.
A generated document is a working draft. The reviewer checks requirements, decisions and ownership, resolves ambiguity, then refines the output into something the team can use. Structured information makes that review more specific than rewriting a broad summary.
01Check the meaning
02Resolve ambiguity
03Refine the draft
04Use the document
Review journey / generation does not settle unresolved decisions
01Missing ownership or conflicting statements
A review needs to make incomplete information visible rather than fill it with plausible wording. An unassigned action or conflicting requirement remains a clarification task for the team.
08 / Outcome & impact
An information model before a generated document.
My design contribution was separating meeting understanding, meaningful information, document structure and review. That distinction lets a BRD preserve requirements, an SOP preserve a process and a charter preserve project context. The review journey keeps ambiguity and missing ownership visible, so a polished draft does not turn an unresolved discussion into an apparently settled decision.
01Documents with a purpose
SOPs, business requirements documents, project charters and process documentation call for different structures, even when they draw from the same meeting.
02What I learned
Structuring information is often the difficult part of document generation. The final wording only becomes useful when requirements, decisions and ownership are understood in relation to one another. Designing that transformation made me think more carefully about the information a document needs before thinking about its format.
09 / Success criteria
Success criteria: measure useful documents, not generated words.
Evaluate each document against its source conversation and intended use. Quality depends on preserved meaning and the review effort needed to make the draft usable.
Meaning preserved
≥95%
Requirements, decisions, actions and owners represented accurately against the source conversation.
Unsupported content
0
Statements or assignments added without support in the conversation. Missing information remains open for clarification.
Time to usable output
≤5 min
Median review and editing time to reach a usable BRD, SOP or project charter after generation.