근거를 먼저
회사 문서로 뒷받침되는 내용을 우선하고, 확인되지 않은 설명이나 약속을 줄이는 설계를 지향합니다.
KNOWLEDGE INTO CUSTOMER CARE
답을 찾는 시간은 짧게.
고객을 이해하는 시간은 깊게.
회사 문서에 근거한 LLM 초안, 출처가 보이는 답변, 사람의 최종 판단.
모루는 작은 팀의 지식을 더 나은 고객 응대로 연결합니다.
문서에 근거한 초안확인 가능한 출처담당자의 최종 검토
제품 사용 문의 · 예시
팀원 초대가 보이지 않아요
모루 답변 초안LLM
팀원 초대는 워크스페이스 관리자가 진행할 수 있습니다. 설정의 ‘멤버 관리’에서 ‘초대’를 선택해 주세요. 1
초대 메뉴가 보이지 않는다면, 현재 계정에 관리자 권한이 있는지 먼저 확인해 주세요.
출처를 확인한 뒤 내용과 표현을 검토하세요.
마지막 한 단계는, 담당자의 판단.
고객 상황에 맞게 확인·수정한 후 직접 발송
문서 → 근거가 있는 초안 → 담당자 검토서비스 방향을 설명하는 가상의 문의·문서 예시입니다.
제품을 만드는 팀이
고객지원도 잘할 수 있도록.
B2B SaaS소프트웨어 스타트업작은 고객지원 팀
THE PROBLEM WE CARE ABOUT
답변 하나 뒤에,
너무 많은 일이 있습니다.
도움말을 찾고, 정책을 다시 읽고, 아는 동료에게 묻고.
답을 알고 있는 팀도 답변을 쓰기까지는 시간이 걸립니다.
01
지식은 흩어지고
제품 가이드와 운영 정책, 업데이트된 안내가 서로 다른 곳에 있습니다.
02
문의는 반복되고
비슷한 질문에도 매번 처음부터 문서를 찾고 문장을 다듬어야 합니다.
03
확인은 여전히 사람의 일입니다
그럴듯한 초안이 있어도, 어디서 나온 답인지 모르면 검토가 더 어려워집니다.
ONE CONNECTED WAY TO REPLY
팀의 지식에서 시작해,
확신 있는 답변으로.
모루가 설계하는 고객지원은 세 가지를 연결합니다.
답변의 기준이 되는 문서, 검토할 수 있는 초안, 고객을 아는 담당자.
01 / KNOWLEDGE답변의 기준은
답변의 기준은
이미 팀 안에 있습니다.
제품 가이드, 자주 묻는 질문, 지원 정책.
누가 작성하든 일관된 안내가 가능하도록, 팀이 승인한 지식을 답변의 출발점으로 삼습니다.
- 회사 문서를 중심에 둔 지식 구조
- 최신 문서와 적용 범위를 고려하는 설계
- 근거가 없는 질문은 추가 확인으로 구분
TEAM KNOWLEDGE설계 예시
제품 가이드기능 · 설정 · 이용 방법
제품자주 묻는 질문반복 문의 · 표준 안내
FAQ지원 정책지원 범위 · 예외 조건
정책팀이 승인한 문서가 답변의 기준
02 / GROUNDED DRAFTS좋은 초안에는
좋은 초안에는
확인할 수 있는 근거가.
LLM이 만든 문장만 보여주는 데서 끝나지 않습니다. 어떤 문서를 참고했는지, 어느 부분을 확인해야 하는지 함께 살펴보는 경험에 집중합니다.
- 문의와 관련된 문서에 기반한 답변 초안
- 내용을 대조할 수 있는 출처 표시
- 불확실한 부분을 드러내는 답변 구조
근거를 따라 읽는 답변 예시
“관리자 권한으로 멤버를 초대할 수 있습니다.” 1
1 · 팀원 및 권한 관리
팀원 초대는 관리자에게 제공됩니다.
계정별 실제 권한은 담당자 확인 필요
03 / HUMAN JUDGMENT
제품 원칙 읽기고객에게 닿는 마지막 문장은, 사람이 결정합니다.
문서에 없는 맥락, 고객과의 약속, 미묘한 표현까지.
모루의 중심에는 답변을 검토하고 완성하는 담당자가 있습니다.
MADE FOR EVERYDAY QUESTIONS
익숙한 문의로 보는
모루의 접근 방식.
질문은 달라도 기준은 같습니다. 근거가 있는 내용과 확인이 필요한 내용을 나눕니다.
고객의 질문 · 가상 예시“초대한 팀원이
“초대한 팀원이
관리자 메뉴를 못 봐요.”
역할별 접근 범위와 실제 계정 권한을 나누어 확인해야 하는 제품 사용 문의.
참고할 회사 문서멤버 초대 가이드 / 역할별 권한 안내
답변 구성 예시실제 생성 결과 아님
관리자 메뉴는 관리자 역할에 제공됩니다. 팀원을 초대했더라도 부여된 역할에 따라 표시되는 메뉴가 다를 수 있습니다. 초대한 계정의 역할을 멤버 관리에서 확인해 주세요.
문서로 안내할 부분
역할별 메뉴 접근 범위와 멤버 관리 경로
담당자가 확인할 부분
초대한 계정에 실제로 부여된 역할과 접근 상태
이 섹션의 문의·정책·답변은 제품 방향을 설명하기 위한 가상 사례입니다.
BUILT ON CLEAR PRINCIPLES
많이 답하는 것보다,
제대로 답하는 것.
LLM을 쓰는 이유는 문장을 늘리기 위해서가 아닙니다. 작은 팀이 더 일관되게 고객을 돕는 방법을 만들기 위해서입니다.
불확실성은 분명하게
정보가 부족한 질문은 추가 확인으로 이어져야 합니다. 답변을 보류할 줄 아는 흐름도 품질의 일부입니다.
데이터는 필요한 만큼
개인정보 최소화, 문서 접근 권한, 보관·삭제 기준과 외부 LLM 전달 범위를 제품 설계의 기준으로 삼습니다.
효율은 실제 업무에서
문서와의 일치도, 출처 정확성, 담당자의 수정 부담, 처리 비용과 응답 시간을 함께 평가하는 접근을 지향합니다.
모루WHY WE EXIST
팀이 쌓아온 지식이
고객을 돕는 힘이 되도록.
작은 소프트웨어 팀은 제품을 만들고, 문제를 해결하고, 고객의 질문에도 답합니다. 그 과정에서 쌓이는 지식은 많지만, 필요한 순간에 찾아 쓰기는 쉽지 않습니다.
모루는 그 사이를 연결하는 고객지원 방식을 만듭니다. 회사가 가진 지식을 바탕으로 답변의 초안을 구성하고, 사람이 맥락을 더해 마무리하는 방식입니다.
우리가 지향하는 변화는 단순합니다. 반복적인 탐색에는 적은 시간을, 고객을 이해하고 돕는 일에는 더 많은 시간을 쓰는 것.
OUR MISSION
작은 팀의 지식을,
더 나은 고객 경험으로.
A FEW THINGS TO KNOW
궁금한 점을
확인해 보세요.
모루는 어떤 서비스인가요?
회사 문서에 근거한 LLM 답변 초안과 출처 확인, 담당자의 최종 검토를 연결하는 고객지원 서비스를 지향합니다. 제품 문서와 도움말은 있지만 고객지원 인력이 충분하지 않은 소프트웨어 팀에 집중합니다.
지금 사용할 수 있나요?
현재 공개 서비스는 제공하지 않습니다. 제공 범위와 이용 안내는 이 페이지에서 업데이트합니다.
고객에게 답변이 자동으로 발송되나요?
모루의 제품 방향은 담당자의 검토를 중심에 둡니다. 문서와 초안을 대조하고, 고객 상황에 맞게 수정한 뒤 사람이 직접 발송하는 흐름을 우선합니다.
문서에 답이 없으면 어떻게 하나요?
근거가 부족한 내용은 추측으로 채우기보다 확인이 필요하다고 구분하는 것이 설계 원칙입니다. 계정 상태나 개별 계약 조건처럼 문서만으로 알 수 없는 정보는 담당자가 확인해야 합니다.
문서가 오래되었거나 서로 다르면 어떻게 하나요?
최신 버전과 적용 범위를 구분하고, 충돌하는 내용은 담당자가 확인할 수 있어야 합니다. 문서가 있다는 이유만으로 답변을 확정하지 않는 것이 설계 원칙입니다.
페이지에 보이는 화면은 실제 제품인가요?
서비스 방향과 검토 흐름을 설명하는 화면 예시입니다. 문의, 문서, 답변은 가상으로 작성했으며 실제 고객 데이터나 LLM 실행 결과가 아닙니다.
KNOW YOUR ANSWER. OWN YOUR REPLY.