Pipp의 가이드
창립자와 소규모 팀을 위한 공유 이메일 지원
공유된 지원 받은 편지함을 통해 팀원은 고객 이메일을 읽고, 이전 답변을 확인하고, 다음 답변을 처리할 사람을 결정할 수 있습니다. 답변한 사람끼리 계속 물어보면 도움이 됩니다.
우리는 Pipp를 빌드하고 Lumenfall에서 이 문제에 직면했습니다. 이 가이드는 Pipp 디자인에서 우리가 선택한 경험과 선택을 바탕으로 작성되었습니다. Pipp의 기본 공유 이메일 받은 편지함이 오늘 준비되었습니다. 아래의 핸드오프 연습은 허구입니다.
공유 지원 받은 편지함이란 무엇입니까?
공유주소는 고객이 글을 쓰는 곳입니다. 공유 받은 편지함은 팀이 해당 메시지를 함께 작업하는 곳입니다. 유용한 설정을 통해 다음 사람은 고객이 요청한 내용, 팀에서 이미 보낸 내용, 다음 조치를 취해야 할 사람을 확인할 수 있습니다.
이 작업의 일부를 수행할 수 있는 여러 종류의 설정이 있습니다.
| 설정 | 그것이 당신에게 주는 것 | 확인해야 할 사항 |
|---|---|---|
| 사본을 개인 편지함으로 전달하는 주소 | 모든 사람이 수신 이메일을 받습니다. | 각 사람은 어떻게 응답을 보고 누가 응답을 처리하는지 알 수 있습니까? |
| 공유 사서함 | 팀원은 하나의 사서함을 통해 메일을 읽고 보낼 수 있습니다. | 발신 응답은 모든 사람에게 표시되며 소유권을 어떻게 기록합니까? |
| 공유 지원 도구 | 팀 워크플로를 통해 대화를 관리하는 장소 | 테스트 과제, 후속 조치, 내부 토론 및 답변이 실제 제품에 표시됩니다. |
라벨이 겹칩니다. Microsoft는 공유 사서함을 그룹이 공통 주소에서 이메일을 모니터링하고 보내는 방법으로 설명합니다. Google Groups는 대화 할당 및 완료 상태가 포함된 공동작업 받은 편지함을 제공합니다. 기존 이메일 설정에 이미 적합한 것이 있을 수 있습니다. Microsoft 공유 사서함 설명서, Google 공동작업함 문서.
보낸 답장이 어디에서 끝나는지 확인하세요. Microsoft는 보내는 메시지가 기본적으로 공유 사서함의 보낸 편지함이 아닌 보낸 사람의 보낸 편지함에 저장된다고 말합니다. 나머지 팀 구성원에게 해당 기록이 필요한 경우 공유된 보낸 항목을 구성한 다음 두 번째 팀원과 함께 테스트하세요. Microsoft 공유 사서함 설정.
소규모 팀에는 언제 필요한가요?
우리의 다른 프로젝트에서는 루멘폴, 우리는 간단한 Google Groups 설정을 사용합니다. 공유된 info@ 주소로 전송된 이메일은 두 창립자 모두에게 전달됩니다. 그런 다음 누가 어떤 주제를 처리하는지 합의하기 위한 두 번째 채널이 필요합니다.
우리는 계속해서 “X에게 이미 답장을 보냈나요?”라고 묻습니다. 또는 “Y라고 대답할까요?” 종종 우리 둘 다 상대방이 그 문제를 해결했다고 생각합니다. 우리 각자는 이메일 사본을 가지고 있지만, 누가 그것을 처리하고 있는지 확인해야 합니다.
이것이 Lumenfall에서 Google Groups를 사용하는 방법입니다. 위에 링크된 공동작업 받은편지함의 선택적 기능에는 할당이 포함됩니다. 이러한 기능을 사용하든 전용 지원 도구를 사용하든 팀원이 볼 수 있는 대화의 소유자가 누구인지 기록하세요.
소프트웨어를 구입하기 전에 조정 문제를 찾으십시오.
- 두 사람이 같은 이메일에 답장을 보내는 경우도 있습니다.
- 각 사람은 다른 사람이 메시지를 가지고 있다고 생각하기 때문에 메시지에 답이 없습니다.
- 팀원을 대신한다는 것은 팀원에게 대화를 전달하도록 요청하는 것을 의미합니다.
- 약속된 후속 조치는 누군가의 기억이나 개인적인 할 일 목록에 남아 있습니다.
- 개발자가 문제를 해결하지만 누구도 고객에게 이를 알려주지 않습니다.
이메일 볼륨만으로는 언제 설정을 변경해야 하는지 알 수 없습니다. 전달이 복잡한 10개의 메시지는 한 사람이 처리하는 많은 간단한 질문보다 더 많은 조정이 필요할 수 있습니다.
한 사람이 지원을 처리하고 미해결 약속을 모두 찾을 수 있다면 현재 사서함을 유지하는 것이 올바른 선택일 수 있습니다. 여러 사람이 도움을 준다면 먼저 공유 사서함과 명시적인 소유권 루틴을 시도해 보세요. 해당 루틴을 유지 관리하는 것이 자체 작업이 되는 경우 전용 도구를 고려하십시오.
답글을 정리하는 방법
각 대화에 한 명의 소유자를 지정하세요.
소유자는 다음 고객 업데이트를 담당합니다. 해당 책임을 넘기지 않고 개발자에게 조사를 요청할 수 있습니다.
근무 시간 중에 할당되지 않은 새 메일을 확인할 사람과 부재 시 담당할 사람을 선택하세요. 그들이 언제 그것을 확인할 것인지에 동의하십시오. 일정은 팀에 적합해야 합니다. 응답 시간 약속을 게시하는 것은 별도의 결정입니다.
답장을 쓰기 전에 대화를 요청하세요. 소유권이 변경되면 두 사람이 모두 볼 수 있는 새 소유자를 기록해 두세요. "이메일을 열었습니다"를 "내가 처리 중입니다"로 만들지 마세요.
Pipp에서 읽기 상태는 개인별이며 할당은 대화에 속합니다. 할당되지 않은 대화에 답장하면 답장하는 사람에게 대화가 할당됩니다. 우리는 놓친 과제에 대한 대체를 선택했습니다. 가능하면 글을 쓰기 전에 소유권에 동의하세요.
완료와 주의를 분리하라
팀이 동의하는 의미를 지닌 소규모 상태 세트를 사용하세요.
| 상태 | 팀 규칙 | 예 |
|---|---|---|
| 열기 | 누군가는 지금 행동해야 합니다 | 새로운 질문이나 답변이 오늘 마감입니다 |
| 나중에 | 선택한 시간에 돌아오세요. 주인을 지키다 | 내일 고객 업데이트가 예정되어 있어 수정을 기다리는 중입니다. |
| 휴무 | 현재 추가 조치는 계획되어 있지 않음 | 질문에 대한 답변이 완료되었으며 후속 조치가 남아 있지 않습니다. |
우리는 Pipp에 대해 이러한 주 이름을 선택했습니다. 레이블이 다르더라도 다른 도구에서 동일한 규칙을 사용할 수 있습니다.
따로 보관해 둔 모든 것에 반환 시간을 정하세요. "엔지니어링을 기다리는 중"은 종속성을 설명하지만 언제 다시 살펴봐야 하는지 알려주지는 않습니다. 도구에 다시 알림이나 알림 기능이 없으면 소유자의 기존 작업 시스템에 후속 조치를 취하세요.
Pipp에서는 "해결됨" 대신 "닫힘"을 선택했습니다. 활성 목록에서 이메일을 이동한다고 해서 고객의 문제가 해결되었음을 증명하는 것은 아닙니다. 확인을 보낸 후에도 답변이 남아 있는 경우 검토를 위해 대화를 계속 진행하세요.
누군가가 조치를 취할 수 있도록 핸드오프를 남겨두세요.
내부 메모에는 알려진 내용, 여전히 불확실한 내용, 고객에 대한 다음 약속을 설명해야 합니다. 보내는 답장과 별도로 보관하고 보내기 전에 작성기 모드를 확인하세요.
소규모 소프트웨어 팀을 위한 가상의 핸드오프:
고객이 CSV 가져오기를 완료할 수 없습니다. 샘플 파일을 이용하여 실패를 재현해봤습니다. Lina가 파서를 확인하고 있습니다. 수정 사항이 준비되지 않았더라도 내일 14:00까지 업데이트하겠다고 고객에게 말했습니다. Sam이 해당 업데이트를 소유하고 있습니다.
Sam은 고객 대화를 자신에게 할당된 상태로 유지합니다. Lina는 팀의 개발 추적기에서 기술 조사를 담당합니다. Sam은 약속된 업데이트 이전에 대한 후속 조치를 설정합니다. 이렇게 하면 Lina의 코드 변경이 다시 작성하라는 유일한 알림이 되는 것을 방지할 수 있습니다.
Sam이 떠나면 핸드오프에는 지명된 교체와 동일한 약속이 필요합니다. “누가 후속 조치를 취할 수 있나요?” 일자리를 구하지 않은 채로 둡니다.
보내기 전에 스레드를 확인하세요
최신 고객 메시지와 최신 팀 답변을 읽어보세요. 팀원의 보기 또는 입력 표시는 유용한 컨텍스트이지만 다른 응답을 보낼 수 없다는 것을 보장하지는 않습니다.
Pipp의 디자인에서 현재 상태는 팀원이 전송을 차단하지 않고도 이중 응답을 방지하는 데 도움이 됩니다. 또한 팀원들은 초안이 존재한다는 사실을 확인할 수 있으며 해당 텍스트는 작성자에게 비공개로 유지됩니다.
전송 상태도 확인하세요. Pipp 사양에서 "Queued"는 응답이 장치에서 대기 중임을 의미하고 "Sent"는 이메일 공급자가 이를 수락했음을 의미하며 "Delivered"는 공급자의 배달 이벤트가 필요함을 의미합니다. 이것이 우리 디자인의 상태 규칙입니다.
어떤 도구를 사용하든 고객에게 답변이 도착했음을 알리기 전에 상태 라벨이 실제로 무엇을 확인하는지 알아보세요.
도구를 변경하기 전에 루틴을 시도해 보십시오.
가상의 이메일 몇 개를 사용하여 팀원과 함께 후보 설정을 테스트해 보세요.
- 외부 주소에서 질문을 보냅니다. 한 팀원이 답장을 보내고 다른 팀원은 보낸 답장을 찾도록 합니다. 고객에게 표시되는 주소를 확인하세요.
- 자신에게 질문을 할당하고 내부 도움을 요청한 다음 넘겨주세요. 새 주인이 당신에게 묻지도 않고 당신이 한 약속을 찾을 수 있을까요?
- 특정 시간까지 대화를 따로 설정하세요. 그것이 어떻게 주의를 끌게 되는지, 그렇게 되면 누가 책임을 지는지 확인하십시오.
- 대화를 종료한 후 고객에게 다시 글을 쓰도록 하세요. 새 메시지가 어떻게 표시되는지 확인하세요.
- 팀원과 동시에 답장을 시작하세요. 각 사람이 볼 수 있는 것과 도구가 실제로 무엇을 방지하는지 확인하세요.
짧은 평가판 기간 동안 누락된 후속 조치와 중복된 답변은 물론 다른 곳에서 추적 중인 모든 작업을 기록하세요. 설정이 핸드오프 및 후속 약속을 얼마나 잘 처리하는지에 따라 선택하십시오.
Pipp가 맞는 곳
Pipp는 창립자와 소규모 팀을 위한 팀 받은 편지함이며, Pipp AI가 내장되어 있으며 자신의 AI 에이전트가 무료로 액세스할 수 있습니다. 우리는 1~10명으로 구성된 팀을 위해 디자인합니다. 이는 공개된 좌석 제한이 아닙니다.
Pipp에는 할당, 시작, 나중에 및 종료 상태, 내부 메모 및 팀원 존재가 포함됩니다.
Pipp는 현재 이메일을 다루고 있으며 채팅은 이미 진행 중입니다. 팀원은 앱, 브라우저 및 이메일을 통해 필요한 작업에 대해 듣습니다. 누군가가 그들에게 대화를 할당하거나 메모에서 언급하거나 고객이 대화에 응답할 때 가능합니다. 태그와 저장된 답변은 아직 Pipp의 일부가 아닙니다.
계정을 만들고 받은편지함을 설정하세요. 도메인을 인증하기 전에도 이메일을 받고, 읽고, 초안을 작성할 수 있습니다.
고객에게 답장하려면 DNS 레코드로 자신의 발신 도메인을 확인한 다음 받은편지함에 대해 활성화된 도메인을 선택하세요.
각 작업 영역은 하나의 전송 도메인을 연결할 수 있습니다. 모든 워크스페이스는 고객에게 답장을 보내기 전에 자체 도메인을 확인해야 합니다.
현재 계정당 하루에 최대 3개의 워크스페이스를 만들 수 있습니다. 각 워크스페이스는 수신자별 이메일 전달 횟수를 기준으로 하루 최대 100건을 보낼 수 있습니다.
To 또는 Cc의 수신자는 각각 따로 계산합니다. To의 2명과 Cc의 1명에게 보낸 이메일은 전달 3건으로 계산합니다. 두 일일 한도는 모두 00:00 UTC에 초기화됩니다.
한도 해제가 필요하시면 다음 주소로 이메일을 보내 주세요: hello@pipp.so.
Pipp가 팀에 필요한 작업을 처리하는지 평가하는 동안 현재 지원을 계속 실행하세요.
Pipp AI는 베타 버전이며 기본적으로 꺼져 있습니다. 소유자 또는 관리자가 설정 → AI에서 켤 수 있습니다. AI 없이 이 가이드의 모든 단계를 수행할 수 있습니다.
기본 공유 이메일 받은 편지함과 상담원 액세스는 영원히 무료입니다. Pipp AI는 베타 기간 동안 무료이며 베타 이후에는 합리적인 가격으로 제공됩니다. 우리는 가격을 발표하지 않았습니다.
이 가이드 정보
스위스 회사 Telesoft AG의 제품인 Pipp를 위해 작성되었습니다. 출처는 24 9월 2026에서 확인되었습니다.
Microsoft 및 Google의 공식 문서는 위에 링크된 사서함 세부 정보를 지원합니다. 우리 창립자는 Google Groups 설정 경험을 바탕으로 Lumenfall 계정을 제공했습니다. 이는 Lumenfall이 Pipp를 채택했거나 개선을 측정했다는 주장 없이 우리가 직면한 문제를 설명합니다. Pipp 예제는 기록된 설계 결정에서 나온 것입니다. 가상의 핸드오프는 조언을 설명하는 것이며 고객 이야기가 아닙니다.