앱 빌더에 대한 프롬프트 가이드라인 및 예

모든 Suite

Professional, Enterprise 또는 Enterprise Plus

Support

Professional 또는 Enterprise

앱 빌더는 자연어 처리(NLP)를 활용하여 사용자 프롬프트를 해석하고 실행 가능한 앱 구성 요소로 변환합니다. 이 도구의 효율성을 극대화하려면 명확하고 정확한 프롬프트를 제공해야 합니다. 이 문서에서는 앱 빌더에 필요 사항을 효과적으로 전달하기 위한 효과적인 프롬프트를 만들기 위한 주요 가이드라인에 대해 설명합니다. 또한 앱 빌더 프롬프트 프레임워크를 사용하여 작업 범위를 좁히는 방법에 대한 몇 가지 예도 포함되어 있습니다.

이러한 가이드라인과 프레임워크 예를 따르면 LLM이 요청을 정확하게 이해하여 앱 개발 프로세스가 순조롭게 진행되고 더 나은 결과를 얻을 수 있습니다.

이 문서는 다음 섹션으로 구성되어 있습니다.

효과적인 메시지 표시를 위한 성공 사례
앱 빌더 프롬프트에 대한 가이드라인
앱 빌더 프롬프트를 위한 프레임워크
MAPS 원칙을 사용한 프롬프트 예
고객이 만든 앱 예
추가 리소스

효과적인 메시지 표시를 위한 성공 사례

이러한 성공 사례를 따르면 앱 빌더에서 더욱 정확하고 효율적인 결과를 생성하는 동시에 필요한 프롬프트 수를 최소화하는 데 도움이 됩니다.

앱 구축에 대한 프롬프트 집중 : 앱 빌더는 앱을 디자인 및 개선하고, API를 연결하고, 연동 서비스를 설정할 수 있도록 최적화되어 있습니다. 앱 구성에 대한 개괄적인 지원을 제공하지만 단계별 설정 안내를 대체하지는 않습니다. API 자격 증명을 찾거나 API 키 또는 OAuth 통해 타사 시스템을 연결하는 것과 같은 특정 작업의 경우 공식 문서나 Google 검색 또는 ChatGPT와 같은 신뢰할 수 있는 리소스를 사용하세요. 이로써 실제 앱 논리 및 기능 구축을 위한 앱 빌더 프롬프트를 확보할 수 있습니다.
언제 추가 도움을 요청해야 하는지 파악 : 동일한 오류를 여러 번(예를 들어 3~4번의 프롬프트 시도 후에도) 문제 해결을 시도했지만 계속 진행할 수 없는 경우에는 오류 세부 정보를 가지고 Zendesk 고객 지원팀에 문의하세요 .
오류 및 기대치에 대해 명확하게 설명 : 테스트 중 앱에 오류가 발생하면 무엇이 잘못되었고 어떤 일이 일어날지 정확히 설명하세요. 자세한 피드백은 AI 문제를 더욱 효율적으로 해결하는 데 도움이 됩니다.
해결되지 않은 문제에 대한 디버깅 세부 정보 공유 : 반복해서 수정해도 문제가 해결되지 않으면 프롬프트에 이를 명확하게 명시하세요. AI 콘솔에서 광범위한 디버깅 정보를 생성하도록 요청한 다음 오류를 재현하여 출력을 다시 대화에 붙여넣습니다.
일괄 변경 및 단순 변경 : 프롬프트 사용을 최적화하려면 레이아웃 조정, 버튼 스타일 또는 탭 순서와 같은 사소한 조정을 여러 개의 별도 요청을 보내는 대신 단일 프롬프트로 그룹화하세요.
티켓 검색으로 테스트 모드 사용자 지정 : 상담사 워크스페이스 에서 티켓 검색을 사용하여 앱을 테스트하는 동안 티켓을 변경하세요. 이로써 추가적인 프롬프트 없이 신속한 시나리오 유효성 검사가 가능합니다.
비공개 또는 알 수 없는 API에 대한 예 제공 : 앱 빌더가 인식하지 못하는 API를 사용하는 경우에는 샘플 API 요청과 예상 응답을 둘 다 포함합니다. 이로써 AI의 정확도가 개선되고 반복 낭비가 줄어듭니다.
라이트 모드와 다크 모드 모두에서 테스트 : 다크 모드를 사용하는 상담사가 있다면 두 테마 모두에서 앱을 테스트하여 시각적 문제를 조기에 파악하고 해결하도록 하세요.
대화를 삭제하기 전에 청사진을 저장합니다 . 대화를 삭제하기 전에blueprint.md 코드 탭에서 파일을 만듭니다. 앱의 디자인 요약을 포함하며 향후 수정 버전에 중요합니다.
설정을 통해 앱 이름 및 아이콘 조정 : 프롬프트를 통하지 않고 설정 탭에서 직접 앱의 이름과 아이콘을 업데이트합니다.
앱은 상담사 워크스페이스 내에서 실행됩니다 . 앱 빌더 앱은 상담사 워크스페이스 환경 내에서 작동하며 해당 워크스페이스 열려 있는 동안에만 실행됩니다. 백그라운드 또는 영구 워크플로우가 필요한 경우에는 작업 빌더, ZIS 또는 Workato, Zapier, AWS Lambda 또는 Heroku와 같은 외부 도구를 사용하세요.
구축 전 계획 요구 사항 : 시작하기 전에 앱의 목표, 워크플로우, 데이터 요구 사항 및 기본 설정을 간략하게 설명하세요. 이로써 AI 강력한 첫 번째 버전을 제공하는 데 도움이 되며 지원 티켓을 제출하는 것보다 빌드 속도가 더 빠른 경우가 많습니다.

앱 빌더 프롬프트에 대한 가이드라인

Zendesk 앱 빌더를 사용할 때 프롬프트를 작성하기 위한 성공 사례는 다음을 포함합니다.

명확하고 간단한 언어 사용
- 동료에게 필요 사항을 설명하는 것처럼 자연스럽고 간단한 문장으로 프롬프트를 작성하세요.
- 설명하지 않거나 사용자가 알지 못하는 전문 용어나 프로그래밍 용어를 사용하지 마세요.
- 앱이 수행해야 하는 작업에 대해 명확하게 하세요.

원하는 기능에 대해 구체적으로 작성
- 앱에서 사용해야 하는 데이터 소스(예: Google, Jira, 내부 데이터베이스)를 명확하게 명시합니다.
- 앱에 있어야 하는 핵심 기능이나 작업(예: 주문 상태 표시, 에스컬레이션 양식 제출)을 지정합니다.
- 표시하려는 중요한 데이터 포인트나 출력을 포함합니다.

사용자 전후상황 또는 역할 포함
이로써 앱 빌더가 그에 따라 인터페이스와 기능을 맞춤화하는 데 도움이 됩니다.
- 앱의 기본 사용자(예: 상담사, 감독자)를 멘션합니다.
- 예를 들어 지원 티켓을 처리하는 동안 앱을 사용할 전후상황을 설명합니다.
복잡한 요청 분류
이로써 오류가 줄어들고 각 기능을 더 잘 이해하는 데 도움이 됩니다.
- 앱에 여러 기능이 필요한 경우에는 요청을 더 작은 부분으로 나누고 반복적으로 구축해 보세요.
- 기본 앱 프롬프트로 시작한 다음 기능이나 세부 정보를 단계적으로 추가하여 세분화합니다.
예 및 시각적 기대치 사용
- 가능하다면 앱의 출력 형태(목록, 버튼, 그래프)를 설명하세요.
- 유형 요소를 참조하면 빌더가 직관적인 인터페이스를 만드는 데 도움이 됩니다.

반복적인 개선 요청
반복 주기를 통해 한 번에 모든 기능을 테스트하는 대신 한 번에 하나씩 앱을 테스트하고 개선하여 코딩 없이 더 나은 최종 앱을 만들 수 있습니다.
- 첫 번째 버전이 생성된 후 어떤 것이 효과가 있고 어떤 것이 효과가 없는지 검토하고 피드백을 제공하세요.
- 자연어를 사용하여 변경 내용을 지정합니다(예: “데이터를 새로 고치는 버튼 추가” 또는 “등록 티켓만 표시”).

실용적인 이점에 중점
이로써 앱이 가치를 제공하는 데 집중하여 관련성과 유용성을 보장합니다.
- 상담사를 위해 해결해야 할 문제나 단순화할 작업을 중심으로 프롬프트를 구성하세요.

모호성 방지
- “relevant”의 의미를 설명하지 않고 “show related info”와 같은 모호한 용어를 사용하지 마세요.
- 모호성으로 인해 앱이 기대치에 미치지 못할 수 있습니다.

이러한 성공 사례를 따르면 코딩 경험이 없는 사용자도 효과적인 프롬프트를 작성하여 유용한 사용자 지정 지원 앱을 만들 수 있습니다.

앱 빌더 프롬프트를 위한 프레임워크

프롬프트를 작성할 때 개발자에게 앱을 만들도록 안내하는 것과 비슷한 방식으로 앱 빌더에 안내를 제공하는 것입니다. 달성하려는 목표에 대한 계획을 세우는 것이 좋습니다. 다음 프레임워크를 통해 앱 빌더가 무엇을 기대하는지 알 수 있어 더욱 효과적으로 작업 중인 것에 집중할 수 있습니다.

이러한 유형의 지시가 없으면 앱 빌더가 앱을 구축하지만 필요를 충족시키지 못할 수도 있습니다. 앱 빌더는 프롬프트가 앱 빌드 인 경우에도 시도합니다. 하지만 특정 앱이 필요한 경우에는 앱 빌더를 더 많이 안내할수록 필요한 것을 얻을 가능성이 높아집니다.

프롬프트를 작성할 때 다음과 같은 MAPS 원칙을 고려하세요. 미션, 작업, 부품, 범위

목적: 앱의 용도. 현재 필요와 전후상황을 고려하세요.
작업: AI 생성해야 하는 것입니다. 핵심 기능과 워크플로우를 고려하세요.
구성 요소: UI 또는 구조적 부분 디자인 구성 요소를 고려하세요.
범위: 누구 또는 무엇을 위한 것입니다. 제약 조건과 대상을 고려하세요.

MAPS 원칙을 사용하여 확실하지 않거나 마음에 들지 않는 경우 다른 섹션을 변경하지 않고 작업, 범위 또는 부분을 변경할 수 있습니다.

MAPS 원칙을 사용한 프롬프트 예

다음은 MAPS 원칙을 사용한 몇 가지 프롬프트 예입니다.

예 1: 내 최근 만족도 댓글 앱

목적: 이 앱은 상담사 만족도를 위해 구축되었으며 상담사에게 피드백 루프를 허용하여 상담사가 고객의 만족도 기록을 파악하여 상호작용을 안내하고 서비스 품질을 개선할 수 있도록 합니다.
작업: 지난 6개월 동안의 가장 최근 티켓 만족도 댓글 5개와 추세를 검색하여 표시하는 사이드 패널 앱을 만듭니다.
구성 요소: 날짜와 만족도 점수를 표시하지 마세요. 가장 최근의 티켓 만족도 댓글 5개를 표에 표시하고 6개월 동안의 추세를 간략한 선 차트에 표시합니다. 개별 티켓 만족도 댓글과 추세 사이를 전환하는 탭을 포함합니다. 댓글 열을 앱의 전체 너비로 설정합니다. 각 컨테이너의 배경에 만족도 평점이 좋음이면 약간 옅은 녹색 음영을, 만족도 평점이 나쁨이면 약간 흐리게 빨간색 음영을 표시합니다.
범위: 이 앱은 지원 티켓을 보는 상담사를 위한 것입니다. 현재 요청자에 대한 티켓 만족도 댓글만 표시하고 동일한 브랜드나 조직의 티켓만 표시합니다.

예 2: Customer 360 앱

목적: 이 앱은 티켓 보기 내에 바로 주요 고객 정보를 표시하여 상담사가 다른 곳으로 이동하지 않고도 문제를 해결하는 데 필요한 세부 정보에 신속하게 액세스할 수 있도록 하여 상담사 효율성을 높이도록 디자인되었습니다.
작업: 내부 CRM 데이터베이스에서 고객 정보, 구매 내역 및 고객 충성도 정보를 검색하여 표시하는 앱을 만듭니다.
구성 요소: 고객 정보, 구매 내역 및 고객 충성도 정보를 3개의 개별 탭에 표시하세요. 현재 보고 있는 탭을 시각적으로 표시합니다. 고객 충성도가 낮으면 정보를 노란색으로 강조 표시합니다. 최신 변경 사항을 반영하도록 표시된 데이터를 새로 고침하는 버튼을 추가합니다.
범위: 이 앱은 지원 티켓을 보는 상담사를 위한 것입니다. 현재 요청자 및 동일한 브랜드 또는 조직의 티켓에 대해서만 이 정보를 표시합니다.

고객이 만든 앱 예

다음은 Zendesk 고객이 만든 앱의 몇 가지 예입니다.

담당자 변경 내용 추적 앱 : 모든 티켓 배정 변경 내용을 표로 캡처하여 발생한 총 티켓 배정 수를 보여주는 앱입니다. 관리자와 팀 리드가 사용할 수 있습니다. 관리자가 이 앱을 구축하는 데 30분도 채 걸리지 않았습니다.

프롬프트

지정된 티켓에서 담당자의 변경 내용을 추적하는 앱을 만듭니다. 이전 담당자와 새 담당자의 담당자 이름을 반드시 표시하세요. 티켓 배정의 총 변경 수도 표시합니다.
최신 변경 사항을 반영하도록 표시된 데이터를 새로 고침하는 버튼을 추가합니다. 다른 버튼을 추가하여 데이터를 Excel로 내보내세요. 두 버튼을 작게 만들고 서로 나란히 배치합니다.

결과 앱

내 최근 만족도 댓글 앱 : 티켓에서 가장 최근 CSAT 댓글 5개를 표시하는 앱입니다. 고객은 Zendesk의 기본 제공 CSAT 도구의 최신 버전으로 업데이트할 때 대화 로그에서 제거되었던 티켓 맨 위에 표시되었던 CSAT 댓글을 대체하는 앱으로 이 앱을 사용할 계획입니다. 관리자가 이 앱을 구축하여 프로덕션에 배포하는 데 1시간이 걸렸습니다. 이 앱은 상담사 만족도를 위해 구축되었으며 상담사가 피드백 루프를 허용하여 각 상호작용 후 고객이 어떻게 느끼는지 알 수 있도록 합니다.

프롬프트

가장 최근의 티켓 만족도 댓글 5개를 표시하는 앱을 만듭니다.
현재 사용자에 대한 티켓 만족도 댓글만 표시하도록 앱을 업데이트하세요.
앱은 현재 사용자뿐만 아니라 모든 사용자에 대해 가장 최근 티켓 만족도 댓글 5개를 계속 표시합니다.
날짜 및 점수 열을 제거합니다. 댓글 열을 앱의 로 가득 채우세요.
각 컨테이너의 배경에 만족도 평점이 좋음이면 약간 옅은 녹색 음영을, 만족도 평점이 나쁨이면 약간 흐리게 빨간색 음영을 표시합니다.

결과 앱

사용자 데이터 앱 : 요청자의 티켓 데이터, 전체 티켓 기록 및 티켓 첨부 파일을 표시하는 앱입니다.

프롬프트

만든 날짜, 종료 날짜 및 티켓 ID가 제공되는 사용자의 티켓 데이터에 대한 지식 또는 Explore 보고서를 만듭니다. 보고서 버튼으로 먼저 보고서를 만든 다음 다운로드 가능으로 설정해야 합니다.
모든 티켓 상태가 신규 순으로 표시되는 고객의 티켓 기록을 봅니다.> 등록> 보류> 해결> 종료됨.
티켓에서 첨부 파일로 보낸 모든 파일을 다운로드합니다.

결과 앱

내 Insight 앱 : 상담사가 지난 6개월 내에 해결한 상위 5개 티켓 주제 또는 카테고리를 볼 수 있는 앱입니다.

프롬프트

상담사가 지난 6개월 이내 티켓 수와 티켓 양식 및 티켓 양식별 티켓 수를 기준으로 지난 6개월 내에 티켓을 해결한 상위 5개 주제 또는 카테고리를 볼 수 있는 앱을 만듭니다. 각각에 대한 CSAT 무엇인지 알 수 있습니다. 카테고리 이름이 B2C 소매 및 전자 상거래 사용 사례를 반영하도록 하고 모의 데이터를 구성합니다. N/A% 또는 100% CSAT 점수가 없어야 합니다. 평균 처리 시간 및 평균 전체 해결 시간에 대한 열을 추가합니다.
상담사가 기간별로 데이터를 분석할 수 있는 필터를 추가하고 각 카테고리에 상담사 담당자 수를 추가할 수도 있습니다.
재배정은 각 카테고리 내에서 총 수가 아닌 평균이어야 합니다. 또한 Avg. 해결 시간은 녹색, 노란색 및 빨간색 신호등 시스템 태그를 사용하여 팀 벤치마크와 비교합니다.

결과 앱

사용자 및 조직 세부 정보 앱 : 축소 가능한 섹션이 있는 사용자 지정 사용자 필드 및 사용자 지정 조직 필드를 포함한 사용자 및 조직 세부 정보를 표시하는 앱입니다.

프롬프트

모든 사용자 지정 사용자 필드와 모든 사용자 지정 조직 필드를 포함하여 사용자 및 조직 세부 정보를 표시하는 앱을 만듭니다.
감사합니다. 키 대신 사용자 지정 사용자 및 조직 필드의 이름을 주시겠어요? 또한 앱의 이름을 사용자 및 조직 세부 정보로 바꾸어 보겠습니다.

결과 앱

Ticket Pulse 앱 : 요청자의 최근 활동, 특히 가장 최근 5개의 티켓을 관련 정보와 함께 표시하는 앱입니다.

프롬프트

현재 티켓 요청자에 대한 최근 5개의 티켓을 표시하는 앱을 만듭니다. 새 탭에서 열기 위해 리디렉션될 수 있는 티켓의 번호와 제목 및 링크를 표시하고 싶습니다.
Zendesk 내의 새 탭에서 티켓을 열 수 있나요?
UI를 더욱 사용자 친화적으로 만들 수 있나요?
다른 멋진 이름을 지정하세요.

결과 앱

Salesforce 계정 세부 정보 앱 : 티켓 요청자의 Salesforce 계정 세부 정보를 표시하는 앱입니다.

프롬프트

Zendesk API를 사용하여 Salesforce API에 연락하여 티켓 요청자의 Salesforce 계정 세부 정보를 검색합니다.
이제 앱이 어떻게 보일지 보여주기 위한 테스트 목적으로 실제로 Salesforce API에 연결하지 않고 앱이 각 Salesforce 필드에 대한 모의 테스트 값을 리턴하도록 합니다.

결과 앱

추가 리소스

앱 빌더를 시작할 때 다음 리소스가 도움이 될 수 있습니다.

모든 앱 빌더 사용법 찾아보기 : 다음 빌드에 영감을 주는 커뮤니티 구축 앱 예 모음입니다.
앱 사용법 만들기 : 사용법 호스트를 제출하여 직접 만든 앱 빌더를 커뮤니티와 공유하세요. 전체 안내를 참조하여 시작하세요.

번역 고지 사항: 본 문서는 콘텐츠에 대한 기본적인 이해를 제공하기 위해 자동 번역 소프트웨어를 사용하여 번역되었습니다. 정확한 번역을 제공하고자 합당한 노력을 기울였으나 Zendesk는 번역의 정확성을 보장하지 않습니다.

번역된 문서에 포함된 정보의 정확성과 관련하여 질문이 있으시면 문서의 공식 버전인 영문 버전을 참조하시기 바랍니다.