솔루션 핸드북
Custom webhook 트리거, Run once 테스트 경로, HTTP 모듈, Make History 검증, Jodoo 필드, 배포 체크리스트를 포함한 Make 지원 분류 루프 계획 가이드입니다.
핸드북 열기MAKE + JODOO
Make + Jodoo로 구현하는 AI 지원 티켓 우선순위 분류
Make와 Jodoo를 함께 사용해 지원 티켓 webhook을 수신하고, 구조화된 분류 필드를 HTTP 모듈로 전송한 뒤, 에스컬레이션 필드를 Jodoo에 기록하여 후속 조치를 계속 가시화할 수 있습니다.
Make webhook으로 티켓 수신우선순위와 상태 분류SLA 필드를 Jodoo에 기록에스컬레이션 후속 조치 추적 유지Make History에서 운영 내역, 크레딧, 실행 상태 검토
영상 둘러보기
Make 데모에서 일어나는 일
이 영상은 하나의 지원 처리 루프를 보여줍니다. 티켓이 Make Custom webhook으로 들어오고, Make가 HTTP 모듈을 통해 분류 필드를 전송하며, Jodoo가 에스컬레이션 레코드를 유지합니다.
티켓이 Make로 들어옵니다
시나리오는 지원 양식, 포털, 채팅 또는 받은편지함 이벤트를 받을 수 있는 Custom webhook으로 시작합니다.
Make가 분류 필드를 전송합니다
HTTP 모듈이 카테고리, 우선순위, 상태, 담당자, SLA 목표, 응답 초안, 후속 조치 메모를 전송합니다.
History가 실행 내역을 기록합니다
Make History 패널에서 수동 실행, 작업 수, 크레딧 사용량, 소요 시간, 데이터 전송량을 확인할 수 있습니다.
Jodoo가 티켓을 저장합니다
구조화된 결과가 Jodoo 지원 앱에 기록되어 팀이 이를 필터링하고, 배정하고, 검토할 수 있습니다.
중요 티켓이 계속 가시화됩니다
에스컬레이션된 티켓은 Jodoo 레코드를 기반으로 담당자 큐, SLA 보기, 알림, 대시보드로 이어질 수 있습니다.
데모 요약
Make가 티켓을 분류하고, Jodoo가 에스컬레이션을 추적합니다
이 구현은 지원 접수를 먼저 시각적인 Make 시나리오로 처리한 뒤, 에스컬레이션 후속 조치는 Jodoo를 기준 시스템으로 운영하려는 팀에 적합합니다.
Custom webhook 트리거
지원 payload가 Custom webhook을 통해 Make로 들어옵니다.
HTTP Jodoo에 기록
Make HTTP 모듈이 구조화된 지원 분류 필드를 전송합니다.
History 성공
Make History에 두 번의 작업으로 수동 실행이 성공적으로 완료된 것으로 표시됩니다.
시나리오 사용 내역
테스트된 지원 흐름에 대해 Make 실행이 작업 수, 크레딧, 소요 시간, 데이터 전송량을 기록합니다.
Jodoo Jodoo에 기록
Jodoo가 우선순위, 상태, SLA 목표, 요청자, 카테고리 필드를 저장합니다.
재사용 가능한 루프
Make가 시나리오를 실행하고, Jodoo가 지원 레코드를 유지합니다.
워크플로 키트
같은 Make 지원 분류 루프를 직접 구성해 보세요
지원 필드 매핑을 검토하고, 워크플로 레시피를 복사한 뒤, Make webhook을 실제 지원 소스에 맞게 조정하기 전에 Jodoo 앱 설계도를 활용해 보세요.
팀이 재사용할 수 있는 항목
Make는 Custom webhook으로 티켓 이벤트를 수신하고, HTTP 모듈로 구조화된 분류 결과를 전송하며, History에 작업 수, 크레딧, 소요 시간을 기록합니다. Jodoo는 안정적인 지원 레코드, 에스컬레이션 상태, 담당자 큐, 감사 추적을 유지합니다.
비즈니스 워크플로Jodoo 필드 모델에이전트 프롬프트배포 체크리스트
재사용 가능한 워크플로
워크플로가 판단하고, Jodoo가 업무를 계속 진행시킵니다.
- 01
Make webhook
양식, 포털, 받은편지함, 채팅 대화 기록 또는 내부 시스템
- 02
Make 시나리오
티켓 webhook을 수신하고, HTTP Jodoo에 기록을 전송하며, History에서 실행을 확인합니다
- 03
HTTP 모듈
분류 필드를 JSON post 요청으로 전송하고 응답을 파싱합니다
- 04
Make History
성공 여부, 작업 수, 크레딧, 소요 시간, 데이터 전송량을 보여줍니다
- 05
Jodoo Jodoo에 기록
지원 티켓을 생성하고 data ID를 반환합니다
- 06
지원 후속 조치
SLA 보기, 담당자 큐, 에스컬레이션 상태, 감사 추적
워크플로 루프
Make webhook에서 라우팅된 에스컬레이션까지
양식, 포털, 받은편지함, 채팅 도구 또는 내부 시스템에서 들어온 지원 요청이 Make Custom webhook에 도착합니다.
Run once를 실행하면 Webhooks 모듈이 대기 상태가 되어 들어오는 테스트 payload를 캡처할 수 있습니다.
Make 시나리오는 이벤트를 Webhooks 앱 트리거와 HTTP 앱 Jodoo에 기록으로 구성된 2개 모듈 흐름으로 가시화합니다.
HTTP 모듈은 JSON body, post method, parse response 설정과 저장된 URL을 사용하며, 임시 엔드포인트가 바뀌는 경우 이를 다시 확인해야 합니다.
HTTP 요청은 이슈 카테고리, 우선순위, SLA 목표, 상태, 담당자, 응답 초안, 후속 조치 메모를 JSON으로 전송합니다.
Make History는 수동 실행, 작업 수, 크레딧 사용량, 소요 시간, 데이터 전송량을 기록합니다.
구조화된 결과는 Jodoo Jodoo에 기록 엔드포인트 또는 보안 미들웨어 계층으로 전송됩니다.
Jodoo는 지원 티켓 레코드를 생성하고 이를 SLA 보기, 담당자 큐, 대시보드, 감사 이력에서 활용할 수 있도록 유지합니다.
필드 매핑
에이전트 출력이 Jodoo 필드가 됩니다
| 에이전트 또는 소스 데이터 | Jodoo 레코드 필드 |
|---|---|
| requester_name, requester_email, requester_department | 요청자 이름, 요청자 이메일, 요청자 부서 |
| issue_category, affected_asset | 이슈 카테고리, 영향받은 자산 |
| priority, sla_target, ticket_status | 우선순위, SLA 목표 날짜, 티켓 상태 |
| assigned_owner, routing_reason, follow_up_note | 배정된 담당자, 해결 메모, 후속 조치 메모 |
에이전트 레시피
프롬프트 및 구조화된 출력
워크플로 역할
들어오는 지원 티켓 payload를 수신하고, Jodoo가 저장하고 라우팅하며 보고할 수 있는 구조화된 필드를 반환합니다.
분류 지침
긴급도, 영향도, 카테고리, SLA 위험, 담당자를 기준으로 티켓을 분류합니다. Make HTTP Jodoo에 기록 단계에서 출력값을 예측 가능하게 유지하세요.
필수 출력
ticket_summary, issue_category, priority, sla_target, assigned_owner, ticket_status, response_draft, follow_up_note, routing_reason을 반환합니다.
Make 모듈 계약
워크플로를 지원팀에 넘기기 전에 Webhooks 번들, HTTP method, JSON content type, parse response 설정, 저장된 endpoint URL, Run once 검증을 명확히 유지하세요.
{
"issue_category": "접근 및 권한",
"priority": "긴급",
"sla_target": "2026-06-04 09:00",
"assigned_owner": "지원 에스컬레이션 / ID 팀",
"ticket_status": "에스컬레이션됨"
}Jodoo 스타터 앱
Make 지원 티켓 우선순위 분류 스타터 앱
Make Custom webhook과 Jodoo Jodoo에 기록 워크플로를 구성할 때 이 필드 모델을 사용하세요.
포함된 필드
- 티켓 번호
- 요청자 이름
- 요청자 이메일
- 요청자 부서
- 이슈 카테고리
- 영향받은 자산
- 우선순위
- SLA 목표 날짜
- 티켓 상태
- 배정된 담당자
- 이슈 설명
- 해결 메모
- 후속 조치 메모
- 첨부파일
- 제출 일시
- 원본 에이전트 출력값
추천 보기
- 중요 에스컬레이션
- SLA 위험
- 담당자 큐
- 추가 정보 필요
- Make 실행 검토
- 전체 지원 티켓
자동화 규칙
- Make HTTP 모듈이 완료된 후 Jodoo 지원 티켓 레코드를 생성하거나 업데이트합니다.
- 우선순위가 높음이거나 상태가 에스컬레이션됨이면 배정된 담당자에게 알립니다.
- 정보가 누락된 티켓을 검토 큐로 이동합니다.
- Make History에 HTTP 작업 실패가 표시되면 레코드에 검토 플래그를 표시합니다.
- 원본 워크플로 출력값을 감사 추적에 보관합니다.
배포 체크리스트
운영 적용 전 확인할 사항
- 지원 카테고리, SLA 목표, 에스컬레이션 담당자를 정의합니다.
- 어떤 티켓 소스가 Make webhook을 트리거할지 선택합니다.
- 매번 Run once 테스트 전에 HTTP 모듈 URL이 저장되어 있는지 확인합니다.
- 임시 터널을 사용할 경우 엔드포인트 상태를 점검합니다.
- 모든 Make 출력 필드를 Jodoo 티켓 필드에 매핑합니다.
- 실제 운영 트래픽 전에 가상 티켓으로 테스트합니다.
- 오류 처리, 재시도 알림, 사람 검토 큐를 추가합니다.
워크플로
Make webhook에서 추적 가능한 에스컬레이션까지
Make가 들어오는 이벤트와 Jodoo에 기록 단계를 처리합니다. Jodoo는 팀이 검토, 필터링, 후속 처리할 수 있는 지원 티켓 필드를 저장합니다.
양식, 포털, 받은편지함, 채팅 도구 또는 내부 시스템에서 들어온 지원 요청이 Make Custom webhook에 도착합니다.
Run once를 실행하면 Webhooks 모듈이 대기 상태가 되어 들어오는 테스트 payload를 캡처할 수 있습니다.
Make 시나리오는 이벤트를 Webhooks 앱 트리거와 HTTP 앱 Jodoo에 기록으로 구성된 2개 모듈 흐름으로 가시화합니다.
HTTP 모듈은 JSON body, post method, parse response 설정과 저장된 URL을 사용하며, 임시 엔드포인트가 바뀌는 경우 이를 다시 확인해야 합니다.
HTTP 요청은 이슈 카테고리, 우선순위, SLA 목표, 상태, 담당자, 응답 초안, 후속 조치 메모를 JSON으로 전송합니다.
Make History는 수동 실행, 작업 수, 크레딧 사용량, 소요 시간, 데이터 전송량을 기록합니다.
구조화된 결과는 Jodoo Jodoo에 기록 엔드포인트 또는 보안 미들웨어 계층으로 전송됩니다.
Jodoo는 지원 티켓 레코드를 생성하고 이를 SLA 보기, 담당자 큐, 대시보드, 감사 이력에서 활용할 수 있도록 유지합니다.
Jodoo 레코드
Jodoo가 저장하는 항목
Make 실행 후에도 Jodoo에는 요청자, 카테고리, 자산, 우선순위, SLA 목표, 상태, 담당자, 후속 조치 메모 등 안정적으로 유지되는 지원 필드가 남습니다.
티켓 번호요청자 정보이슈 카테고리영향받은 자산우선순위SLA 목표 날짜티켓 상태배정된 담당자이슈 설명해결 메모후속 조치 메모원본 워크플로 출력값
실행 화면
Make 시나리오가 지원 티켓을 Jodoo에 기록했습니다
스크린샷은 가상의 지원 데이터를 사용했으며, Make 시나리오 캔버스, 성공한 Make History 실행, 그리고 Jodoo에 기록 후의 Jodoo 지원 티켓 테이블을 보여줍니다.
Make 시나리오 구성
Make 캔버스는 Custom webhook과 HTTP 모듈을 사용해 Jodoo Jodoo에 기록 엔드포인트를 호출합니다.
성공한 Make History 실행
Make History에는 작업 수, 크레딧, 소요 시간, 데이터 전송량을 포함해 지원 시나리오가 성공적으로 완료된 것으로 표시됩니다.
Jodoo Jodoo에 기록
Make에서 분류한 티켓이 요청자, 카테고리, 우선순위, SLA 목표, 상태 필드와 함께 Jodoo에 나타났습니다.
FAQ
자주 묻는 질문
Jodoo 레코드, 워크플로, 앱 템플릿과 에이전트 플랫폼을 함께 사용하는 방법에 대한 답변입니다.
이 Make 지원 워크플로는 처음부터 끝까지 테스트되었나요?
네. Make 시나리오의 History 항목에서 수동 실행 성공이 확인되며, Jodoo 테이블에서도 해당 실행으로 생성된 가상의 높은 우선순위 지원 티켓을 확인할 수 있습니다.
유료 Make 요금제가 필요한가요?
검증 실행은 무료 Make 계정과 가상 지원 데이터를 사용했습니다. 실제 운영에서는 작업량, 연결된 서비스, 엔드포인트 사용량에 따라 비용이 발생할 수 있습니다.
티켓 소스가 Jodoo 외부 시스템이어도 되나요?
네. 결과가 Jodoo에 기록되기 전까지는 webhook payload를 Make로 보낼 수 있는 어떤 시스템이든 트리거 소스로 사용할 수 있습니다.
팀이 Make 안에 모델 기반 에이전트 단계를 추가할 수 있나요?
네. 검증된 경로는 안정적인 webhook과 HTTP Jodoo에 기록 흐름을 사용합니다. 카테고리, 우선순위, SLA, 담당자, 상태 필드가 예측 가능하게 유지된다면 Make AI 단계나 연결된 모델 호출을 추가할 수 있습니다.
Make 시나리오 실행 전에 무엇을 확인해야 하나요?
Custom webhook이 데이터 수신 대기 중인지, HTTP 모듈 URL이 저장되었는지, 요청 본문이 JSON인지, 임시 터널을 쓰는 경우 엔드포인트 상태 점검이 통과했는지 확인하세요.
코드 중심 webhook 워크플로와는 어떤 점이 다른가요?
Make는 지원 흐름을 캔버스 위 모듈로 가시화합니다. 빌더는 Jodoo 팀이 티켓을 검토하기 전에 Webhooks 트리거, HTTP 요청, 작업 수, 크레딧 사용량, History 결과를 직접 확인할 수 있습니다.
Make HTTP 모듈이 실패하면 어떻게 되나요?
해당 실행은 완료되지 않은 것으로 처리해야 합니다. 실제 지원 트래픽에 사용하거나 스크린샷을 수집하기 전에 저장된 URL, JSON body, 엔드포인트 상태, Make History 오류를 확인하세요.
테스트 중에는 Make 시나리오를 비활성 상태로 둘 수 있나요?
네. 수동 검증의 경우 예약 실행이나 상시 실행 시나리오를 켜지 않아도 Run once로 webhook 이벤트를 대기할 수 있습니다. 운영 환경에서는 엔드포인트 상태, 할당량, 재시도, 오류 알림 준비가 끝난 후 시나리오를 활성화하세요.
지원 흐름 문제를 점검할 때 어떤 Make 화면이 도움이 되나요?
Jodoo 레코드를 확인하기 전에 Scenario Usage, History, 모듈 번들 출력, HTTP 상태 코드, 데이터 전송량, 작업 수, 크레딧 사용량을 통해 티켓이 Make를 정상적으로 통과했는지 확인하세요.
왜 결과를 Make History가 아니라 Jodoo에 저장하나요?
Make History는 빌더에게 유용하고, Jodoo는 지원팀에 필요한 필드, 보기, 담당자, SLA 큐, 대시보드, 워크플로 상태, 감사 맥락을 제공합니다.
다음 단계
Make 기반 지원 접수를 재사용 가능한 분류 워크플로로 전환
지원 티켓 우선순위 분류부터 시작해, 같은 패턴을 IT 요청, 고객 성공 에스컬레이션, 버그 접수, 현장 서비스 이슈까지 확장할 수 있습니다.