지식 베이스는 그 안의 문서만큼만 유용합니다. Trupeer를 사용하면 바로 사용할 수 있는 지식 베이스 문서 템플릿으로 시작해 브랜드 가이드라인에 맞게 커스터마이징하고, 텍스트가 많은 문서를 고객과 직원이 실제로 참여할 수 있는 명확한 비디오 워크스루로 전환하여 지식 베이스 문서 작성에 드는 시간을 몇 시간씩 절약할 수 있습니다.

지식 베이스 문서란 무엇이며, 템플릿은 무엇을 해결하나요?

지식 베이스 문서는 검색창에서 문제를 이미 염두에 둔 사람이 도착했을 때 그 사람에게 제공하는 하나의 독립된 답변입니다. 문서는 시스템을 설명하는 것이고, 매뉴얼은 순서대로 읽기 위한 것이지만, 지식 베이스 문서는 그렇지 않습니다.

템플릿은 세 가지를 해결합니다. 문서 작성자가 매번 구조를 새로 만들지 않게 하여, 그 과정에서 사라지는 시간을 막습니다. 독자가 어디를 봐야 하는지 학습할 만큼 문서를 일관되게 만듭니다. 그리고 혼자 두면 작성자가 건너뛰는 필드를 강제로 채우게 하는데, 그 필드들은 거의 항상 단계가 빠지는 원인이 됩니다.

하지만 템플릿이 해결할 수 없는 것은 있습니다. 아무도 검색할 수 없는 라이브러리, 잘못된 주제에 대한 문서, 그리고 업데이트를 전혀 하지 않는 팀입니다.

지식 베이스 문서가 실패하는 지점은 ‘가운데’가 아니라 ‘가장자리’입니다

형편없는 지식 베이스 문서를 읽어보면 보통 글 자체는 괜찮습니다. 단계는 맞고, 스크린샷은 최신이며, 누군가 그 주제를 분명히 알고 있었습니다.

문제가 생기는 건 경계입니다. 문서는 상황의 한 버전을 설명하지만, 독자는 약간 다른 버전을 보고 있고, 그 사실을 알려주는 것이 없습니다. 독자는 그대로 따라 하고, 조용히 작동하지 않으며, 결국 어쨌든 티켓을 올립니다. 아무것도 찾지 못했을 때보다 더 짜증 난 상태로요.

데이터에서는 이를 모든 헬프 센터에서 가장 이상한 패턴처럼 보이게 됩니다. 같은 주제에서 조회는 높고 티켓도 높은 문서가 있는 경우죠. 문서는 발견됩니다. 읽힙니다. 그런데 아무것도 해결해주지 못합니다.

해결책은 더 나은 글쓰기가 아닙니다. 대부분의 템플릿에는 없는 두 줄을 추가하는 것입니다. 이 문서가 무엇을 다루는지, 그리고 그게 아니라면 어디로 가야 하는지를 가장 먼저 말해주는 두 줄 말이죠.

Trupeer에서 이 템플릿을 커스터마이징하는 방법

1단계: 템플릿 섹션 열기

메인 내비게이션에서 템플릿 섹션으로 이동하세요.

2단계: 템플릿 선택 후 열기

작업할 템플릿을 클릭해 열어보세요.

3단계: 템플릿 보기 확장

필요한 경우 템플릿 보기를 확장해 전체 레이아웃과 세부 정보를 더 명확히 확인하세요.

4단계: 템플릿 편집

선택한 템플릿을 수정하기 시작하려면 Edit을 클릭하세요.

편집기에서 다음을 할 수 있습니다:

• 새 섹션 추가

• 서식 규칙 정의 또는 업데이트

• 로고를 추가하고 위치 및 관련 설정을 조정

5단계: 커스터마이징한 템플릿 저장

필요한 모든 변경을 마친 후 Save를 클릭해 업데이트된 템플릿을 본인 템플릿으로 저장하세요.

6단계: 미리보기 및 템플릿 미세 조정

커스터마이징한 템플릿이 어떻게 보이는지 확인하려면 Preview를 여세요.

미리보기 화면에서 필요하다면 직접 계속 조정할 수 있어, 템플릿이 원하는 그대로 정확히 표시되도록 할 수 있습니다.

지식 베이스 문서 템플릿으로 할 수 있는 일:

• 문서 작성 시간을 절약: 가이드, FAQ, 문제 해결 문서에 대한 검증된 구조를 사용하세요.

• 지원 티켓 감소: 명확한 문서는 사용자가 셀프 서비스로 해결하도록 도와 지원 부담을 줄이고, 더 어려운 이슈에 에이전트를 집중할 수 있게 합니다.

• 브랜드에 맞게 유지: Trupeer의 브랜드 키트를 사용해 로고, 글꼴, 색상을 적용하면 모든 문서가 제품에 속한 것처럼 보입니다.

• 찾기 쉬움 개선: 표준 구조로 문서를 더 쉽게 훑어보고, 검색하고, 업데이트할 수 있습니다.

• 전 세계로 로컬라이즈: 클릭 한 번으로 지식 베이스 문서를 65+개 언어로 번역하세요.

• 비디오 워크스루 추가: 텍스트만으로는 설명하기 어려운 단계에 임베디드 비디오를 함께 제공하세요.

모든 지식 베이스 문서 템플릿에 필요한 두 줄

범위(scope) 줄. 이 문서가 적용되는 상황을 독자의 표현으로 한 문장으로 명명하세요. “이 문서는 Standard 플랜 계정에 적용됩니다”가 아니라 “이메일 주소와 비밀번호로 로그인하면”처럼요. 독자는 자신이 볼 수 있는 어떤 것과 비교해 확인할 수 있어야 합니다.

출구(exit) 줄. 가장 흔한 인접 상황을 한 문장으로 명명하고 연결하세요. “회사에서 단일 로그인을 사용한다면 여기로 가세요.”

두 줄은 단계 위에 두세요. 아래쪽의 참고 메모에 넣지 마세요. 지침을 따라 시작한 독자는 주의 사항에서 멈추지 않고, 잘못된 문서에 들어온 독자는 약 8초 안에 떠나야 합니다.

중요한 건 ‘줄’보다 ‘규율’입니다. 출구 줄을 쓰면 인접한 케이스를 반드시 이름 붙이게 되고, 이름을 붙이다 보면 보통 그중 두세 개는 애초에 문서가 없다는 사실이 드러납니다.

지식 베이스 문서 유형과 각각을 언제 사용하나요?

가장 흔한 구조적 오류는 문제 해결 문서를 방법(How-to)으로 쓰는 것입니다. 독자가 아직 무엇이 잘못됐는지 모르는 상태라면 번호 단계는 형태가 맞지 않습니다. 1단계가 독자가 아직 내리지 않은 진단을 전제로 하기 때문이죠. 증상에서 시작해 분기하세요. 저희의 방법(How-to) 문서 템플릿은 첫 번째 행을 더 깊게 다룹니다.

무료 지식 베이스 문서 템플릿: 복사할 구조

여기서부터 복사하세요. 필수로 표시된 필드는 문서 유형과 관계없이 모든 문서에 유지됩니다.

제목, 필수. 독자의 질문을 독자의 말로 적으세요. “저는 로그인할 수 없어요”가 “인증 문제 해결”보다 낫습니다. 문제를 설명하는 문장이 아니라 라벨처럼 쓴 제목은, 좋은 문서가 절대 검색되지 않는 가장 흔한 이유입니다.

검색어, 필수. 사람들이 실제로 쓰는 대체 표현 3~6개를 입력하세요. 직접 만들어내지 말고, 제로 결과 검색 로그에서 가져오세요. 대부분의 플랫폼에는 이 필드가 있고, 대부분의 팀은 비워둡니다.

범위 줄, 필수. 위와 동일합니다.

출구 줄, 필수. 위와 동일합니다.

답변 또는 첫 단계, 필수. 짧은 질문이라면 답변을 두 줄 안에 완결되게 작성하세요. 절차라면 1단계. 출구 줄과 이 부분 사이에는 아무것도 두지 말고, 특히 문서가 무엇에 관한 것인지 설명하는 서두도 넣지 마세요.

본문. 유형에 따라 단계, 분기 또는 표를 작성하세요.

이렇게 해도 안 될 때. 다음에 해야 할 일을 명확히 적으세요. 다른 특정 문서, 양식, 또는 큐(queue)입니다. “지원팀에 문의”가 아닙니다.

소유자 및 마지막 검증 날짜. 한 사람과, 누군가가 마지막으로 문서가 여전히 현실과 일치한다고 확인한 날짜를 적으세요. 문구를 편집한 날짜가 아닙니다.

여기까지 복사하세요. 특정 문서에서 어떤 필드가 불필요하게 느껴지면, 템플릿에서 제거하지 말고 해당 문서에서 삭제하세요. 작성자가 건너뛰는 필드가 바로 ‘일을 하고 있던’ 필드였기 때문입니다.

네 가지 일반 유형을 위한 지식 베이스 문서 템플릿 예시

FAQ. 제목: “청구일을 변경할 수 있나요?” 범위: 매달 청구되는 계정. 답변(처음 두 줄): 네, 청구 주기당 한 번이며 Billing에서 Schedule로 변경하고, 변경은 다음 주기에 적용됩니다. 출구: 연간 플랜은 여기로 가세요. 이게 문서 전체입니다.

방법(How-to). 제목: “작업 공간에 사용자를 추가하기”. 범위: 사용자는 관리자입니다. 출구: Settings를 볼 수 없다면 관리자가 아니므로, 본인 관리자에게 요청하세요. 단계: 4개, 각 단계에 예상 결과가 포함됩니다. 그다음: 초대가 오지 않는다면 무엇을 해야 하는지.

문제 해결(Troubleshooting). 제목: “내보내기는 끝났는데 파일이 비어 있어요”. 범위: Reports 화면에서의 내보내기. 첫 번째 분기는 독자가 도움 없이 확인할 수 있는 것(보통 날짜 범위)입니다. 두 번째 분기는 권한입니다. 세 번째는 알려진 한도입니다. 각 분기는 해결됨 또는 명시된 다음 단계 중 하나로 끝납니다.

알려진 오류. 제목: “EU 계정의 보고서가 지연됩니다”. 상태, 누가 영향을 받는지, 그동안 무엇을 해야 하는지, 다음 업데이트가 언제 게시되는지, 그리고 마지막 업데이트 시간. 이 필드는 독자가 실제로 확인하는 항목입니다.

지식 베이스 문서 예시: 조회는 높고 티켓도 높은 경우

약 1만 1천 개의 비즈니스 고객을 가진 급여(payroll) 제품 Loxwell은 대략 1,100개의 문서로 구성된 헬프 센터와 평판이 좋은 콘텐츠 팀을 보유하고 있었습니다.

비밀번호 재설정 문서는 분기당 약 14,200회의 조회를 받았습니다. 같은 기간의 비밀번호 티켓은 약 900건 수준이었고, 2년 동안 거의 변하지 않았습니다. 두 수치는 매달, 서로 다른 덱(deck)에서 서로 다른 사람들에게 보고되었습니다.

누군가 결국 둘을 나란히 놓아 비교했습니다. 문서는 표준 재설정을 다뤘습니다. 이메일을 입력하고 링크를 클릭한 뒤 새 비밀번호를 선택하세요. 비밀번호 티켓의 약 60%는 단일 로그인이 활성화된 회사의 사용자에게서 나왔는데, 이 경우 재설정 링크는 유용한 일을 하지 못합니다. 신원 제공자(Identity provider)가 비밀번호를 보유하고 있기 때문이죠. 문서에는 단일 로그인이 언급되지 않았습니다. 이 독자들은 문서를 찾아 따라 했고, 오류 메시지 없이 실패하는 것을 보고, 결국 티켓을 열었습니다.

해결에는 오후 한때면 충분했습니다. 기존 문서 상단에 표준 케이스를 명명하고 단일 로그인 사용자는 다른 곳으로 안내하는 두 줄을 추가하고, 그 사용자들을 위한 짧은 새 문서를 하나 더 만들었습니다. 그리고 사람들이 실제로 검색창에 입력하던 문구를 양쪽 모두에 추가했죠.

비밀번호 티켓은 다음 분기에 약 310건으로 떨어졌습니다. 원래 문서의 조회도 약 9,800으로 함께 감소했는데, 이 하락은 회귀가 아니라 성공이었습니다. 그 독자 중 4,000명은 잘못된 문서에 들어가 있었던 것입니다.

같은 오후에 두 번째 숫자도 드러났습니다. 1,100개 문서 중 12개월 동안 조회가 전혀 없었던 문서는 340개였습니다. 그 문서들에도 문제가 있던 건 아니었습니다.

좋은 지식 베이스 문서를 단계별로 작성하는 방법

기능이 아니라 티켓부터 시작하세요. 해당 주제의 마지막 10개 티켓을 열고, 각 티켓에서 고객이 직접 쓴 첫 문장을 읽어보세요. 그 문장이 제목이고, 그 단어들이 검색어입니다.

범위 줄은 다른 무엇보다 먼저 작성하세요. 한 문장으로 ‘누구를 위한 것인지’ 명확히 말할 수 없다면, 주제가 너무 넓은 것이며 문서가 두 개여야 합니다.

출구 줄 바로 다음에 답변 또는 첫 단계를 작성하세요. 서두를 넣지 마세요. 검색 결과에서 들어온 사람에게 이 문서가 무엇에 관한 것인지 설명할 필요는 없습니다.

본문을 작성한 뒤, 시스템이 왜 이런 방식으로 작동하는지 설명하는 모든 문장을 잘라내세요. 그 내용은 documentation에 있어야 하며, 문서에서는 유용한 부분이 접히는 영역 아래로 밀려납니다.

명시된 다음 단계와 소유자로 마무리한 뒤, 문제를 가진 누군가에게 넘기고 그 사람이 도움 없이도 사용하게 되는지 지켜보세요.

모든 지식 베이스 문서 템플릿에 무엇이 포함되어야 하나요?

총 6개 필드가 필요하며, 이 순서대로 작성합니다. 독자의 문제로 표현한 제목, 대체 검색어, 범위 줄, 출구 줄, 답변 또는 첫 단계, 그리고 실패 시의 명시된 다음 단계. 소유자와 마지막 검증 날짜는 메타데이터에 포함됩니다.

그 외의 모든 것은 유형별로 달라집니다. 단계, 분기, 표, 상태 블록, 스크린샷은 문서 유형에 따라 모두 달라지며, 모든 문서에 대해 템플릿이 이를 강제하면 결과적으로 FAQ가 부풀려지고 문제 해결 가이드는 얇아지는 일이 똑같이 발생합니다.

기존 지식 베이스에 템플릿을 적용하는 방법

전체 라이브러리를 소급 적용하지 마세요. 문서 90개쯤에서 멈춰버리고, 눈에 띄게 다른 두 가지 기준을 그대로 남겨두는 팀이 생기는데, 이는 하나의 나쁜 것보다 더 나쁩니다.

고정된 날짜 이후에 새로 작성되는 문서에는 템플릿을 적용하세요. 그다음 조회가 가장 많은 기존 문서 20개를 가져와 범위 줄, 출구 줄, 검색어만 추가하고 본문은 건드리지 마세요. 이 20개 문서는 보통 전체 조회의 큰 비중을 차지하므로, 회수는 분기보다 더 짧은 보름 안에 도착합니다.

그 이후에는 티켓이 주도하게 두세요. 티켓을 생성하는 어떤 문서든, 해당 티켓이 닫힐 때 그 문서는 다시 작업됩니다. 닫은 사람이 다시 다듬는 방식입니다. 라이브러리는 중요한 순서대로 스스로 전환되고, 취소되는 문서 스프린트를 누가 계획하지 않습니다.

지식 베이스 문서 성과는 어떻게 측정하나요?

조회수만으로는 거의 아무것도 알 수 없습니다. 위의 예시가 이를 보여줍니다. 각 문서를 해당 주제의 티켓 볼륨과 함께 두고, 함께 읽어보세요. 조회는 높고 티켓도 높다면 문서는 발견되지만 실패한 것입니다. 조회는 낮고 티켓은 높다면 문서가 없거나 찾기 어렵다는 뜻이며, 같은 증상을 가진 서로 다른 문제입니다. 조회와 티켓이 모두 낮다면 보통 삭제하면 됩니다.

노력할 만한 다른 숫자도 두 가지가 있습니다. 제로 결과 검색 로그(고객이 찾았지만 여러분에게 없는 것들의 목록)와, 최근 6개월 동안 검증된 문서의 비율입니다. 둘 다 보통 오후 한때면 확인할 수 있고, 대부분의 리포트에는 나타나지 않습니다.

리라이트(재작성) 사이클 없이 지식 베이스 문서를 유지하는 방법

정기 검토 주기는 실패합니다. 아무것도 바뀌지 않은 시점에 도착해, 변화가 생긴 순간을 놓치기 때문입니다. 대신 트리거를 사용하세요.

문서가 이미 존재하는데도 티켓이 제기되면, 문서에서 설명하는 인터페이스가 변경되면, 제로 결과 로그에서 문서가 있어야 할 표현으로 나타나면, 그리고 소유자가 떠나면 문서를 다시 검증하세요. 네 가지 조건 중 모두에 대해 12개월 동안 아무것도 일어나지 않은 문서는 검토 후보가 아니라 삭제 후보입니다.

팀들이 피하려는 건 삭제입니다. 조회되지 않은 문서 340개는 조용히 있지 않습니다. 검색 결과를 희석시키고 유용한 문서에 도달하기 어렵게 만듭니다. 계속해서만 늘어나는 라이브러리는 유지 관리가 되고 있는 것이 아닙니다. 더 넓은 규율이 중요한 지점에서는, 전체 자산에 걸친 소유권과 라이프사이클을 다루는 knowledge management template을 참고하세요.

Word 또는 Excel에서 지식 베이스 문서 템플릿을 받을 수 있나요?

팀이 게시 전에 문서를 작성한다면 Word는 문서 자체에 적합합니다. 다만 헬프 센터에서 직접 작성하는 편이 보통 더 빠른데, 렌더링과 검색 필드를 바로 볼 수 있기 때문입니다. Excel은 문서 인덱스(소유자, 유형, 마지막 검증 날짜, 조회수, 티켓 볼륨이 포함된 모든 문서 목록)에 적합하며, 이 인덱스가 위의 측정이 가능하게 해줍니다.

두 가지 중에서는 인덱스가 더 가치가 있고, 거의 아무도 만들지 않습니다. 6개 열과 월간 내보내기만으로도 어떤 템플릿보다 지식 베이스에 대해 더 많은 정보를 알려줄 수 있습니다.

지식 베이스 웹사이트 템플릿과 HTML: 이 페이지가 아닌 것

이 용어를 검색하는 일부 사람들은 지식 베이스 웹사이트 템플릿이나 HTML 테마를 원합니다. 즉, 문서 자체가 아니라 문서를 담고 있는 사이트를 의미하죠. 이 페이지는 그런 용도를 제공하지 않으며, 그렇게 보이도록 꾸며서도 안 됩니다.

두 결정이 서로 무관하기 때문에, 이 구분은 명확히 해두는 것이 가치가 있습니다. 헬프 센터 플랫폼이나 테마를 고르는 것은 검색, 내비게이션, 모바일 렌더링, 권한에 대한 웹 및 디자인 결정입니다. 문서 구조는 작성에 대한 결정입니다. 범위 줄이 없는 문서로 가득한 아름다운 헬프 센터도 결국 티켓을 만들고, 좋은 문서로 가득한 단순한 헬프 센터도 그렇지 않습니다.

문서에 무엇을 넣을지보다 문서가 어디에 ‘살게 될지’를 고르는 중이라면, 저희의 knowledge base template에서 구조, 카테고리, 소유권을 다룹니다.

스크린 레코딩을 지식 베이스 문서로 바꾸는 방법

모든 헬프 센터에서 병목은 무엇을 써야 하는지 모르는 데 있지 않습니다. 답을 아는 사람이 이미 문제를 해결하고 다음으로 넘어가 버려서, 정리해 쓰는 데 필요한 한 시간이 그 사람에게 없다는 데 있습니다.

Trupeer AI는 스크린 레코딩을 포맷된 문서로 바꾸고, 단계와 스크린샷을 제자리에 배치합니다. 그래서 해결한 사람이 한 번만 수정하고 기록하면 되고, 새로 쓰지 않아도 됩니다. 제목, 범위 줄, 출구 줄은 직접 추가하세요. 그 부분은 판단이 필요한 영역이고, 나머지는 전사(Transcription)이기 때문입니다.

기록하세요. 브랜드를 입히세요. 번역하세요. Trupeer하세요.

같은 레코딩으로, 보는 것을 선호하는 독자에게는 비디오를, 지식 베이스에는 문서를 제공할 수 있으며, 스타일 가이드를 누가 유지 관리하지 않아도 모든 문서에 일관된 서식을 적용할 수 있습니다. 번역은 대부분의 다른 곳보다 여기서 더 중요합니다. 한 언어의 헬프 센터가 다른 모든 고객을 조용히 여러분의 support queue로 라우팅하기 때문입니다. Guides에서는 더 넓은 워크플로를 다루고, 설정 지침은 document template setup guide에 있습니다.

자주 묻는 질문

Word에서 무료 지식 베이스 문서 템플릿을 사용할 수 있나요?

위의 6개 필드 구조는 Word 또는 Google Docs에 그대로 붙여 넣고, 초안 작성용 틀로 계속 사용할 수 있도록 작성되었습니다. 다운로드를 위한 별도 절차가 없다는 뜻이기도 하며, 따라서 여러분과 구조 사이에 폼도 없습니다. 대부분의 팀은 Word 버전을 한 달 안에 더 이상 사용하지 않고 대신 헬프 센터에서 초안을 작성하는데, 이 또한 괜찮고 더 빠릅니다.

Excel에서 지식 베이스 템플릿을 사용할 수 있나요?

문서가 아니라 문서 인덱스에 Excel을 사용하세요. 제목, 유형, 소유자, 마지막 검증 날짜, 이번 분기 조회수, 그리고 이 주제의 티켓. 이 시트는 헬프 센터를 페이지 더미에서 관리 가능한 형태로 바꿔주며, 설정하는 데 약 한 시간이 걸립니다.

지식 베이스 문서 템플릿 예시는 어디에서 찾을 수 있나요?

위의 예시 섹션에 FAQ, 방법(How-to), 문제 해결, 알려진 오류를 다루는 4개의 완성 예시가 있습니다. 더 유용한 연습은 본인이 가장 많이 조회되는 문서 3개를 가져와 각 문서에 범위 줄과 출구 줄을 추가하는 것입니다. 여러분의 예외 케이스는 제품에 따라 구체적이며, 어떤 예시도 그 케이스를 그대로 담고 있지 않기 때문입니다.

Word에서 무료 FAQ 템플릿을 사용할 수 있나요?

FAQ 문서는 다른 어떤 유형보다 구조가 덜 필요합니다. 질문을 제목으로 하고, 고객이 묻는 그대로 표현하세요. 답변은 두 줄 안에 완결되게 작성하고, 그 외에는 아무것도 넣지 마세요. 답변이 두 줄에 들어가지 못한다면 FAQ가 아니라, 잘못 라벨링된 방법(How-to) 또는 문제 해결 문서입니다.

Zendesk Guide용 문서 템플릿이 있나요?

Zendesk Guide는 테마 시스템을 통해 문서 템플릿을 지원하며, 위의 6개 필드는 여기에 문제없이 매핑됩니다. 제목과 검색 키워드는 기본 필드이고, 범위 줄과 출구 줄은 본문 상단에 배치됩니다. 여기의 구조는 의도적으로 플랫폼과 무관하게 설계되어 있는데, 팀이 예상보다 더 자주 헬프 센터를 마이그레이션하기 때문입니다.

무료 HTML 지식 베이스 템플릿이 있나요?

그건 다른 산출물입니다. 즉, 문서가 아니라 사이트를 의미하며, 이 페이지가 아닌 것에 대한 위 섹션에서 다룹니다. 테마가 적용된 헬프 센터가 필요하다면, 대부분의 플랫폼에 기본으로 제공되며 커스터마이징은 작성이 아니라 프론트엔드 작업입니다.

무료 지식 베이스 웹사이트 템플릿이 있나요?

동일한 답변입니다. 컨테이너를 선택하는 것은 검색 품질, 권한, 모바일 렌더링에 의해 좌우되는 플랫폼 결정입니다. 이 페이지의 어떤 내용도 선택을 도와주지 않으며, 문서 구조는 테마보다 티켓 볼륨에 더 큰 영향을 미칩니다.

지식 베이스 문서는 얼마나 길어야 하나요?

답변이 휴대폰에서 스크롤 없이도 보일 만큼 짧아야 합니다. FAQ는 두 줄이면 됩니다. 방법(How-to)은 약 9단계 미만, 그 이상이면 보통 두 개의 문서가 됩니다. 길이가 목표는 아닙니다. 목표는 독자가 8초 안에 자신이 올바른 위치에 있는지 알 수 있어야 한다는 점입니다.

누가 지식 베이스 문서를 작성해야 하나요?

문제를 해결한 사람이 작성해야 하며, 라이브러리를 소유한 사람이 편집해야 합니다. 티켓 요약을 바탕으로 문서 팀이 작성한 문서는 고객의 고유한 표현을 잃게 되는데, 그 표현이 다음 고객이 검색할 단어이기 때문입니다. 올바른 제목을 가진 지원 에이전트의 거친 문서가, 아무도 찾지 못하는 완성형 문서보다 낫습니다.