Salesforce 기술 자료 준비
학습 목표
이 유닛을 완료하면 다음을 수행할 수 있습니다.
- 기술 자료에 포함할 정보를 수집할 수 있습니다.
- 정보를 정리할 수 있습니다.
- 사용자 액세스 권한을 결정할 수 있습니다.
Knowledge에 적합한 정보를 수집합니다.
Maria는 계획 수립의 중요성을 압니다. Ursa Major는 이미 Service Cloud를 사용하여 실로 탁월한 고객 서비스를 제공할 날이 머지않았습니다. 회사의 사례는 에이전트가 사례를 빨리 마감하려면 다음에는 어디로 가야 하는지 알 수 있도록 정형화되어 있습니다. 하지만 Maria와 Ada는 아직 알아내야 할 것이 많습니다.
Maria는 Ursa Major 최고의 지원 에이전트인 Ada와 미팅 일정을 한 번 더 잡습니다. 두 사람은 함께 기술 자료에 포함시킬 정보를 결정합니다. Ada에게는 문서를 만드는 데 사용할 수 있는 메모가 있습니다. Ursa Major 웹 사이트에 자주 묻는 질문(FAQ) 목록도 있지만, 최신 상태는 아닙니다. 게다가 태양광 발전 부품에 대한 제조업체 데이터 시트도 있습니다. 이런 정보는 시작에 불과하고, 두 사람은 곧 기술 자료에 추가할 정보가 많다는 사실을 깨닫습니다.
Maria와 Ada에게는 Knowledge 문서를 정형화할 방법에 관한 목표도 있습니다. 두 사람의 목표는 다음과 같습니다.
- 작성자가 적절한 콘텐츠를 수집할 수 있게 지원
- 읽기 쉬운 문서 작성
- 문서를 쉽게 업데이트할 수 있게 하기
- 문서의 각기 다른 부분을 각기 다른 사용자와 공유
Maria는 기술 자료를 디자인하면서 다음과 같이 질문합니다.
| 질문 | 예제 | 모범 사례 |
|---|---|---|
| 어떤 정보를 게시할 것인가요? | FAQ, 절차, 제품 매뉴얼, 지침 Ursa Major에는 이런 유형의 정보 외에도 다양한 정보가 있습니다. 두 사람은 다양한 유형의 정보를 다양한 방법으로 게시하고 표시하고 싶어합니다. |
각각 다른 정보 유형마다 레코드 유형을 하나씩 만듭니다. 레코드 유형에 따라 각 문서 유형을 정형화할 방법 및 다양한 사용자 프로필과 공유할 정보가 결정됩니다. 그 외에 워크플로와 페이지 레이아웃 같은 중요한 기능도 레코드 유형에 따라 설정됩니다. |
| 가져올 기존 기술 자료 또는 설명서가 있나요? | Ursa Major는 Lightning Knowledge와 Ada의 메모로 시작하기 때문에 아무것도 가져오지 않아도 됩니다. | Knowledge 가져오기 도구를 사용하여 다른 기술 자료에서 문서를 가져옵니다. Lightning Knowledge 마이그레이션 도구를 사용하여 기존 Salesforce Classic Knowledge 콘텐츠를 Lightning Knowledge로 이동합니다. |
| 추천 문서를 필터링하는 데 사용할 필드가 사례에 있나요? | 제품군, 제품 지역, 문제 유형. Ursa Major에 중요한 필드로는 태양광 발전 부품과, 그룹이라는 부품 컬렉션 등이 있습니다. |
각 검색 필터 유형마다 데이터 범주 그룹을 정의하거나 각 범주 또는 그룹의 문서를 표시할 사용자 프로필을 결정합니다. |
| 문서 작성 및 게시를 관리할 워크플로 또는 승인 프로세스가 필요한가요? | 일부 문서는 중요한 정보를 포함하고 있어 법적 승인이 필요합니다. Ursa Major의 태양 전지판에는 안전 요건이 있으므로 설치 및 서비스 절차를 주의 깊게 검토해야 합니다. |
레코드 유형에 승인 프로세스를 추가하여 문서를 게시하기 전에 해당 유형의 문서를 검토해야 하는 사람의 승인을 받도록 합니다. |
| 정보를 어떤 유형의 대상과 공유하려고 하는가? | 다양한 대상을 채널이라고 합니다. 문서의 채널을 설정하여 문서를 볼 수 있는 사용자 유형을 결정합니다. 정의한 후에는 사용자가 액세스 권한을 보유한 셀프 서비스 사이트에서 콘텐츠를 볼 수 있습니다. Ursa Major에는 몇 가지 유형의 사용자가 있으므로 Maria는 누가 무엇을 봐야 하는지 알아야 합니다. |
각 대상이 이용할 수 있도록 할 정보를 결정합니다. 필요한 경우 중요한 정보를 안전하게 지키기 위해 개별 필드를 제한하거나, 데이터 범주를 사용해 특정 범주에 연결된 레코드를 특정 사용자 프로필로 제한합니다. |
| 문서 피드백을 어떻게 추적하나요? | 사용자가 엄지를 올리거나 내려서 문서를 평가할 수 있게 합니다. | 문서 평가 등급에 대한 사용자 정의 보고서를 만듭니다. 보고서와 문서를 주기적으로 검토하여 기술 자료를 정확한 최신 상태로 유지합니다. |
| 어떤 문서가 효과적인지 어떻게 확인할 수 있나요? | 문서가 사례에 얼마나 자주 연결되는지 모니터링합니다. Ursa Major에서는 태양광 온수 히터를 설치하면 고객이 절약할 수 있는 금액을 설명하는 문서가 가장 많이 참조됩니다. |
문서가 고객 문제를 해결하는 사례에 몇 번 연결되는지 확인합니다. 사례에 자주 연결되는 문서를 교육 중에 고객이나 에이전트와 공유하면 유용할 수 있습니다. 문서를 번역하는 경우 이런 문서로 시작하면 좋습니다. |
이 정도면 Maria가 시작하는 데 충분합니다. 자신에게 어떤 정보가 있는지 알게 된 Maria는 이제 정보로 무엇을 할지 계획하기 시작합니다.
Knowledge에 사용할 정보 정리
Maria에게는 많은 정보가 있지만, 모든 정보가 모든 지원 에이전트에게 중요하지는 않습니다. 그녀는 정보를 정리할 논리적인 방법을 찾아야 합니다. 우선 정보를 데이터 그룹으로 정리합니다.
하지만 사용할 데이터 그룹은 어떻게 결정할 수 있을까요? Maria는 Ursa Major 지원 조직의 구조를 살펴봅니다. Ursa Major는 지원하는 제품 유형에 따라 지원 팀을 다음과 같이 나눕니다.
- 주거용 태양광 발전 설비
- 상업용 태양광 발전 설비
- 개별 태양광 발전 부품
Maria는 정보를 팀별로도 나누기로 결정합니다. 고객 서비스 제공 방법 같은 일부 문서는 모든 팀이 볼 수 있습니다. 그 외에 상업용 태양 전지판에 대한 법규 같은 문서는 관련 팀만 볼 수 있습니다.
이런 그룹—주거용, 산업용 및 개별 부품— 안에서, Maria는 정보를 데이터 범주로 더 분류합니다. 주거용 그룹에는 태양광 온수 히터 설치 및 전체 주택 태양광 시스템 같은 범주가 포함됩니다. 문서를 범주로 나누자 에이전트 및 사용자들이 필요한 문서를 더 빨리 찾을 수 있습니다.
문서를 범주로 나눌 때 질문할 내용은 다음과 같습니다.
| 질문 | 예 | 모범 사례 |
|---|---|---|
| 정보를 어떻게 범주로 나눠야 하나요? | Ursa Major는 정보를 팀별 그룹으로 나눈 후 제품 유형별 범주로 나눕니다. 다른 회사에서는 정보를 지역 그룹별로 나눈 후 제품별 범주로 나눕니다. |
데이터 범주 그룹에는 데이터 범주가 포함됩니다. 그룹 수는 적을수록 좋습니다. 데이터 범주 그룹과 데이터 범주를 정의할 때는 분류를 사용자가 분명히 이해할 수 있도록 해야 합니다. 사용자는 기존 문서를 검색하거나 새 문서를 작성할 때 어떤 그룹과 범주를 선택해야 하는지 알아야 합니다. |
| 제한해야 하는 정보가 있나요? | Ursa Major의 제품과 지원 에이전트는 주에 따라 다릅니다. 애리조나 주에서만 확인할 수 있는 제품 및 영업 정보는 뉴멕시코 주의 에이전트에게 표시되지 않을 수 있습니다. | 데이터 범주 표시 여부를 프로필에서 설정하여 해당 데이터 범주의 문서에 액세스할 수 있는 사용자 프로필을 관리합니다. |
| 검색 용이성을 개선해야 하나요? | 에이전트와 고객은 광대한 기술 자료 속에서도 필요한 문서를 찾아야 합니다. Ursa Major에는 아직 이런 문제가 없지 않지만, Maria는 이 문제를 사전에 차단하고 싶어합니다. |
검색어의 유의어를 식별합니다. 예: linking(연결)과 attaching(연결) 검색 결과에 검색어와 일치하는 문서 텍스트 코드조각이 하이라이트되도록 합니다. |
Knowledge를 위해 누가 무엇을 하는지 결정
Maria는 내부 사용자가 문서를 볼 수 있도록 하기 위해 무엇을 할지 결정합니다. 좋은 소식이 있습니다! 모든 내부 사용자가 기술 자료를 기본적으로 볼 수 있습니다. 따라서 이렇게 하기 위해 Maria가 해야 할 일은 없습니다.
하지만 에이전트가 기술 자료를 보기만 하는 것은 아닙니다. 결국에는 많은 에이전트가 문서를 쓰고 관리하게 됩니다. 각 문서에 누가 무엇을 해야 하는지 결정하기 위해, Maria와 Ada는 문서 수명 주기를 고려합니다.
예를 들어 Ada는 신입 에이전트들이 새 문제를 해결하면 문서를 작성하도록 하고 싶습니다. 하지만 문서를 더 광범위한 대상을 위해 게시하기 전에 Ada처럼 경험이 더 풍부한 에이전트가 다시 확인하고 승인해야 합니다. 문서를 업데이트하거나 문서를 보관 또는 삭제하는 경우에도 유사한 프로세스를 사용하게 됩니다.
일반적인 세 가지 유형의 사용자와 각 유형의 사용자가 자신의 직무를 수행하기 위해 필요한 권한은 다음과 같습니다.
| 사용자 | 설명 | 필요한 권한 |
|---|---|---|
| 읽기만 가능 | 비교적 최근에 입사한 이런 에이전트는 아직 문서를 작성할 권한이 없습니다. 이들은 기존 문서를 사용하여 질문에 답하고 문서를 사례에 연결합니다. 이런 문서를 통해, 이들은 모든 문제를 스스로 해결해야 하는 경우보다 훨씬 더 빨리 회사에 기여할 수 있습니다. |
Knowledge 읽기 권한 |
| 기고자 | Ada 같은 고급 Knowledge 사용자입니다. 이들은 제품 지식이 많고 문서가 충족해야 하는 기준을 이해합니다. 이들은 문서를 작성, 편집 및 게시합니다. |
문서 관리 권한과 Knowledge 읽기, 작성, 편집 및 게시 권한 |
| Knowledge 관리자 | Knowledge 관리자는 문서를 언제 폐지 또는 삭제해야 하는지 압니다. | 문서 관리 권한과 Knowledge 읽기, 작성, 편집, 보관, 게시 및 삭제 권한 |
Maria는 어떤 종류의 정보를 갖고 있는지 확인했고, 정보를 정리하기 위해 사용할 그룹과 범주를 결정했습니다. 누가 어떤 정보에 액세스할 수 있어야 하는지도 결정했습니다. 그녀는 Lightning Knowledge를 설정하고 Ursa Major의 기술 자료를 만들기 시작할 준비가 되었습니다.
