Turn messy GTM calls into SOP updates and recurring checklists

Scope: Choose the meeting types that are eligible to feed the process system, such as sales handoffs, customer onboarding, implementation reviews, support escalations, postmortems, and recurring GTM operating reviews.

Set up: In Notion, create fields for Call Type, Business Process, Process Owner, Meeting Owner, Eligible for SOP Change, Eligible for Checklist Change, Required Approver, and Review SLA. Write inclusion rules based on whether the call can produce a repeatable decision, operating constraint, failure pattern, control requirement, or handoff change.

Build: Write exclusions for routine status updates, one-off customer preferences, unverified opinions, confidential discussions that cannot be documented, and decisions outside the meeting participants' authority. Assign one accountable process owner for every included call type so proposed changes do not sit unowned. Review the matrix with RevOps, Enablement, Customer Success, and any functional leaders whose procedures may be changed.

Output: Publish the approved intake rules in the process knowledge base before processing transcripts.

Capture: Document when Granola or Fathom may record or transcribe meetings and how participants are informed according to company policy and applicable consent requirements. In Notion, record Allowed Meeting Types, Consent Method, Restricted Topics, Transcript Access Group, Storage Location, Retention Period, Redaction Owner, and Deletion Process.

Guardrails: Exclude or redact credentials, sensitive personal information, medical or financial details, confidential customer data, legal advice, and unrelated employee performance discussions before process analysis. Define which links may be stored in a broadly accessible SOP and which evidence must remain in a restricted workspace.

Exceptions: Limit transcript access to the people who need to review the change and use summaries or approved excerpts for wider communication. Assign an owner for responding to access, correction, and deletion requests.

Approval: Obtain approval from the relevant privacy, legal, security, or operations owner before the workflow goes live.

Set up: Create one reusable meeting template in Granola and Fathom for every eligible call type. Include Meeting ID, Date, Call Type, Process Area, Facilitator, Participants, Decisions, Decision Owner, Action Items, Unanswered Questions, Exceptions, Customer or Team Impact, and Potential Process Change.

Configuration: Add a required manual field called `Process change hypothesis` that the meeting owner completes in one or two sentences after the call.

Set up: Add another field called `Evidence confidence` with High, Medium, Low, or No Change so uncertain observations are not presented as approved facts. Configure the meeting owner to check names, decisions, dates, and action owners before the transcript enters the process queue.

Approval: Store the approved template link and completion instructions in Notion. Test the template on one representative meeting and revise any field that people cannot complete consistently.

Scope: At the end of an eligible call, restate any operating decision, exception, or repeated failure pattern so participants can correct it while context is fresh. The meeting owner should identify whether the discussion represents a new rule, a clarification of an existing rule, a temporary exception, a training gap, a tooling issue, or no process change.

Action: In Granola or Fathom, mark the timestamp or note section that supports each proposed change and identify who had authority to make the decision. Capture unresolved disagreement separately rather than writing a false consensus into the summary.

QA: Confirm the action owner, expected due date, and whether the current process remains in force until approval.

Review: Complete the `Process change hypothesis` and `Evidence confidence` fields within one business day. Send the meeting into the intake queue only after these checks are complete.

Set up: Create one Notion intake record for each proposed change using a stable Change ID rather than editing the live SOP immediately.

Configuration: Add Source Meeting, Call Type, Process Area, Change Type, Current Process Link, Proposed Outcome, Evidence Excerpt, Evidence Confidence, Requester, Process Owner, Approver, Risk Level, Status, and Target Review Date. Search the change log for the same process, customer issue, checklist step, or decision before creating a new record.

Action: Link related requests and consolidate duplicates while retaining each source meeting as evidence. Route unclear ownership to RevOps or the operating-system owner instead of guessing.

Output: Mark incomplete records as Needs Evidence and return them to the meeting owner with the missing field. Keep the intake database separate from published SOPs and live Manifestly checklists.

QA: Review the intake record and classify the output as SOP Update, Manifestly Checklist Update, Onboarding Note, FAQ, Enablement Note, Escalation Rule, Tool Configuration Change, Training Need, Temporary Exception, or No Process Change.

Scope: Assign a risk level based on customer impact, financial or legal impact, reversibility, number of teams affected, automation involved, and whether the change alters a control or approval.

Requirements: Define the minimum approvers for low, medium, and high-risk updates in the Notion template. Route tooling defects and data-quality problems to their operational owner rather than rewriting a checklist to work around them permanently.

Next action: Mark one-off customer accommodations as exceptions with expiration dates rather than global process changes. State the exact artifact or artifacts that must change and the employees or roles affected. Reject or defer requests that lack authority, evidence, repeatability, or a clear operational outcome.

Set up: Open the current Notion SOP and any connected Manifestly checklist and identify the exact section, step, role, dependency, form, template, or approval affected by the request.

Capture: Record the current wording, current owner, current version, effective date, downstream references, and known exceptions in the intake record. Check whether the current process is wrong, incomplete, ambiguous, outdated, or simply not followed.

QA: Review linked onboarding material, enablement notes, and recurring checklists so one change does not create conflicting instructions. Identify dependencies such as automation, CRM fields, access permissions, customer communication, or another team's handoff.

Output: Define what must remain unchanged to protect controls and continuity. Save a current-state snapshot or version link before drafting the proposed state.

Set up: Create a staging copy or draft section in Notion rather than editing the published SOP.

Build: Write the purpose, trigger, owner, prerequisites, inputs, actions, decisions, handoffs, exceptions, escalation path, required evidence, and completion definition for the proposed procedure. In Manifestly, draft each checklist item as one observable action beginning with a verb and include the responsible role, due timing, required field or attachment, conditional logic, and completion evidence.

Action: Separate policy, explanation, and examples from executable checklist actions so operators can scan the live work. Include an effective date, Change ID, version note, source meeting, and rollback condition.

QA: Highlight every changed or new section in a side-by-side review block. Verify that a new team member could execute the draft without relying on private context from the original call.

Scope: Select one person who performs the process and one downstream recipient of its output to review the staged change. Ask the executor to walk through a realistic example using the proposed SOP and checklist without verbal coaching from the author.

Capture: Record missing inputs, unclear ownership, hidden knowledge, impossible deadlines, duplicate work, ambiguous completion criteria, and handoff gaps in the intake record.

QA: Verify that required tools, permissions, templates, and data are available to the assigned role. Test at least one normal case and one exception or failure case.

Next action: Revise the draft and rerun any step that changed materially. Mark Operational Walkthrough Passed only when the executor and downstream recipient agree that the procedure is feasible and produces the required output.

Action: Send a structured Slack approval request containing the Change ID, business reason, source meeting, current-state problem, proposed operational change, affected teams, risk level, walkthrough result, effective date, and links to the staged diff. Require the designated approver to choose Approved, Approved with Edits, Rejected, Deferred, Needs More Evidence, or Temporary Exception.

Capture: Capture the decision, approver, date, rationale, required edits, and expiration date in Notion rather than treating a Slack reaction as approval. For medium or high-risk changes, require all approvers defined by the risk matrix before publication.

Action: Escalate overdue decisions according to the review SLA but keep the current process in force until approval is complete. If the change is rejected, preserve the draft and rationale in the change log.

Approval: Re-run the operational walkthrough when an approval edit changes execution, ownership, timing, or controls.

Scope: Merge the approved wording into the live Notion SOP and retain the prior version or archive link.

Set up: Add Version, Effective Date, Change ID, Process Owner, Approvers, Source Evidence Link, Affected Roles, Training Required, and Rollback Trigger to the page history. Update links from onboarding pages, enablement documents, FAQs, forms, and templates that reference the changed section.

Action: Remove or clearly label superseded instructions so employees do not encounter two active versions. Restrict editing permissions to the designated owners while preserving team read access.

Output: Verify every internal link and embedded template after publication. Record the publication timestamp and final live URL in the change intake record.

Scope: Update the live Manifestly checklist only after the corresponding SOP version is published.

Set up: Configure the checklist title, version, trigger, recurrence, responsible roles, due dates, conditional steps, required comments or attachments, approval gates, and escalation rules.

Action: Link each checklist section to the relevant SOP section rather than copying long policy explanations into the task. Preserve a duplicate or export of the prior checklist version so the change can be rolled back.

Output: Test assignment, permissions, notifications, conditional paths, completion evidence, and overdue behavior with a non-production run. Confirm that integrations or recurring schedules do not create duplicate active checklist runs. Record the deployed checklist version and test evidence in the Notion change record.

Action: Send a Slack change notice that states what changed, why it changed, who is affected, when it becomes effective, what action is required, and where the live SOP and checklist are located. Use a targeted channel or user group rather than announcing every change to the entire company. For material changes, provide a short example, before-and-after summary, or live walkthrough and record attendance or acknowledgment.

Next action: Ask managers to confirm that affected users have the required access, templates, and context before the effective date.

Set up: Create a feedback route for questions and edge cases and identify who will answer them. Keep temporary exceptions and transition instructions visible until the old process is retired.

Output: Save the notice link, training evidence, and readiness status in the change record.

Action: Run the updated process with a limited team, customer segment, or checklist cycle when the risk or scope justifies a pilot.

Next action: In Manifestly, monitor assignment success, completion rate, skipped steps, late tasks, comments, attachments, approvals, escalations, and exceptions. Compare the output with the acceptance criteria defined in the change request rather than judging only whether the checklist was completed.

Action: Ask executors and downstream recipients whether the change reduced ambiguity, rework, delays, or errors. Pause or roll back when the new process creates customer risk, duplicate work, broken handoffs, missing evidence, or an unmanageable exception rate.

Output: Record pilot size, observation window, issues, corrective actions, and the go-forward decision in Notion. Close the change only after the owner confirms that the process performs as intended.

Scope: Each month, review Manifestly completion, skips, overdue tasks, reassignments, exceptions, approval delays, and repeated comments by checklist version.

Action: In Notion, review open, rejected, deferred, rolled-back, and duplicate change requests to identify process areas producing noise or unresolved risk.

Next action: Separate problems caused by unclear documentation from problems caused by training, staffing, tooling, incentives, or unrealistic policy. Rewrite or remove checklist steps that are repeatedly skipped because they are unnecessary, impossible, duplicated, or poorly defined.

Output: Update the eligible-call matrix when certain meeting types produce little value or repeatedly create unsupported requests. Share a short operating review with process owners showing adopted changes, failed changes, recurring gaps, and next actions. Preserve the monthly decisions in the process change log so the operating system improves without accumulating documentation bloat.