In Parallel treats meetings as execution events—because that’s where priorities shift, decisions get made, and ownership gets assigned. When you connect a recurring meeting to a scope, In Parallel can join automatically, capture execution signals, and keep the scope’s living plan current.
In this article
What happens when you connect a meeting
What In Parallel captures (and what it doesn’t)
How to use it without changing how you meet
Best practices for consent and trust
Common issues and fixes
What happens when a meeting is connected
When a recurring meeting is connected to an execution scope, In Parallel can:
join automatically
transcribe in real time
identify decisions, actions, risks, ownership shifts, unresolved topics
link those signals directly to the right scope
Those signals feed the core loop:
pre-read before the meeting
structured report after the meeting
execution plan update
snapshot created so “what changed” is explicit
What In Parallel captures (execution signals)
In Parallel is not trying to document everything. It listens for execution-relevant signals, including:
decisions (“we’re changing priority,” “we’re delaying launch,” “we’re doing A instead of B”)
action-worthy commitments (“Chris will follow up,” “we need to ship X by Friday”)
risks and dependencies (“blocked on API,” “waiting on Legal,” “depends on team Y”)
ownership changes (“this now belongs to…,” “we’ll have Pat own this”)
Crucially: these aren’t stored as raw “meeting notes.” They’re interpreted as signals tied to a scope’s plan.
What it doesn’t capture (and why)
To keep the system calm and trustworthy, In Parallel isn’t meant to preserve:
detailed brainstorming threads
every tangent or conversational nuance
long-form reasoning better captured in docs
granular task tracking that belongs in Jira/Asana/etc.
Think of it this way:
Conversation happens in the meeting.
Execution truth gets distilled into the plan.
Delivery detail stays in delivery tools.
How to use the meeting transcriber (without changing how you meet)
The best way to use In Parallel in meetings is to ignore it during the meeting.
Recommended workflow
Before the meeting: skim the pre-read (“what changed?”).
During the meeting: run it normally. Don’t tag moments, don’t narrate for the system.
After the meeting: review the report, confirm decisions and actions while context is fresh.
This keeps meetings natural and the system accurate.
Tip: Start every recurring meeting with one question: “What changed since last time?” The tool is built to make that effortless.
Consent and trust (how to do this well)
Meeting capture only works long-term if it’s trust-preserving.
Best practices
Make sure participants know the meeting is being transcribed.
Treat the post-meeting report as the “official output,” not the raw transcript.
Confirm what matters (decisions, actions, plan changes) — don’t let anything material become “truth” without review.
This aligns with the product’s core trust model: execution truth is maintained through signals + review, not silent automation.
Common issues (and fixes)
“The meeting didn’t get captured”
Most often:
the meeting wasn’t actually connected to the scope
it wasn’t part of a recurring series
the calendar connection isn’t enabled
Fix
confirm the recurring meeting is linked to the right scope
ensure calendar access is enabled
“The output missed an important decision”
This usually happens when:
the decision was implied but not stated clearly
it occurred outside the main meeting context
Fix
confirm the decision in the post-meeting report
if needed, add a short explicit decision note and link it to what changed
“People feel uncomfortable being recorded”
Fix
be explicit about consent expectations
use the report as the artifact, not transcripts
keep scopes membership/visibility intentional
Related articles
Before & after meetings: pre-reads and reports
Understand the living execution plan
What are snapshots?
Actions and ownership (how tasks work)
Privacy, security & trust