팀 스탠드업
글로 하는 데일리 스탠드업
데일리 스크럼 툴, 하루에 한 번 서면 체크인을 제출합니다. 무엇을 끝냈는지, 오늘 무엇을 하는지, 업무량이 어느 정도인지, 무엇이 막혔는지를 담당한 클라이언트 태그와 함께 남깁니다. 회의를 여는 대신 팀 전체를 1분 만에 읽어보세요.
이미 워크스페이스가 있으신가요? 로그인하기
- 월 99달러부터 시작하는 요금제
- 멀티 클라이언트 대행사를 위한 설계
- 콘솔 전체에 자사 브랜드 적용
팀 스탠드업
데일리 스크럼 툴, 마케팅 대행사를 위한 비동기 데일리 체크인
15분짜리 스탠드업 하나가 여섯 명 규모 대행사에서 하루 한 시간 반을 잡아먹지만, 정말 들어야 했던 한마디는 처음 90초 안에 이미 나옵니다. 데일리 스크럼 툴, AI Marketing Dashboard의 Stand Up은 그 회의를 각자 자신의 시간에 맞춰 제출하는 서면 체크인으로 바꿉니다. 무엇을 끝냈는지, 오늘 무엇을 하는지, 얼마나 부담을 느끼는지, 무언가 막고 있는지를 담당 클라이언트와 함께 태그합니다. 팀장은 화면 하나를 열어 여섯 명을 집중 업무에서 끌어내지 않고도 하루가 어디까지 왔는지 압니다.
회의냐 메시지냐
서 있을 필요 없는 같은 스탠드업
회의의 목적이던 모두의 현황 파악은 그대로 두고, 내 차례를 기다리는 시간은 덜어냅니다.
전과 후
글로 남긴 체크인이 보관하는 것
매일 하는 회의
- 모두가 자기 차례를 기다립니다
- 늦게 들어온 사람은 앞서 나온 말을 놓칩니다
- 참석자의 절반은 자기와 상관없는 업데이트를 듣습니다
- 블로커는 누군가 기억해 낼 때 비로소 드러납니다
- 통화가 끝나면 남는 기록이 없습니다
회의는 모두를 한꺼번에 불러 모읍니다. 체크인은 사람마다 하루에 한 번씩만 묻습니다.
서면 체크인
- 모두가 하루에 한 번, 각자의 시간에 답합니다
- 체크인마다 작업 대상 클라이언트를 밝힙니다
- 표시된 블로커는 관리자와 그 블로커가 언급한 클라이언트의 담당 팀장에게 전달됩니다
- 관리자는 팀 전체의 하루를 일 분 만에 읽습니다
- 히스토리는 쓴 그대로 남으며, 월간 캘린더, 리포트, CSV 내보내기가 함께 제공됩니다
기본은 비공개입니다. 클라이언트의 담당 팀장은 그 클라이언트가 태그된 체크인을 보고, 그 밖의 모든 사람은 본인의 체크인만 보며, 어떤 내용도 클라이언트 포털에는 전달되지 않습니다.
하루의 흐름
근무일의 처음부터 끝까지
질문 정하기
관리자가 양식을 작성합니다. 안내 문구와 최대 열두 개의 질문을 넣으며, 질문 유형은 짧은 텍스트부터 1~5 척도, 설명이 붙는 예/아니오 플래그까지 다섯 가지 중에서 고를 수 있고, 제출해야 하는 사람도 정합니다.모두가 체크인합니다
사람마다 하루에 한 번 체크인을 제출하고, 작업 대상 클라이언트를 태그하며, 체크인을 남긴 평일의 연속 기록을 쌓아 갑니다.하루 읽기
관리자는 누가 제출했고 누가 아직 남았는지 볼 수 있으며, 그 위에 그날의 블로커와 평균 업무량이 표시됩니다. 담당 팀장은 자신이 맡은 클라이언트의 하루를 봅니다.블로커 해소하기
피드를 블로커만 남기도록 걸러 봅니다. 새 블로커가 생길 때마다 관리자와 그 블로커가 다루는 클라이언트의 담당 팀장에게 알림이 갑니다.
모두의 진행 상황을 알고 시작하는 하루
새 워크스페이스에 팀을 초대하고 첫 체크인 양식을 보여 주세요.
요금제는 월 99달러부터 시작합니다.
이 페이지의 내용
데일리 스크럼 툴, 매일 여는 회의 없이 하는 스탠드업
모두가 각자의 시간에 글로 답합니다
스탠드업은 회의 문제가 아니라 동기화 문제입니다. Stand Up은 이를 서면으로 풀어냅니다. 각자 하루에 체크인 하나를 제출하며, 아침이 실제로 시작되는 시점이 언제든 상관없고, 답변은 관리자나 자기 클라이언트를 맡은 팀장이 1분이면 읽는 하나의 피드로 쌓입니다. 아무도 차례를 기다리지 않고, 늦게 합류한 사람을 위해 같은 말을 되풀이하지 않으며, 오전 7시부터 오후 3시까지 일하는 디자이너가 두 문장을 말하려고 오전 10시 통화에 끌려 나오지 않습니다.
대행사에서는 이 점이 거의 다른 어디보다 더 중요합니다. 스탠드업에 참여하는 사람들이 같은 일을 하고 있는 경우가 드물기 때문입니다. 절반이 나머지 절반의 클라이언트 업데이트를 그저 앉아서 듣는 것이 데일리 회의가 만드는 바로 그 낭비이며, 서면 피드는 그 낭비를 없애면서도 업무를 이끄는 사람들이 필요한 것을 여전히 볼 수 있게 합니다.
우리 대행사가 정말로 답을 알아야 하는 질문
관리자가 정하는 다섯 가지 유형, 최대 12개 질문
기본 양식은 고전적인 네 가지 질문입니다. 지난번에 무엇을 했는지, 오늘 무엇을 하는지, 얼마나 일이 쌓였는지, 막힌 것이 있는지를 묻습니다. 관리자는 이 전부를 다시 쓸 수 있습니다. 안내 문구를 추가하고, 질문을 최대 12개까지 더하거나 빼고, 순서를 바꾸고, 각 질문의 유형을 정합니다. 짧은 텍스트, 긴 텍스트, 양 끝에 직접 라벨을 붙이는 1~5 척도, “예”일 때 상세 설명을 요구하는 예/아니오 플래그, 또는 정해진 선택지 중 하나입니다.
양식을 편집하는 것은 관리자의 결정이며 계속 그렇게 남으므로, 체크인은 팀마다 달라지지 않고 대행사 전체에서 같은 것을 의미합니다. 질문을 필수로 지정하면 양식을 만든 목적인 그 답을 확실히 받을 수 있고, 작성 화면은 그 질문을 건너뛴 제출을 받아주지 않습니다.
블로커는 발생한 그날 아침에 드러납니다, 금요일 리뷰가 아니라
상세 설명이 붙은 예/아니오 플래그
블로커 질문은 플래그이며, 켜진 플래그는 스스로 설명을 달고 다닙니다. 작성자는 “예”라고 답한 뒤 무엇이 막고 있는지 씁니다. 피드에서 그 답변은 표시되고 그날의 인사이트 바에 집계되며, 하루를 다른 누군가의 도움이 필요한 사람들만으로 걸러 주는 블로커 전용 필터로도 확인할 수 있습니다.
브랜드 자산을 기다리는 클라이언트, 아무도 접근 권한을 받지 못한 광고 계정, 스테이징 비밀번호에 막힌 개발자, 이런 것들은 보통 데드라인이 밀릴 때까지 아무도 눈치채지 못하는 죽은 시간입니다. 발생한 그날 아침에 적어 풀어줄 수 있는 관리자와 클라이언트 담당 팀장에게 전달하면, 일주일이 아니라 이메일 한 통이면 끝납니다.
누군가 조용히 가라앉기 전에 받는 업무량 신호
1~5 척도로 자가 평가하고 하루 단위로 평균 냅니다
모든 체크인은 직접 라벨을 붙인 척도 위에서 업무량 답변을 담습니다. 가벼움부터 과부하까지이며, 그날의 인사이트 바는 제출 수와 블로커 수 옆에 팀 평균을 보여줍니다. 이것은 지표가 아니라 느낌이며, 의도적으로 그렇게 둡니다. 이 숫자는 본인이 자신의 한 주에 대해 말하는 것이고, 가동률 리포트는 절대 줄 수 없는 바로 그 신호입니다.
2주에 걸쳐 읽으면 용량 스프레드시트가 절대 알려주지 않는 두 가지, 즉 여전히 성과를 내면서도 번아웃을 향해 가는 사람과, 누구도 계획하지 않은 만큼 누군가의 한 주를 삼키고 있는 계정을 알려줍니다. 시간은 타임시트에 속하고, 이것은 그 옆에 놓인 인간적인 해석입니다.
모든 체크인에 붙는 클라이언트 태그
계정을 태그한 뒤 피드를 하나로 필터링합니다
한 사람의 하루가 계정 하나뿐인 경우는 드물기 때문에, 체크인에는 건드린 모든 클라이언트가 태그됩니다. 대행사 자체의 내부 업무도 나중에 붙인 것이 아니라 정식 태그 대상으로 포함됩니다. 그러면 피드를 클라이언트 하나로 필터링할 수 있고, 스탠드업은 오늘 이 클라이언트에게 무엇이 움직였고, 누가 움직였고, 무엇이 멈췄는지 보여주는 계정 단위 기록이 됩니다.
이것은 계정 매니저가 클라이언트 콜에 들고 들어가는 화면이며, 막 물려받은 계정을 따라잡으려는 신규 담당자가 읽는 화면이기도 합니다. 체크인을 제출할 때 이미 하는 태깅에서 덤으로 따라오는 결과입니다.
제출과 대기, 연속 기록까지 보이는 참여 현황
제출 수, 대기 중 칩, 요일 연속 기록
그날의 바는 예상되는 사람 중 지금까지 몇 명이 제출했는지 세고, 대기 중 행은 아직 제출하지 않은 사람들의 얼굴을 보여주므로 스탠드업을 재촉하는 일이 전체 메시지가 아니라 한 번 보는 것으로 끝납니다. 마지막 사람이 제출하면 그 행이 직접 그렇게 알려주므로 굳이 세지 않아도 됩니다.
각자는 체크인이 이어진 연속 근무일 수도 함께 가지고 다니며, 아직 진행 중인 그날을 위한 유예 기간이 있어 마치지 못한 아침 때문에 연속 기록이 끊기지 않습니다. 스탠드업은 근무일의 습관이므로 주말은 연속 기록을 끊지 않으며, 카운터도 그에 맞춥니다.
스스로 다시 쓰지 않는 한 주의 서면 기록
답변 스냅샷, 달력, 리포트, CSV 내보내기
답변은 스스로를 설명하는 스냅샷으로 저장됩니다. 각각은 답하고 있던 질문과, 그 질문이 그날 가졌던 문구를 함께 간직합니다. 다음 분기에 양식을 바꿔도 지난 분기의 체크인은 아무도 받지 않은 질문으로 다시 라벨이 붙는 대신 쓰인 그대로 읽힙니다. 계속 진실하다고 믿을 수 없는 스탠드업은 기록이 아닙니다.
월간 달력과 멤버별·일별 리포트로 히스토리를 거슬러 올라갈 수 있고, 그날의 피드는 클라이언트로 필터링하거나 블로커만 남기도록 좁힐 수 있으며, 회고나 용량 리뷰, 범위에 관한 대화를 위해 한 달치를 스프레드시트로 원할 때 리포트를 CSV로 내보낼 수 있습니다. Stand Up은 의도적으로 대행사 내부용 화면입니다. 여기 담긴 어떤 것도 클라이언트 포털로 공유되지 않습니다.
데일리 스크럼 툴 도입, 두 주 만에 매일의 통화에서 서면 체크인으로 옮기기
매일 하는 의식을 바꾸는 일은 단계를 나눠야 성공합니다. 이 도입 계획은 습관이 자리 잡는 한 주 동안 통화를 유지하다가, 그다음에 접습니다.
질문 정하기
기본 네 가지 질문으로 시작합니다. 무엇을 끝냈는지, 오늘 무엇을 하는지, 업무량이 어느 정도인지, 막힌 것이 있는지입니다. 대행사에 정말 필요한 질문을 한두 개만 더하고, 거기서 멈춥니다.
누가 제출하는지 정하기
관리자가 누가 체크인을 제출해야 하는지 정합니다. 이 설정은 “Submitted”(제출) 수, “Waiting on”(대기 중) 행, 캘린더에 반영되며, 다른 사람이 제출하는 것을 막지는 않습니다.
제출 시간을 정해 모두에게 알리기
“Waiting on” 행이 아직 체크인을 남기지 않은 사람을 보여 주므로, 팀에는 하루의 첫 회의 전에 제출하는 것 같은 공통 습관만 있으면 됩니다. 시간을 정해 분명히 알리고, 재촉은 행에 맡기세요.
한 주 동안 둘 다 운영하기
통화는 그대로 두되, 한 사람씩 돌아가며 말하는 대신 피드를 읽는 것으로 시작합니다. 체크인에 없었는데도 사람들이 여전히 말하는 내용은 양식에 무엇이 빠져 있는지 알려 줍니다.
매일 하던 통화 접기
둘째 주에는 통화를 없애거나, 목소리로 나눠야 하는 대화를 위해 회의 캘린더에 주간 시간대 하나만 남겨 둡니다. 매일의 사실은 체크인이 전달합니다.
팀원이 활용할 수 있는 체크인 쓰는 법
좋은 체크인은 읽는 사람이 통화에서 따로 물어볼 질문에 미리 답합니다.
| 질문 | 약한 답변 | 더 나은 답변 | 도움이 되는 이유 |
|---|---|---|---|
| 지난번에 무슨 일을 했나요? | 웹사이트 작업함 | 수정한 홈페이지 카피를 승인받으려고 보내고 월간 리포트 초안을 마무리함 | 팀원이 믿고 기댈 수 있는 결과를 구체적으로 적음 |
| 오늘은 무슨 일을 하나요? | 웹사이트 업무 계속 | 봄 프로모션용 예약 페이지를 만든 뒤 광고 시안을 검토함 | 팀장이 무엇을 기대하고 무엇을 물어야 할지 알려 줌 |
| 막힌 것이 있나요? | 있음, 이것저것 기다리는 중 | 있음: 목요일 런칭 전에 클라이언트에게서 광고 계정 초대를 받아야 함 | 장애물이 무엇이고, 누가 풀 수 있고, 무엇이 위험한지 짚음 |
| 어느 클라이언트를 위한 일이었나요? | 태그 없음 | 작업 대상이었던 클라이언트 두 곳을 태그함 | 해당 클라이언트의 담당 팀장이 읽을 수 있고, 피드를 필터링할 수 있는 상태가 유지됨 |
블로커는 양식이 묻는 자리에 적습니다. 블로커를 표시하면 설명이 함께 붙고, 그날의 합계에 집계되며, 관리자와 태그된 클라이언트의 담당 팀장에게 알림이 가므로 명확한 한 문장이 하루를 아낄 수 있습니다. 작업이 닿은 모든 클라이언트를 태그하세요. 태그가 없거나 대행사 자체 계정만 태그한 체크인은 작성자와 관리자 사이에만 남습니다.
직접 만드는 양식에 맞는 질문 유형 고르기
기본 양식은 대부분의 팀에 맞습니다. 더 필요하다면 돌려받고 싶은 답변에 맞는 질문 유형을 고르세요.
| 유형 | 쓰임 | 예시 |
|---|---|---|
| 짧은 텍스트 | 한 줄로 적는 사실 하나 | 어느 환경에서 테스트하고 있나요? |
| 긴 텍스트 | 읽는 사람이 훑어볼 서술 | 어제 무엇을 끝냈나요? |
| 1~5 척도 | 느낌이나 평점을, 양 끝에 직접 정한 문구를 붙여서 묻기 | 금요일 런칭에 얼마나 자신이 있나요? “불확실”부터 “확실”까지 |
| 설명이 붙는 예/아니오 | 표시할 때 설명이 필요한 플래그 | 클라이언트 쪽에서 기다리는 것이 있나요? |
| 객관식 | 정해진 목록에서 고르는 답변 하나 | 오늘은 어디에서 일하나요? |
양식은 관리자가 편집합니다. 안내 문구 한 줄과 질문 최대 열두 개까지 담을 수 있습니다. 체크인이 그 질문 없이는 불완전할 때만 필수로 지정하세요. 필수 질문이 하나 늘어날 때마다 습관을 건너뛸 이유도 하나 늘어나기 때문입니다. 변경은 다음 체크인부터 적용됩니다.
체크인을 읽을 수 있는 사람, 그리고 그것이 핵심인 이유
기본적으로 비공개라는 점이 답변을 솔직하게 만듭니다. 규칙은 읽는 사람 유형마다 한 문장으로 정리됩니다.
| 읽는 사람 | 읽을 수 있는 체크인 | 화면에서 보는 것 |
|---|---|---|
| 관리자 | 워크스페이스의 모든 체크인 | 제출해야 하는 사람 대비 실제 제출자, 아직 대기 중인 사람, 모든 블로커, 팀의 업무량, 캘린더와 리포트, CSV 내보내기, 양식 편집기 |
| 클라이언트 담당 팀장 | 본인의 체크인과, 본인이 맡은 클라이언트가 태그된 체크인 | 해당 클라이언트 계정의 피드, 블로커, 업무량을 보여 주는 “Your clients” 보기 |
| 그 외 모든 사람 | 본인의 체크인만 | 본인의 연속 기록, 이번 주, 본인의 캘린더 |
클라이언트 담당 팀장은 클라이언트의 “Team & Roles”(팀과 역할) 탭에서 “Account Manager”(계정 매니저), “Marketing Lead”, “Design Lead”, “Development Lead”로 지정된 사람입니다. 그래서 클라이언트에 사람을 배정하는 일이 곧 그 클라이언트의 체크인을 누가 읽는지도 정합니다. 스탠드업은 클라이언트 포털에 절대 나타나지 않는 내부 기록입니다.
참고
열람 범위를 좁게 두는 이유
실제 팀에는 반드시 제출해야 하는 사람도, 그렇지 않은 사람도 있으며, 모두가 읽을 수 있는 피드는 협업 툴을 출석부로 바꿔 버립니다. 읽을 수 있는 사람을 업무에 책임을 지는 사람으로 제한하면 글이 솔직해집니다. 블로커 알림은 각자의 설정에 따라 이메일, 기기 알림, 알림 벨로 전달될 수 있으며, 이메일과 기기 알림에는 클라이언트 이름이 나오지 않습니다.
점수가 아니라 신호로 읽는 피드
업무량 수치는 본인이 직접 보고한 값이며, 어떤 숫자도 누군가의 가치를 재지 않습니다. 대화를 시작하는 계기로 다루세요.
- 블로커(Blocker)
- 블로커 질문에 “예”라고 답하고, 무엇이 가로막고 있는지 상세 내용을 옆에 적은 것입니다.
- 업무량(Workload)
- 할 일이 얼마나 쌓여 있는지에 대한 본인의 1~5 답변으로, 읽는 사람에게는 하루 기준 평균으로 보입니다.
- 연속 기록(Streak)
- 체크인이 이어진 평일의 수입니다. 주말은 기록을 끊지 않으며, 아직 진행 중인 날은 기록에 불리하게 작용하지 않습니다.
- 대기 중(Waiting on)
- 관리자가 제출을 기대하는 사람 가운데 오늘 아직 제출하지 않은 사람들입니다.
- 제출 대상(Expected to post)
- 관리자가 참여 수치를 위해 관리하는 목록입니다. 집계에 영향을 줄 뿐, 누가 제출할 수 있는지를 정하지는 않습니다.
| 패턴 | 의미할 수 있는 것 | 알맞은 대응 |
|---|---|---|
| 같은 클라이언트가 며칠째 블로커에 나타남 | 장애물이 팀 밖에 있음: 답변, 접근 권한 요청, 또는 결정 | 각자가 같은 내용을 다시 적게 두지 말고, 그 클라이언트의 담당 팀장에게 가져가 누가 챙길지 정함 |
| 한 사람의 업무량이 며칠째 무거운 쪽에 머묾 | 계획한 일이 너무 많거나, 업무가 보기보다 큼 | 먼저 본인에게 물어본 뒤, 기한을 놓치기 전에 프로젝트에서 업무를 다시 배분함 |
| 한 사람의 이름이 “Waiting on” 아래에 계속 나타남 | 습관이 아직 자리 잡지 않았거나, 그 사람이 제출 대상이 아님 | 재촉하기 전에 “Who’s expected”(제출 대상)를 확인함 |
| 대부분의 체크인이 한 클라이언트를 언급함 | 그 계정이 계획보다 한 주의 더 많은 부분을 차지하고 있음 | 업무 시간에 기록된 시간과 비교해 범위나 인력 배치를 다시 조정함 |
“Daily”(일별) 보기는 하루씩 보여 주며, 관리자와 담당 팀장에게는 클라이언트 필터와 “Blockers only”(블로커만 보기) 스위치가 있습니다. 관리자에게는 “Calendar”가 제출해야 하는 사람 중 몇 명이 제출했는지에 따라 날짜마다 색을 달리 칠합니다. 관리자와 담당 팀장에게 열리는 “Report”는 팀원과 날짜를 가로세로로 놓고 제출한 칸을 표시하며, 관리자에게는 누락된 칸과 대기 중인 칸도 보여 주고, 해당 기간의 “By client”(클라이언트별) 분석과 “Export CSV”(CSV 내보내기)도 제공합니다. 모든 수치는 그 뒤에 있는 날짜를 열어 줍니다.
스탠드업이 끝나고 다른 툴이 시작되는 지점
체크인은 의도적으로 작게 설계되어 있습니다. 더 큰 기록을 복제하는 대신 그쪽을 가리킵니다.
- 시간은 업무 시간에 기록합니다. 스탠드업에는 그 옆에서 사람이 직접 전하는 해석, 즉 본인이 느끼는 업무 부담과 앞을 가로막는 것이 담깁니다.
- 대화가 필요한 블로커는 채팅으로 가져갑니다. 체크인은 블로커가 있다는 사실을 알리고, 스레드가 그것을 해결합니다.
- 추적해야 하는 일은 프로젝트에 업무로 등록합니다. 같은 장애물이 어떤 업무를 붙잡고 있다면, 체크인이 알리는 내용이 보드에도 보이도록 그 업무를 “Issues”(이슈) 열로 옮깁니다.
데일리 스크럼 툴인 스탠드업은 Studio부터 모든 요금제에 포함되며, 사이드바의 팀 그룹에서 업무 시간과 회의 사이에 있습니다.
자주 묻는 질문
서면 스탠드업을 쓰는 데는 얼마나 걸려야 하나요?
하루의 첫 업무를 시작하기 전에 끝낼 수 있을 만큼 짧아야 하며, 보통 긴 질문 하나에 한두 문장이면 됩니다. 사람들에게 그보다 훨씬 많은 시간이 필요하다면 양식에 질문이 너무 많거나 업무의 갈래가 너무 많다는 뜻입니다. 간결한 체크인은 팀장이 실제로 끝까지 읽는 체크인이기도 합니다.
체크인을 제출하지 않은 사람은 어떻게 챙기나요?
관리자는 아직 제출해야 하는 사람의 이름이 나오는 “Waiting on” 행을 보고, “Report”는 누락된 날과 대기 중인 날을 표시하므로, 팀 전체에 메시지를 보내지 않고도 누가 체크인을 남기지 않았는지 알 수 있습니다. 제출 시간을 팀의 습관으로 정하고, 행이 미제출자를 보여 주게 하세요.
어제의 체크인을 제출하거나 고칠 수 있나요?
가능합니다. 이전 날짜 화살표로 하루 뒤로 간 다음, 그날의 항목을 제출하거나 수정하면 됩니다. 한 달이 지난 스탠드업은 읽기 전용이며, 다음 날짜 화살표는 오늘에서 멈춥니다. 체크인은 한 사람당 하루에 하나이므로, 이미 쓴 날은 새로 쓰는 것이 아니라 수정합니다.
누군가 블로커를 표시하면 누구에게 알림이 가나요?
관리자와 체크인에 태그된 클라이언트의 담당 팀장에게 알림이 가며, 작성자 본인에게는 가지 않습니다. 각자의 설정에 따라 알림 벨, 이메일, 기기 알림으로 전달되고, 알림을 열면 그날의 항목이 열립니다. 이메일과 기기 알림에는 클라이언트 이름이 나오지 않습니다.
다른 팀원의 체크인을 수정할 수 있나요?
아니요. 체크인은 작성한 사람만 수정할 수 있습니다. 관리자는 실수로 제출한 항목처럼 어떤 항목이든 삭제할 수 있지만, 팀원이 쓴 내용을 고쳐 쓸 수는 없습니다. 그래서 모든 체크인이 작성자 본인의 말을 충실히 담은 기록으로 남습니다.
내가 입력한 업무량 숫자는 누가 보나요?
그 숫자가 속한 체크인을 읽을 수 있는 사람이 봅니다. 본인, 관리자, 그리고 본인이 태그한 클라이언트의 담당 팀장입니다. 다른 팀원은 볼 수 없습니다. 관리자와 담당 팀장은 자신이 읽을 수 있는 체크인 전체의 평균을 보며, 이는 성과를 재는 잣대가 아니라 상황이 어떤지 물어보는 계기입니다.
클라이언트도 우리 스탠드업을 볼 수 있나요?
아니요. 스탠드업은 내부 기록이며 클라이언트 포털에는 절대 표시되지 않습니다. 클라이언트가 태그된 체크인을 읽을 수 있는 사람은 관리자와 그 클라이언트의 담당 팀장으로 배정된 대행사 팀원뿐입니다. 클라이언트 쪽 사람은 이 기록을 볼 수 없습니다.