| name | s-skill-interview-to-ticket |
| version | 1.1.0 |
| description | 인터뷰 피드백에서 SAL(Engineering) 팀 티켓 초안을 작성할 때 사용. "인터뷰 티켓", "피드백 티켓", "SAL 티켓 만들어" 등의 요청 시 자동 호출.
|
| allowed-tools | ["Bash","Read","Write","AskUserQuestion","ToolSearch","mcp__claude_ai_Notion__notion-fetch","mcp__linear-server__linear_getIssueById"] |
Interview to Ticket
고객 인터뷰 피드백을 세일즈맵 CRM 커스텀 오브젝트 티켓으로 생성한다.
입력
$ARGUMENTS: 피드백이 담긴 소스 (URL, 텍스트 등 형식 무관)- 입력이 없으면 사용자에게 요청한다.
작업 프로세스
1. 피드백 수집
입력 형식을 자동 판별하여 내용을 가져온다:
- Notion URL →
notion-fetch로 페이지 내용을 가져온다.
- Linear URL →
linear_getIssueById로 이슈 내용을 가져온다.
- 텍스트 → 그대로 사용한다.
- 추출 대상:
- 고객사/담당자 (누구의 피드백인지)
- 문제 상황 (무엇이 안 되는지, 불편한지)
- 고객이 제안한 해결책 (있다면)
- 인터뷰 날짜
2. 초안 작성
아래 양식으로 초안을 작성하여 사용자에게 보여준다:
**제목**: [{기능영역}] {핵심 문제 요약}
**1. 주관적 온도 (10점 척도)**
{사용자가 제공한 점수, 없으면 사용자에게 질문}
**2. 배경/문제 상황**
- {고객사} {담당자}님 인터뷰({날짜})에서 접수된 피드백
- {확인된 문제 상황 서술}
- {비교 대상이 있으면 언급 (예: 타 서비스에서는 되는데 세일즈맵에서는 안 됨)}
**3. 해결책 (있다면)**
- {구현 방식을 한정짓지 않는 열린 형태로 작성}
- {고객이 제안한 방식은 예시로만 포함}
제목 규칙
- 패턴:
[기능영역] 핵심 문제 요약
- 해결책이 아닌 문제를 쓴다 (예: "표 형태 보기/내보내기 기능" X -> "표 형태로 볼 수 없음" O)
- 기능영역 예시: 이메일, 에디터, 파이프라인, 연락처, 대시보드 등
- 고객사명은 제목에 넣지 않음
해결책 작성 규칙
- 고객이 특정 해결책을 언급했더라도, 그것만이 답이 아닐 수 있음
- "예: ~" 형태로 예시를 나열하되 열린 형태로 작성
- 구현 방식을 한정짓지 않음
3. 검증 질문
초안을 보여준 뒤 다음을 확인한다:
- 문제 상황이 확인된 사실인지, 고객 제보 수준인지
- 주관적 온도가 적절한지 (빈도, 심각도 고려)
- 해결책 방향이 맞는지
- 제목의 기능영역이 맞는지
사용자 피드백을 반영하여 최종본을 확정한다.
4. CRM 티켓 생성
최종본 확정 후 세일즈맵 CRM에 커스텀 오브젝트 티켓을 생성한다.
4-1. 티켓 타입 확인
| 타입 | Definition ID |
|---|
| CRM 티켓 | 019abebf-887c-755f-b526-2567e2476fde |
| SDR 티켓 | 019e3dbe-f9e0-7000-80c2-001c51ebb091 |
사용자가 명시하지 않으면 질문한다. 대부분의 경우 CRM 티켓이다.
4-2. API 인증
중요: 환경변수 $SALESMAP_API_TOKEN이 Bash 세션에서 로드되지 않을 수 있다.
실패 시 ~/.zshrc에서 토큰 값을 직접 읽어서 사용한다.
TOKEN=${SALESMAP_API_TOKEN:-$(grep SALESMAP_API_TOKEN ~/.zshrc | sed 's/.*"\(.*\)"/\1/')}
4-3. 커스텀 오브젝트 생성 — 검증된 필드 ID 매핑
중요: 필드 정의 API(GET /v2/field/custom-object)는 모든 커스텀 오브젝트의 필드를 섞어서 반환한다.
동일 이름 필드가 여러 개 나오므로 반드시 아래 검증된 필드 ID를 사용한다.
필드 정의 API를 호출하여 필드를 탐색하지 않는다.
CRM 티켓 필드 ID
| 필드명 | 필드 ID | 타입 | 비고 |
|---|
| 티켓(CRM) 이름 | 35f19e7e-039f-40d1-912e-da8b93a329ef | string | 대표 필드 — 반드시 포함 |
| 소스 | d1ae8285-8b1b-4494-a89d-f1f113af04a0 | multiSelect | 옵션: VOC, 인터뷰, 정량 지표, 기타 |
| 이슈 유형 | 815c9050-3d43-4261-a3d3-225e5dc7ee1c | singleSelect | 옵션: Regular Track, Fast Track, Quick Win Track |
| 기능 카테고리 | bd9561e3-fab6-4fe6-b610-798d9542d11a | multiSelect | 아래 옵션 목록 참조 |
| 제보 일자 | 1930963f-eaf5-4d29-a2a8-9676187665e6 | date | 미검증 — 실패 시 스킵 |
| 담당자 | 미확정 | user | 미검증 — 실패 시 스킵 |
| 요청사 | 6cf84776-146a-4b9e-bd1e-2e9f2dcbc5e9 | multiOrganization | 검증됨 — organizationValueIdList 사용 |
| 요청자 | e59cd00d-17d2-4e68-bb1b-3a90f3c1e86e | multiPeople | 검증됨 — peopleValueIdList 사용 |
SDR 티켓 필드 ID
SDR 티켓은 CRM 티켓과 필드 ID가 다르다. 아래는 추정이며, 첫 사용 시 필드 정의 API로 검증 필요.
| 필드명 | 필드 ID | 타입 | 비고 |
|---|
| 티켓(SDR) 이름 | 019e3dbe-f9f3-7000-80c2-09141ab99ffe | string | 대표 필드 — 반드시 포함 |
| 소스 | ad7b5383-af11-46f5-a313-33e5b920a3e1 | multiSelect | 추정 — 첫 사용 시 검증 |
| 이슈 유형 | 6f89d747-5ea5-4c5d-abbf-d966d4de7aae | singleSelect | 추정 — 첫 사용 시 검증 |
| 기능 카테고리 | 13a23b63-f036-4656-8893-cafafe961b9b | multiSelect | 추정 — 첫 사용 시 검증 |
SDR 티켓 필드 ID가 검증되면 이 표를 업데이트할 것.
기능 카테고리 옵션 (CRM 티켓 기준, SDR도 동일 옵션명)
노트, 검색, 다국어, 데이터 업로드, 데이터 필드 관리, 레이아웃, 목록/파이프라인, 마케팅 이메일, 문서, 미리보기, 미팅, 병합, 뷰(필터/정렬/컬럼), 사용자 관리, 상세 페이지, 상품/견적서, 시퀀스, 알림, 에디터, 연동, 워크플로우, 웹 폼, 이메일, 차트/대시보드, 커스텀 오브젝트, AI, UX/UI, API/웹훅, TODO/캘린더, 타임라인/히스토리, SMS/알림톡, 전체 선택, 권한, 기타, 그룹, 모바일
요청 형식
{
"customObjectDefinitionId": "{definitionId}",
"name": "[기능영역] 핵심 문제 요약",
"fieldList": [
{"id": "{대표필드ID}", "name": "{대표필드명}", "stringValue": "[기능영역] 핵심 문제 요약"},
{"id": "{소스ID}", "name": "소스", "stringValueList": ["인터뷰"]},
{"id": "{이슈유형ID}", "name": "이슈 유형", "stringValue": "Regular Track"},
{"id": "{기능카테고리ID}", "name": "기능 카테고리", "stringValueList": ["목록/파이프라인"]}
]
}
핵심 규칙:
fieldList에 대표 필드(티켓 이름)를 반드시 포함해야 한다. 누락 시 "대표 필드를 입력해 주세요" 오류 발생.name (최상위)과 대표 필드의 stringValue에 동일한 제목을 넣는다.- multiSelect ->
stringValueList (배열), singleSelect -> stringValue (문자열), user -> userValueId, date -> dateValue
- 필드 ID를 반드시 함께 전달한다. 이름만으로는 중복 필드 구분이 안 된다.
4-4. 요청사/요청자 연결
인터뷰 대상 고객사/담당자가 특정되면 티켓에 연결한다. 연결 가능하면 묻지 않고 바로 연결한다.
검색 API 스키마 (검증됨)
POST /v2/object/{targetType}/search
- targetType:
people, organization, deal, lead
- 요청 바디:
{
"filterGroupList": [
{
"filters": [
{
"fieldName": "이름",
"operator": "CONTAINS",
"value": "검색어"
}
]
}
]
}
fieldName: 한글 필드명 사용 (예: "이름", "이메일")operator: 대문자 (예: EQ, CONTAINS, IN, EXISTS, NOT_EXISTS, LT, GTE 등)filterGroupList: 최대 3개 그룹, 그룹 간 ORfilters: 그룹 내 최대 3개, 필터 간 AND- 응답: ID와 name만 포함
연결 절차
- 요청사 (회사) 검색 및 연결:
POST /v2/object/organization/search로 회사명 검색하여 UUID 확보- 티켓 수정 시
{ "name": "요청사", "organizationValueIdList": ["<ORG_UUID>"] }로 설정
- 요청자 (고객) 검색 및 연결:
POST /v2/object/people/search로 담당자명 검색하여 UUID 확보- 티켓 수정 시
{ "name": "요청자", "peopleValueIdList": ["<PEOPLE_UUID>"] }로 설정
- 검색 결과가 여러 건이면 사용자에게 확인
- 티켓 수정은
POST /v2/custom-object/{id} (PATCH 아님)
4-5. 노트(메모)로 상세 내용 작성
생성된 티켓에 메모를 추가하여 상세 설명을 기록한다.
메모 포맷 (반드시 이 형식을 따른다):
1. 주관적 온도(10점 척도)
{N}
2. 배경/문제 상황
- {항목 1}
- {항목 2}
3. 해결책(있다면)
- {항목 1}
- {항목 2}
- 번호 + 제목 줄 -> 바로 아래에 값/내용
- 섹션 사이는
\n\n(빈 줄)으로 구분하되, CRM UI가 연속 줄바꿈을 무시하므로 실제 표시에서는 빈 줄 없이 붙어 보임 (API 한계)
- 2, 3번 섹션의 항목은
- bullet list로 작성
- 초안의 전체 내용(주관적 온도, 배경/문제 상황, 해결책)을 이 포맷으로 작성
POST https://salesmap.kr/api/v2/custom-object/{생성된 티켓 ID}
{
"memo": "1. 주관적 온도(10점 척도)\n{N}\n\n2. 배경/문제 상황\n- {항목1}\n- {항목2}\n\n3. 해결책(있다면)\n- {항목1}\n- {항목2}"
}
4-6. 결과 확인
- 성공 시: 생성된 티켓 ID와 이름을 출력
- 실패 시: 에러 메시지를 보여주고 원인 분석 후 재시도 여부를 묻는다
주의사항
- 문제가 확인된 사실인지, 고객 제보인지 구분하여 서술 톤을 맞춘다
- 확인됨: "~이 차단됨", "~이 불가함"
- 미확인: "~이 안 된다는 피드백 접수", "~라고 함"
- 하나의 인터뷰에서 여러 피드백이 나올 수 있음. 티켓은 이슈별로 분리하여 각각 생성
- 주관적 온도를 사용자가 제공하지 않으면 반드시 질문 (임의로 채우지 않음)
- CRM API 호출 시 rate limit 준수 (0.1~0.15초 간격)
- 여러 티켓을 한번에 생성할 때는 하나씩 순차 생성하고, 각각 결과를 보고한다
- 필드 정의 API를 호출하여 필드를 탐색하지 않는다 — 위 검증된 필드 ID 표를 사용한다
$ARGUMENTS
