오늘 볼 자동화 포인트
이번에 볼 툴들은 고객과 나눈 대화에서 변경 사항을 찾고, 반복 질문에 답하고, 제품 안에서 실제 작업을 실행하는 구간을 다뤄요. 세 가지를 모두 하나의 챗봇으로 묶기보다, 기억할 정보와 답변할 내용, 실행할 기능을 따로 나누는 편이 도입 범위를 잡기 쉬워요.
아래 설명은 수집 자료와 공식 제품 소개를 대조해 정리했어요. 활용 예시는 적용을 검토할 업무 흐름이며, 세 제품 간 기본 연동이나 실제 운영 성과를 검증했다는 뜻은 아니에요.
한눈에 비교
표는 좌우로 움직여 확인할 수 있어요.
| 툴 | 핵심 용도 | 잘 맞는 업무 | 주의할 점 |
|---|---|---|---|
| Bracket | 고객 대화의 범위·결정·마감 변경 정리 | 프로젝트 인수인계, 요구사항 변경 확인 | 지원 소스와 원문 접근 권한 확인 필요 |
| Chat.sh | 공개 도움말을 근거로 질문에 답변 | 반복 사용법 문의, 온보딩 문서 검색 | 최신 공개 문서 관리와 답변 검수 필요 |
| Yedric.ai | 자연어 요청을 제품 기능 실행으로 연결 | SaaS 설정, 반복 입력·관리 작업 | 사용자별 실행 권한과 중요 변경 승인 필요 |
Bracket
고객 대화가 바뀔 때 프로젝트의 범위·요구사항·결정·마감을 함께 정리해요.
Bracket은 고객 프로젝트가 진행되는 대화를 연결해 업무 맥락을 유지하는 도구예요. 공식 소개에서는 Gmail 대화 또는 지원하는 다른 소스를 연결하고, 의미 있는 변경이 생기면 무엇이 달라졌고 어디에 영향을 주는지 보여주는 흐름을 설명해요.
메일을 다시 읽으며 요구사항을 재구성하는 작업을 줄이는 데 초점이 있어요. 다만 변경 감지 결과가 곧 계약이나 일정의 확정은 아니므로, 담당자가 원문과 영향 범위를 확인한 뒤 승인하는 단계가 필요해요.
이런 분들한테 맞아요
고객 메일을 읽고도 나중에 “언제 범위가 바뀌었지?”를 다시 찾는 일이 잦다면, 대화에서 변경 후보를 모으는 구간부터 정리할 수 있어요. 인수인계 때도 최신 결정과 아직 합의하지 않은 요청을 구분해 넘기는 데 활용할 수 있어요.
다만 고객별로 연결할 대화를 제한하고, 실제 지원하는 소스·삭제 정책·접근 권한을 도입 전에 확인해야 해요.
Bracket 활용 예시
고객 프로젝트 대화 연결 → 범위·마감 변경 후보 확인 → 담당자가 원문과 영향 검토 → 고객 합의 여부 확인 → 승인된 변경만 프로젝트 기록에 반영
Chat.sh
도움말 문서에서 질문에 맞는 답을 만들고 사용한 근거 페이지를 함께 보여줘요.
Chat.sh는 자사 도메인이나 사이트의 특정 폴더에 도움말 센터를 제공하는 도구예요. 문서·링크·파일을 지식베이스로 모으고, 질문의 의미에 맞춰 답변과 근거 페이지를 제시하는 방식으로 소개돼요.
공식 사이트는 도움말 센터를 현재 제공 기능으로, 채팅 위젯과 상담원 인수인계용 받은편지함을 향후 제공 기능으로 구분해요. 따라서 지금은 반복 사용법 문의를 문서 검색으로 처리하는 범위부터 검토하는 게 맞고, 상담 전체를 대체한다고 보면 안 돼요.
이런 분들한테 맞아요
같은 설정 방법이나 사용법을 고객에게 반복해서 설명하고 있다면, 승인된 도움말을 질문 중심으로 찾아주는 경로를 만들 수 있어요. 고객이 답변과 함께 원문을 확인하게 하면 담당자가 일일이 링크를 고르는 작업도 줄일 수 있어요.
다만 공개용 문서만 넣고, 요금·환불·정책처럼 틀리면 문제가 되는 답변은 표본 질문으로 검수해야 해요. 아직 제공되지 않는 채팅·인수인계 기능에 운영을 의존하지 않는 게 좋아요.
Chat.sh 활용 예시
반복 문의 분류 → 최신 도움말 작성·승인 → 공개 지식베이스 반영 → 고객 질문에 근거 링크와 답변 제공 → 해결되지 않은 질문은 별도 문의 경로로 연결 → 담당자가 문서 보완
Yedric.ai
사용자의 말로 된 요청을 앱이 허용한 기능 호출로 바꿔 실제 작업을 진행해요.
Yedric.ai는 기존 제품에 AI 도우미를 넣고, 제품 문서와 API·도구를 연결하는 방식이에요. 공식 사이트는 Shopify 앱 사례를 제시하며, 사용자가 원하는 결과를 말하면 연결된 기능을 호출하는 구조를 설명해요.
도움말로 작업 방법을 알려주는 것과 실제 설정이나 데이터를 바꾸는 것은 다른 단계예요. 제공자가 노출한 기능과 권한 안에서 실행하는 도구라서, 연결할 API와 사용자 인증, 실행 기록을 제품 담당자가 설계해야 해요.
이런 분들한테 맞아요
고객이 사용법을 알아도 메뉴를 여러 번 눌러야 하거나, 담당자가 같은 설정 요청을 대신 처리하고 있다면 자연어로 실행 가능한 작업을 작게 정해볼 수 있어요. 처음에는 조회나 되돌릴 수 있는 초안 생성부터 열고, 중요한 변경은 결과 미리보기와 승인 단계를 두는 편이 좋아요.
다만 사용자별 권한을 서버에서 확인하고, 대량 수정·금액 변경·외부 발송은 별도 승인 없이는 실행되지 않도록 연결해야 해요.
Yedric.ai 활용 예시
사용자 요청 접수 → 로그인 사용자와 대상 데이터 확인 → 허용된 기능으로 조회·변경안 생성 → 중요한 변경은 사용자 승인 → API 실행 → 결과와 실패 내역 기록
이 업무를 자동화할 때 먼저 볼 기준
같은 질문인가, 바뀐 합의인가
사용법 질문은 승인된 도움말로 처리하고, 프로젝트 범위나 마감 변경은 원문과 합의 여부를 확인하는 별도 흐름으로 남겨요.답변 근거와 실행 권한은 따로 열어요
문서를 읽을 권한이 있다고 고객 데이터 수정까지 허용하면 안 돼요. 조회·초안·실행별로 필요한 기능과 데이터 범위를 나눠요.해결되지 않은 질문과 실패한 실행이 돌아올 곳을 정해요
근거가 없거나 작업이 실패했을 때 담당자가 확인할 경로를 두고, 원문·대상·실행 결과를 남겨 중복 처리와 누락을 줄여요.
고객 응대 자동화에서 자주 막히는 질문
Q. 도움말 답변부터 시작할까요, 실제 업무 처리까지 연결할까요?
A. 반복 문의 중 승인된 문서만으로 해결되는 질문부터 분리하면 검수 범위가 작아져요. 실제 처리는 사용자 인증과 대상 데이터가 명확하고, 실패하거나 잘못 실행했을 때 되돌릴 수 있는 기능부터 붙이는 게 좋아요.
Q. 고객 메일과 내부 문서를 같은 지식베이스에 넣어도 되나요?
A. 공개 도움말과 고객별 프로젝트 대화는 접근 대상이 달라요. 공개 답변용 자료와 내부 변경 추적용 자료를 분리하고, 고객 정보가 다른 고객의 답변에 섞이지 않도록 권한·보관·삭제 조건을 확인해야 해요.
Q. AI가 변경을 감지하면 일정이나 설정을 바로 바꿔도 되나요?
A. 요청이 들어왔다는 사실과 변경에 합의했다는 사실은 구분해야 해요. 일정·금액·대량 데이터처럼 영향이 큰 변경은 원문과 대상, 변경안을 사람이 확인한 뒤 실행하고, 승인과 실제 반영 결과를 함께 기록하는 게 안전해요.
한 줄 정리
고객 응대 자동화는 질문을 잘 이해하는 것에서 끝나지 않아요. 대화 속 변경을 기억하는 단계, 근거를 찾아 답하는 단계, 실제 기능을 실행하는 단계를 나누면 필요한 도구와 사람의 확인 지점이 선명해져요.
고객 문의나 프로젝트 변경 요청이 쌓이고 있다면, 반복 질문은 어디까지 답변으로 해결하고 중요한 변경은 어디서 승인할지 현재 흐름부터 정리해볼 수 있어요.
