/keeper-out/admin Lead Detail View 설계

2026-05-05 · 결정 받기 보고서 · keeper-direct staging · pain_points 백엔드 박은 직후

목차

  1. 한 줄 결정 요청
  2. 현재 admin이 보여주는 데이터
  3. 자동님이 원한 풀 데이터 매핑
  4. 더 있을 것 — 제 추가 제안
  5. 새 페이지 레이아웃 (13 섹션)
  6. API 변경 (GET endpoint 추가)
  7. Phase 분할 — 오늘 vs 다음
  8. 함정 / 미확정
  9. 결정 요청

01.한 줄 결정 요청

/keeper-out/admin/leads/[id]/ 신규 페이지를 만들어, 방금 박은 pain_points·pain_note + 매장·고객·사진·영업자·지급·이벤트 타임라인까지 한 화면에 펼치겠습니다. Phase 1(오늘)은 13섹션 중 8개만, visit_logs / owner 다른 매장 / place 마스터는 Phase 2로 미루는 게 합리적입니다. 스코프 동의 받으면 즉시 진입.

02.현재 admin이 보여주는 데이터

app/keeper-out/admin/AdminClient.tsx의 풀퍼널 list가 PipelineRow 한 줄짜리만 출력 중이고, 개별 lead의 detail view는 아예 없음:

// 현재 PipelineRow 한 줄
{lead.store_name} · {lead.business_no}
{lead.phone} · {lead.current_security} · {lead.camera_count}대 · {scenario benefit}
[🏬 매장] [📷 실사리드] [☎️ 콜매칭] [🚩 설치완료]   // 4단계 진행 버튼
[💸 N페이 송금 대기]                              // payout pending시

즉 영업맨이 매장 방문 전 talking point 준비할 페이지가 없음. 자동님이 지금 만들자는 게 정확히 이 부분.

03.자동님이 원한 풀 데이터 매핑

자동님 발화 verbatim — "페인포인트를 포함한 고객의 모든 데이터와 사진들이 다 포함되고 영업자가 누군지까지, 매장 데이터, 연락처, 지급 여부와 금액, 에이전트 1,2,3 항목들도". 이걸 DB 컬럼/테이블로 풀어보면:

요청출처특이사항
pain_points (오늘 박음)keeper_outbound_leads.pain_points6개 multi-select chip
pain_note (오늘 박음)keeper_outbound_leads.pain_note자유 textarea, 인용 박스
고객 모든 데이터leads (15+ 컬럼)아래 04번 카드 참조
사진들leads.photo_urls text[]Vercel Storage 버킷 keeper-out-photos
영업자 1/2/3agent_1·agent_2·agent_3 (FK)keeper_outbound_agents JOIN — 이름·전화·role 필요
매장 데이터leads + place_id JOIN placesplace 마스터는 Phase 2 권장
연락처leads.phonetel: 링크
지급 여부와 금액keeper_outbound_payouts JOINtype별 합계 + 상태

04.더 있을 것 — 제 추가 제안

자동님이 "음... 더 뭐있지?"라고 열어두셔서, 제가 떠올린 것 5건:

A.funnel_events 타임라인
diagnose_submitted / naver_pay_sent_auto / naver_pay_failed / installed 등 시간순. 이미 INSERT되고 있는데 표시되는 화면이 없음.
B.visit_logs (현장 방문)
promoter + step + outcome + GPS + 녹음 url + 사진 + 메모. 영업원이 "이 매장 누가 언제 갔지?" 즉시 확인.
C.scheduled_sms_at
5분 지연 SMS 큐 시각. 발송됐는지 / 대기중인지 표시.
D.scenario / expected_benefit
A 72만 vs B 92만(통신결합) — 영업맨이 talking 시작 anchor.
E.owner의 다른 매장
owner_id JOIN. 1점주 N매장이면 "이 사장님 매장 3개입니다" — 영업 효율 점프업.
F.naver_place_id 외부 링크
네이버 플레이스 새 탭 열기. 영업원이 매장 사진/리뷰 미리 확인.

05.새 페이지 레이아웃 (13 섹션)

경로: app/keeper-out/admin/leads/[id]/page.tsx + LeadDetailClient.tsx

#섹션주요 컬럼/테이블Phase
1Hero (요약 + status pipeline)store_name, status, scenario, expected_benefit, created_atP1
2고객 풀 데이터ceo_name, phone, business_no, naver_place_id, marketing_consent_atP1
3현재 보안 상황current_security, device_age, camera_count, monthly_fee, combined_ispP1
4★ Pain Points (핵심)pain_points[], pain_note + 영업분기 매핑P1
5사진 갤러리photo_urls[] 그리드P1
6영업자 1/2/3agent_1/2/3 FK + agents JOINP1
7지급/인센티브payouts JOIN — type/recipient/amount/statusP1
8이벤트 타임라인funnel_events 시간순P1
9방문 로그visit_logs JOINP2
10점주 다른 매장owner_id JOIN — 동일 owner의 leadsP2
11매장 마스터place_id JOIN places — 동네 폐업률·우선순위P2
12Status 이동 액션기존 PATCH route 재사용P1
13방문 메모 추가visit_logs INSERT 폼P2

섹션 4 — Pain Points 상세 (오늘 핵심)

출동지연
→ 출동시간 SLA 보증 강조
요금부담
→ 결합 영업 / 가격 비교
약정부담
→ 위약금 대납 시나리오
사각지대
→ 카메라 위치/대수 보강
AS불만
→ 커뮤니케이션 가치
앱불편
→ 모던 UX 차별화

선택된 chip만 컬러 강조. pain_note는 따옴표 인용 박스로 사장님 발화 재현.

06.API 변경

현재 app/api/keeper-out/lead/[id]/route.tsPATCH만 있음. GET 추가해서 lead + agents + payouts + funnel_events 한 번에 fetch:

export async function GET(req, { params }) {
  const { id } = await params;
  // PostgREST embed로 한 방에
  const rows = await sbSelect(
    "keeper_outbound_leads",
    `select=*,
      agent_1_data:keeper_outbound_agents!agent_1(id,name,phone,role),
      agent_2_data:keeper_outbound_agents!agent_2(id,name,phone,role),
      agent_3_data:keeper_outbound_agents!agent_3(id,name,phone,role),
      payouts:keeper_outbound_payouts(*),
      events:keeper_outbound_funnel_events(*)
      &id=eq.${id}`
  );
  return NextResponse.json({ ok: true, lead: rows[0] });
}
★ 왜 PostgREST embed인가

07.Phase 분할

Phase스코프예상 시간커밋 단위
P1 — 오늘 섹션 1·2·3·4·5·6·7·8·12 (9개) + GET endpoint + AdminClient 클릭 이동 ~2시간 3 commits (route / detail page / link)
P2 — 다음 세션 섹션 9·10·11·13 (visit_logs / owner / place / 메모 추가) ~3시간 별도 보고서

08.함정 / 미확정

⚠️ 주의 항목 4건

  1. 색깔 룰 — 키퍼 오렌지(#ff5c00) 그대로: memory feedback_diagnose_design_isolation에 따라 /keeper-out/admin은 영업원 컨텍스트라 키퍼 오렌지 톤. 이번에 청록(#009090)으로 안 박음. 보고서만 청록.
  2. RLS — service_role 필요: keeper_outbound_payouts · funnel_events는 service_role만 SELECT 가능 (anon 차단). 이미 lib/keeper-out/supabase.ts가 service_role key 쓰니 OK.
  3. 사진 buckets public: keeper-out-photos bucket이 public이라 URL 직접 노출 OK. 단 admin이 배포 후 외부에 떠다니지 않게 (/keeper-out/admin/* 라우트 가드 필요 여부 → 현재 가드 없음, 별도 결정 필요).
  4. RBAC — 곽효재 노출 차단: 이건 outbound-dashboard V2 가드레일이지만 keeper-direct admin은 현재 가드 zero. production 노출 전에 최소한 IP 화이트리스트 또는 하드패스워드 필요.

09.결정 요청

자동님 한 줄 회신 부탁

아래 셋 중 하나로 회신 주시면 즉시 진입:

어제 박은 pain_points 백엔드 commit 여부도 같이 결정하시면 좋아요 (P1 진입 전 staging에 박는 게 안전 — DB 컬럼은 이미 박혀있어서).


컨텍스트 인덱스 (한 줄 인용)