C
Docs

Review Gates

Configure approval workflows for quality control and governance

Updated 2026-03-3016 min read

Implement approval workflows to ensure lesson quality, validate insights, and maintain organizational standards.

Overview

Review gates add an approval layer between lesson creation and publication. Designated reviewers validate that lessons are accurate, actionable, and meet quality standards before they're shared with the team.

Note

Review gates are optional. Small teams (< 10 people) often publish lessons immediately. Larger organizations (> 20 people) typically use review gates for quality control and to prevent misinformation.

Why Use Review Gates?

Quality Assurance

Ensure lessons are:

  • Accurate (facts are correct, not based on assumptions)
  • Complete (sufficient context and detail)
  • Actionable (clear recommendations, not vague observations)
  • Well-written (clear, concise, professional)

Knowledge Validation

Subject matter experts verify:

  • Technical accuracy
  • Appropriate conclusions
  • Realistic recommendations
  • No gaps in analysis

Risk Management

Prevent issues:

  • Confidential information disclosure
  • Inaccurate information spreading
  • Blame culture (lessons focused on process, not people)
  • Premature conclusions (lessons created before full information available)

Consistency

Maintain standards:

  • Consistent lesson format and structure
  • Appropriate categorization and tagging
  • Alignment with organizational values
  • Professional tone and language

When to Use Review Gates

Organizations That Benefit

Large teams (20+ people): Review gates prevent knowledge base clutter and ensure quality at scale.

Highly regulated industries: Lessons may contain sensitive information requiring compliance review.

Distributed teams: Reviewers ensure lessons are understandable to team members who weren't involved in the bid.

Quality-focused cultures: Organizations that prioritize knowledge excellence over volume.

Organizations That May Not Need Them

Small teams (< 10 people): Everyone already knows each other and the context—formal review adds overhead without value.

High-trust cultures: Team members self-regulate quality without formal gates.

Fast-paced environments: Speed of knowledge sharing is more important than formal validation.

Pilot programs: When first starting lessons learned, keep it simple—add review gates later if quality issues emerge.

Configuring Review Gates

Accessing Settings

Navigate to SettingsLessons LearnedReview Gates

Basic Configuration

Enable Review Gates: Toggle Require Review Before Publishing to ON.

Set Default Reviewers: Choose who reviews lessons by default:

  • Department Managers - Lessons reviewed by author's manager
  • Knowledge Champions - Designated reviewers per department
  • Bid Managers - Senior bid managers review all lessons
  • Custom - Author selects reviewer when submitting

Review SLA (Service Level Agreement): Set expected review turnaround time:

  • 24 hours
  • 48 hours
  • 1 week
  • 2 weeks

What happens if SLA is exceeded:

  • Auto-approve - Lesson automatically publishes after SLA expires
  • Escalate - Notification sent to reviewer's manager
  • Extend - Reviewer can request SLA extension with justification

Advanced Configuration

Multi-stage review: Require multiple approvals before publishing.

Example workflow:

  1. Author submits → 2. Technical reviewer validates → 3. Manager approves → 4. Published

Conditional review: Apply different review requirements based on lesson characteristics:

ConditionReview RequirementReason
High-value bids (> $5M)Two-stage reviewHigh stakes warrant extra validation
Loss lessonsManager reviewEnsure blame-free, constructive tone
Contains attachmentsSecurity reviewCheck for confidential information
Technical categorySME reviewValidate technical accuracy
Process changesOperations manager reviewAlign with organizational practices

Configure conditions: Click Add Conditional Rule → Set condition → Choose review workflow

Reviewer pools: Create pools of qualified reviewers who rotate:

Example pools:

  • Technical Reviewers - Solutions architects, technical leads
  • Bid Management Reviewers - Senior bid managers, proposal managers
  • Executive Reviewers - Directors, VPs for high-value or sensitive lessons

Assignment logic:

  • Round-robin (distribute evenly)
  • Least busy (assign to reviewer with fewest pending)
  • Random
  • Author's choice (from pool)

Notification Settings

Reviewer notifications:

When a lesson is submitted for review, notify:

  • Assigned reviewer (always)
  • Reviewer's manager (optional)
  • Knowledge management team (optional)

Frequency:

  • Immediate (real-time notification)
  • Daily digest (morning summary of pending reviews)

Reminders: Send reminder notifications:

  • 50% of SLA elapsed (e.g., at 24 hours for 48-hour SLA)
  • 80% of SLA elapsed (e.g., at 38 hours for 48-hour SLA)
  • SLA exceeded (daily reminders until reviewed)

Author notifications:

Notify author when:

  • Lesson submitted successfully
  • Reviewer assigned
  • Reviewer requests changes
  • Lesson approved
  • Lesson rejected
  • SLA exceeded (if auto-approve is disabled)

Review Workflow

For Authors

For Reviewers

Review Actions

Approve:

  • Lesson meets quality standards
  • Published immediately (or sent to next review stage if multi-stage)
  • Author is notified of approval

Request Changes:

  • Lesson has value but needs revision
  • Author receives specific feedback on what to change
  • Lesson returns to author for editing
  • Once edited, author resubmits for review

Reject:

  • Lesson does not meet standards and cannot be salvaged with edits
  • Or: Lesson contains inappropriate content
  • Lesson is not published
  • Author receives explanation
  • Author can appeal rejection to knowledge management team or admin

Request Extension:

  • Reviewer needs more time (conflicts, need to verify facts, complex lesson)
  • Extends review SLA by specified period
  • Notifications adjusted accordingly

Reassign:

  • Reviewer determines someone else is better suited to review this lesson
  • Selects new reviewer from pool
  • New reviewer is notified

Review Criteria

Quality Checklist

Reviewers should verify:

Accuracy:

  • Facts are correct (names, dates, contract values, outcomes)
  • Conclusions are supported by evidence
  • No speculation presented as fact

Completeness:

  • Sufficient context (what, when, who, why)
  • Root cause analysis (not just surface-level description)
  • Clear recommendations (what should be done differently)

Clarity:

  • Title is descriptive and searchable
  • Lesson is well-organized and easy to follow
  • Writing is clear, concise, professional
  • No jargon without explanation

Actionability:

  • Recommendations are specific, not vague
  • Action items (if any) are well-defined with owners and deadlines
  • Future team members can apply these insights

Categorization:

  • Category (Win/Loss/Process/Technical) is appropriate
  • Tags are relevant and follow organizational taxonomy
  • Linked to appropriate bid or opportunity

Tone:

  • Constructive, not blaming individuals
  • Focuses on process failures, not personal failures
  • Professional and objective

Confidentiality:

  • No sensitive client information disclosed inappropriately
  • Contract details are appropriate to share internally
  • Attachments don't contain confidential or proprietary information

Common Issues to Flag

Request changes when:

Too vague: "We need better communication" → Request specific examples and recommendations

Blame-focused: "John didn't deliver on time" → Request reframing to focus on process (e.g., "SME deliverables delayed due to unclear requirements")

Missing context: Lessons that assume reader knows the background → Request adding context for team members who weren't involved

Inaccurate: Facts that don't match the debrief notes or bid records → Request verification or correction

No actionable takeaway: Long description with no clear "what should we do differently" → Request adding specific recommendations

Inappropriate category: Lesson tagged as "Win" but describes a loss, or vice versa → Request recategorization

Reject when:

Completely inappropriate: Lessons that violate company values, are disrespectful, or unprofessional

Confidential breach: Lessons that disclose information that should not be shared (even internally)

Duplicate: Lesson that substantially duplicates an existing lesson → Link to existing lesson and reject

Not actually a lesson: Content that's a complaint, vent, or personal opinion without constructive insights

Multi-Stage Review Workflows

For high-stakes or sensitive lessons, configure multi-stage review:

Example 1: Two-Stage Review

Stage 1: Technical Validation

  • Reviewer: Subject matter expert in the relevant domain
  • Focus: Technical accuracy, feasibility of recommendations
  • Outcome: Approve → Stage 2, Request Changes → Author, Reject → Rejected

Stage 2: Management Approval

  • Reviewer: Department manager or bid manager
  • Focus: Strategic alignment, organizational impact, tone
  • Outcome: Approve → Published, Request Changes → Author (then restart at Stage 1), Reject → Rejected

When to use:

  • Technical lessons that require expert validation
  • Lessons proposing significant process changes
  • Lessons from high-value bids (> $5M)

Example 2: Three-Stage Review

Stage 1: Peer Review

  • Reviewer: Another bid manager or team member
  • Focus: Basic quality, clarity, completeness
  • Outcome: Approve → Stage 2, Request Changes → Author

Stage 2: Subject Matter Expert

  • Reviewer: Expert in the relevant domain (pricing, technical, etc.)
  • Focus: Accuracy and appropriateness of recommendations
  • Outcome: Approve → Stage 3, Request Changes → Author (restarts at Stage 1)

Stage 3: Executive Approval

  • Reviewer: Director or VP
  • Focus: Strategic implications, organizational readiness
  • Outcome: Approve → Published, Request Changes → Author (restarts at Stage 1), Reject → Rejected

When to use:

  • Very high-value bids (> $10M)
  • Lessons proposing major organizational changes
  • Politically sensitive lessons (e.g., repeated failures with a key client)

Configuring Multi-Stage

SettingsLessons LearnedReview GatesMulti-Stage Review

  1. Click Enable Multi-Stage Review
  2. Click Add Stage
  3. Define stage name, reviewer role/pool, focus areas
  4. Set stage-specific SLA
  5. Define transition rules (what happens on approve, reject, request changes)
  6. Repeat for each stage
  7. Save workflow

Apply workflow:

  • As default for all lessons
  • Conditionally based on lesson characteristics
  • Author selects workflow at submission time

Review Analytics

Track review process health:

Review Metrics

Access: SettingsLessons LearnedReview Analytics

Metrics tracked:

Volume:

  • Lessons submitted for review per month
  • Lessons approved per month
  • Lessons rejected per month

Performance:

  • Average time to review (hours or days)
  • Percentage meeting review SLA
  • Percentage exceeding SLA

Outcomes:

  • Approval rate (%)
  • Request changes rate (%)
  • Rejection rate (%)

Reviewer workload:

  • Pending reviews per reviewer
  • Completed reviews per reviewer
  • Average time to review per reviewer

Identifying Bottlenecks

Red flags:

Low approval rate (< 60%):

  • Standards may be too strict
  • Authors need better training on lesson quality
  • Review criteria may be unclear

High rejection rate (> 10%):

  • Authors not understanding quality expectations
  • Review process may be too harsh
  • Communication gap between authors and reviewers

Frequently exceeded SLAs:

  • Reviewers overloaded
  • SLA unrealistic for lesson complexity
  • Need more reviewers or reviewer pools

One reviewer with many pending:

  • Workload imbalance
  • May need to redistribute assignments
  • Reviewer may be unavailable (vacation, sick leave)

Solutions:

Training: Provide author training on writing quality lessons that pass review on first submission

Reviewer calibration: Hold reviewer calibration sessions to align on standards and criteria

Adjust SLAs: Make them more realistic based on actual review times

Expand reviewer pools: Add more reviewers to distribute workload

Automate assignments: Use round-robin or least-busy logic to balance load

Reviewer Management

Designating Reviewers

Roles that can review:

  • Admins (can review all lessons)
  • Knowledge Champions (designated role)
  • Managers (review their team's lessons)
  • Custom (assign specific individuals)

To designate a reviewer:

SettingsLessons LearnedReviewers

  1. Click Add Reviewer
  2. Select team member
  3. Choose review scope:
    • All lessons
    • Specific department
    • Specific category (Win, Loss, Process, Technical)
    • Specific bid value range
  4. Set reviewer capacity (max pending reviews)
  5. Save

Reviewer Permissions

Reviewers can:

  • View lessons pending their review
  • Approve, request changes, or reject lessons
  • Add review comments
  • Reassign lessons to other qualified reviewers
  • Request SLA extensions

Reviewers cannot (unless also admin):

  • Approve lessons outside their scope
  • Edit lessons directly (must request changes from author)
  • Delete lessons
  • Change review configuration

Reviewer Training

Provide reviewers with:

Review guidelines document:

  • What to look for
  • Quality checklist
  • Common issues and how to address them
  • Example feedback (constructive vs. unhelpful)

Calibration exercises:

  • Review sample lessons as a group
  • Discuss what quality looks like
  • Align on standards

Access to templates:

  • Feedback templates for common issues
  • Examples of well-written lessons

Access: ResourcesReviewer Training Materials

Frequently Asked Questions

Best Practices

Start Simple

Phase 1: No review gates

  • Launch lessons learned program without gates
  • Build the habit of lesson creation
  • Focus on volume and participation

Phase 2: Opt-in review

  • Allow authors to request review if they want validation
  • Voluntary quality checks
  • Identify quality issues

Phase 3: Required review

  • Implement review gates once you have 30-50 lessons and understand common quality issues
  • Team is accustomed to the process

Set Realistic SLAs

Don't: Set 24-hour SLA when reviewers are overloaded → guaranteed SLA failures

Do: Start with 1 week, measure actual review times, then tighten SLA if feasible

Provide Constructive Feedback

Bad feedback: "This lesson is too vague."

Good feedback: "The lesson would be stronger with specific examples. For instance, instead of 'communication was poor,' describe what specifically broke down (e.g., 'Daily standups were cancelled during final week, leading to 3 instances of duplicated work on Section 4')."

Bad feedback: "Reject. Not good enough."

Good feedback: "Request changes: (1) Add context about the RFP requirements that made this challenging. (2) Reframe recommendations to focus on process, not individuals. (3) Add at least one action item with owner and deadline. Example: Instead of 'Better resource planning,' try 'Create resource allocation spreadsheet with weekly capacity tracking.'"

Recognize Quality

When approving excellent lessons: Add a comment: "Fantastic lesson—clear, specific, and actionable. Approving immediately. Thank you for documenting this valuable insight!"

Benefits:

  • Encourages author to continue creating quality lessons
  • Sets example for other authors
  • Builds positive culture around knowledge sharing

Balance Quality and Volume

Don't: Be so strict that lesson creation drops because people fear rejection

Do: Request changes on most lessons (helps authors improve) but only reject truly inappropriate content

Target metrics:

  • Approval rate: 70-85%
  • Request changes rate: 15-25%
  • Rejection rate: < 5%

Train Authors

Reduce review burden by improving author skills:

  • Share examples of high-quality lessons
  • Provide lesson creation training
  • Offer templates and checklists
  • Give feedback that teaches, not just corrects

Review Calibration

Quarterly calibration sessions:

  • All reviewers meet to discuss standards
  • Review borderline lessons as a group
  • Align on what constitutes "approve" vs. "request changes"
  • Share best practices for giving feedback

Benefits:

  • Consistency across reviewers
  • Prevents reviewer drift (standards getting too strict or too lenient over time)
  • Builds reviewer community

Disabling Review Gates

If review gates aren't working for your organization:

SettingsLessons LearnedReview Gates → Toggle Require Review Before Publishing to OFF

All lessons immediately publish upon creation.

When to disable:

  • Team is small and self-regulates quality
  • Review process has become a bottleneck
  • Quality issues are minimal
  • Organizational culture prefers speed over validation

Alternative to full disabling:

  • Keep review gates enabled
  • Set auto-approve after short SLA (e.g., 48 hours)
  • Reviewers can approve high-quality lessons quickly, but lessons auto-publish if reviewer is busy

Next Steps

Now that you understand review gates:

Note

Review gates are a governance tool—use them when quality control adds value, skip them when speed is more important. Tailor to your organization's needs.

Was this page helpful?

Review Gates | Cothon Docs | Cothon