Reviews & Sign-offs

CharleOS uses reviews and sign-offs to ensure quality at each phase. This guide explains who reviews what, how the process works, and what happens when work needs changes.

​

Review overview

Reviews are quality gates that work must pass through:

• Design review - Client approves visual designs
• Internal QA review - Internal testing and approval
• External QA review - Client tests and approves work
• Deployment sign-off - Final approval before going live

​

Reviewable subtasks

Five subtask types require review:

​

Review workflow

​

Standard review process

​

Design reviews

​

When design is complete

1. Designer completes design subtask
2. Provides handoff URL (Figma link, etc.)
3. Status becomes “Awaiting Review”

​

Review process

Internal review:

• PM or CSM reviews design internally
• Checks alignment with requirements
• Approves or requests changes

Client review:

• Design sent to client via portal
• Client provides feedback
• Approves or requests changes

​

Outcomes

Approved:

• Design subtask marked complete
• Task moves to Development phase

Changes requested:

• “Client Design Feedback” subtask created
• Assigned to original designer
• Designer incorporates feedback
• Returns to review
• Iteration count increments

​

Internal QA reviews

​

When development is complete

1. Developer completes development subtask
2. Provides:
   • Branch name
   • Preview/staging URL
   • Testing notes
3. Internal QA review subtask becomes available

​

QA testing process

​

Pass outcome

When QA passes:

• Internal QA subtask marked complete
• Task moves to External QA phase
• Notifications sent to CSM/PM
• Work ready for client review

​

Fail outcome

When QA fails:

1. QA provides failure notes/issues
2. System creates “Internal QA Fixes” subtask
3. Auto-assigned to original developer
4. Task returns to Development phase
5. Developer fixes issues
6. Returns to Internal QA for re-test
7. Iteration increments

​

External QA reviews

​

Sending to client

After internal QA passes:

1. CSM or PM clicks “Send to Client”
2. Client receives notification
3. Work appears in client portal for review
4. External QA review subtask status updates

​

Client testing

Clients review work via portal:

• Access preview/staging URL
• Test functionality
• Provide feedback via review form
• Choose outcome: Approve or Request Changes

​

Approve outcome

When client approves:

• External QA subtask marked complete
• Task moves to Deployment phase
• Notifications sent to PM
• Work ready for production deploy

​

Request changes outcome

When client requests changes:

1. Client provides feedback and issues
2. System creates “External QA Fixes” subtask
3. Auto-assigned to original developer
4. Task returns to Development phase
5. Developer fixes issues
6. Goes through Internal QA again
7. Returns to External QA for re-review
8. Iteration increments

​

Deployment sign-offs

​

After external QA approval

1. Deployment subtask scheduled
2. Assigned to appropriate person (PM/DevOps)
3. Work deployed to production

​

Deployment process

​

Sign-off outcomes

Approved:

• Deployment subtask marked complete
• Task marked complete
• Notifications sent to team and client
• Work officially launched

Failed:

• Deployment subtask stays in progress
• Issues documented
• Fix and re-deploy
• Returns to sign-off process

​

Review permissions

​

Who can review

Important rules:

• Assignee cannot review their own work
• Reviews require management role or QA work type
• Client reviews done via portal only

​

Feedback loops

​

Understanding iterations

Iterations track how many times work has been reviewed:

• Iteration 1: Initial submission
• Iteration 2: First round of fixes
• Iteration 3+: Additional fix rounds

​

Why iterations matter

High iteration counts indicate:

• Unclear requirements
• Scope creep
• Communication breakdowns
• Estimation problems
• Technical challenges

​

Monitoring iterations

Track iterations to:

• Identify problematic requirements
• Improve estimation accuracy
• Spot communication issues
• Inform future quotes

​

Review best practices

​

For assignees

​

For reviewers

​

Common review scenarios

​

Scenario 1: Design needs minor tweaks

Situation: Client wants small color/spacing changes Process:

1. Client requests changes
2. Client Design Feedback subtask created
3. Designer makes tweaks (15-30 min)
4. Re-submit for review
5. Client approves
6. Moves to development

​

Scenario 2: Development fails Internal QA

Situation: QA finds bugs in functionality Process:

1. QA marks as Failed with issue list
2. Internal QA Fixes subtask created
3. Developer debugs and fixes (1-2 hours)
4. Re-submit to QA
5. QA passes
6. Moves to External QA

​

Scenario 3: Client finds major issues

Situation: Client testing reveals missing functionality Process:

1. Client requests changes with detailed feedback
2. External QA Fixes subtask created
3. Developer addresses issues (4-8 hours)
4. Goes through Internal QA (pass/fail loop possible)
5. Returns to External QA
6. Client re-tests and approves
7. Moves to Deployment

​

Scenario 4: Multiple QA failures

Situation: Work fails QA multiple times Actions:

• Review requirements with team
• Check if scope changed
• Assess if more time needed
• Consider if right person assigned
• Escalate to PM/CSM if needed

​

Review notifications

​

Who gets notified

Design complete:

• PM, CSM (internal review)
• Client (if sent for review)

Internal QA ready:

• QA team

Internal QA passed:

• PM, CSM (ready for client)

External QA ready:

• Client users

External QA approved:

• PM (ready for deployment)

Deployment complete:

• PM, CSM, Client

​

Troubleshooting

​

Next steps