문서·지식 베이스
사람들이 실제로 찾을 수 있는 문서.
문서·지식 베이스
이 카테고리에 속하는 도구
다른 사람이 찾을 수 있도록 글로 남기는 곳입니다. 고객용 헬프 센터, 사내 핸드북, 개발자 문서, 그리고 이 모든 것을 쓸모 있게 만드는 검색이 여기에 속합니다.
중요한 구분은 독자입니다. 고객용 문서에는 공개 주소, 검토 과정, 이미 막혀 있는 사람을 위한 문장이 필요합니다. 직원용 문서는 좀 더 어수선해도 되지만 대신 권한이 필요합니다.
개인과 소규모 팀의 지식은 노트·위키에 속합니다. 답을 못 얻은 질문이 도착하는 티켓 대기열은 고객 지원입니다.
구조가 무엇이 발견되는지를 결정합니다
모든 문서화 프로젝트는 정돈된 상태로 시작해 무더기로 끝납니다. 도구는 그 속도를 늦추거나 앞당깁니다.
계층이 어떻게 동작하는지 보세요. 카테고리, 하위 페이지, 상호 링크, 그리고 페이지가 복제 없이 두 곳에 놓일 수 있는지입니다. 그다음 페이지가 삼백 개일 때 어떻게 되는지 보세요. 서른 개를 위해 설계된 내비게이션이 무너지는 지점입니다.
검색이 정직한 시험입니다. 내부 용어가 아니라 고객이 쓸 단어로 검색해 보세요. 제목만 매칭하는 제품은 이 시험에 떨어지고, 독자는 결국 지원 대기열로 오게 됩니다.
태그와 관련 문서 추천은 관리될 때만 도움이 됩니다. 손으로 오래 관리하는 사람은 없으므로, 콘텐츠에서 연결을 생성하는 제품을 선호하세요.
쓰기, 검토, 페이지를 사실에 맞게 유지하기
문서는 조용히 썩습니다. 3월에는 맞았던 페이지가 9월에는 지원 티켓이 되는데, 겉보기에는 아무것도 이상하지 않습니다.
쓸모 있는 제품은 담당자, 검토일, 독자가 볼 수 있는 마지막 확인 표시를 갖춥니다. 쓰는 사람이 둘을 넘으면 초안 상태와 검토 워크플로가 중요해지고, 누군가 페이지가 바뀌기 전에 뭐라고 쓰여 있었는지 처음 물을 때 버전 기록이 중요해집니다.
재사용도 확인할 가치가 있습니다. 한도, 가격, 지원 버전 목록은 한 번만 존재하고 나타나는 모든 곳에 포함되어야 하며, 다음 분기에는 서로 어긋날 열한 페이지에 붙여 넣으면 안 됩니다.
발행과 검색 문제
공개 헬프 센터는 웹사이트이므로 웹사이트처럼 동작해야 합니다.
- 깔끔한 URL은 구조를 개편해도 유지되고, 유지할 수 없을 때는 리디렉션이 있어야 합니다.
- 편집 가능한 제목과 설명은 첫 줄에서 자동 생성되지 않고 문서마다 지정할 수 있어야 합니다.
- 빠른 페이지는 텍스트가 나타나기 전에 무거운 애플리케이션이 먼저 로드되지 않아야 합니다.
- 사이트맵은 아무도 기억하지 못하는 일정이 아니라 발행할 때 갱신되어야 합니다.
- 커스텀 도메인이 있어야 자료가 공급사가 아니라 내 사이트의 권위를 쌓습니다.
마지막 항목은 사내에서 주장해 볼 가치가 있습니다. 문서는 소프트웨어 회사가 가진 가장 성과가 좋은 콘텐츠인 경우가 많은데, 공급사 서브도메인에 호스팅하면 그 트래픽을 넘겨주게 됩니다.
측정, 그리고 유일하게 중요한 지표
페이지 조회수는 거의 아무것도 알려 주지 않습니다. 두 가지 숫자가 많은 것을 알려 줍니다.
첫째는 쓸 만한 결과를 돌려주지 못한 검색으로, 다음에 만들 것의 목록 그 자체입니다. 둘째는 문서를 연 독자가 이후에도 지원에 연락했는지로, 헬프 센터를 티켓 시스템에 연결해야 알 수 있습니다.
의견이 아니라 그 목록을 보고 다시 쓰세요. 가장 자주 실패하는 문서 다섯 편이 아무도 방문하지 않는 쉰 편보다 가치가 있습니다.
이 제품들의 요금 구조
작성자 사용자 기준이며, 독자는 모두 무료인 곳도 있고 등록된 사내 독자당 과금하는 곳도 있습니다. 공개 헬프 센터는 보통 작성자 수와 문서 양으로, 사내 위키는 사용자 수로 과금합니다.
세 가지 경계를 살피세요. 커스텀 도메인, 버전 관리, 싱글 사인온은 각각 입문 요금제보다 한 등급 위에 있는 경향이 있습니다. 분석의 깊이가 네 번째입니다. 헬프 센터를 고객 지원 제품과 묶어 파는 공급사는 포함하지 않고 애드온으로 가격을 매기는 경우가 많은데, 이는 요금 페이지가 감추는 것에 모인 관행 중 하나입니다.
결정하기 전에 모든 것을 내보내고 결과물을 읽어 보세요. 마크다운이나 깨끗한 마크업이라면 떠날 수 있습니다. 독자 형식이라면 아카이브가 인질이 됩니다.
맨바닥에서 헬프 센터 시작하기
첫 버전은 민망할 만큼 작아야 합니다.
지원 대기열에 가장 자주 들어오는 질문 스무 개를 골라 제대로 답하세요. 문의의 대부분을 다루고 일주일이면 끝납니다. 반면 전체 구조를 먼저 계획하는 데는 한 분기가 걸리고 그동안 아무것도 답하지 못합니다.
각 문서는 이미 막혀 있는 사람을 위해 쓰세요. 답을 먼저, 설명은 그다음입니다. 스크린샷은 빨리 낡으므로 정말 도움이 되는 곳에만 쓰고 교체할 것으로 생각하세요.
그다음 구조가 저절로 드러나게 두세요. 문서가 서른 편쯤 되면 카테고리가 분명해지고, 다섯 편일 때 억지로 정하면 어차피 다시 개편하게 됩니다.
결과가 나오지 않은 검색어를 작성 대기열로 공개하세요. 이 카테고리에서 바닥나지도, 빗나가지도 않는 유일한 콘텐츠 계획입니다.
자주 묻는 질문
지식 베이스와 위키는 무엇이 다른가요?
지식 베이스는 답이 필요한 독자를 위해 쓰이고, 구조와 검색도 그에 맞게 설계됩니다. 위키는 기여자를 위해 쓰이고 자연스럽게 자랍니다. 둘은 서로의 영역으로 흘러가기 때문에 유지 규칙이 중요합니다.
문서화를 메모와 같은 도구에 두어도 되나요?
독자가 겹칠 때만 그렇습니다. 사내 메모는 어수선해도 됩니다. 고객이 보는 문서에는 버전 관리, 검토, 공개 URL이 필요하고, 둘을 섞으면 보통 후자가 나빠집니다.
문서가 낡는 것을 어떻게 막나요?
모든 페이지에 담당자와 검토일을 정하고, 마지막으로 확인된 시점을 독자에게 보여 주세요. 결과가 나오지 않은 검색의 분석이 나머지 절반이며, 다음에 무엇을 쓸지 알려 줍니다.
공개 지식 베이스가 지원 문의량을 줄여 주나요?
문서가 사람들이 실제로 보내는 질문에 답한다면 측정 가능한 수준으로 줄어듭니다. 추측하지 말고 문의 감소 수치를 헬프 데스크와 연결하고, 가장 자주 실패하는 문서 다섯 편을 다시 쓰세요.
제품 릴리스별로 문서 버전을 관리할 수 있나요?
개발자 중심 플랫폼에서는 가능하며, 고객이 이전 버전을 쓸 때 중요합니다. 일반 지식 베이스 제품은 보통 기록이 있는 라이브 버전 하나를 제공하며, 스스로 업데이트되는 소프트웨어라면 충분합니다.