솔루션 / 대행사 및 스튜디오
비즈니스를 운영하는 클라이언트 포털
모든 클라이언트는 파일, 상태, 결과물 등 자신만의 공간을 갖게 되며, 보유자는 스스로 비용을 청구하고 프로젝트 도구는 동기화된 계속 유지합니다.
구축 사례
클라이언트 포털 SaaS 대신 이것을 구축하는 이유는 무엇입니까?
Portal SaaS는 시트당 가격이 책정되며 일반 대행사에 맞게 조합됩니다. 사용자의 회사는 그렇지 않습니다. 결국 라벨과 일치하도록 배송 단계의 이름을 바꾸고, 모델링할 수 없는 부분을 스프레드시트로 내보내고, 팀이 성장할 때마다 비용을 다시 지불하게 됩니다. Kliv는 사용자의 도메인에서 사용자의 스튜디오를 중심으로 사용자의 스테이지, 언어, 클라이언트 경험 등의 포털을 빌드합니다.
사용자의 전달 프로세스는 차별화 요소(요약, 개념, 수정 라운드, 승인)이므로 포털은 이를 문자 그대로 모델링해야 합니다. 각 클라이언트는 자체 인력, 프로젝트 및 파일이 데이터베이스로 분리된 조직입니다. 제공 방법을 구체화하면 포털은 공급업체에 대한 기능 요청이 아닌 문장으로 따릅니다.
시스템 분석
포털이 실제로 알고 있는 것
대행사 포털은 일반 프로젝트 도구가 모호하게 만드는 두 가지 요소, 즉 팀이 내부적으로 작업하는 방식과 각 클라이언트가 볼 수 있는 항목을 분리해야 합니다. 한 클라이언트의 마케팅 디렉터는 캠페인 달력, 브랜드 파일, 인보이스 및 개정 스레드를 볼 수 있지만 URL을 변경하거나 ID를 추측하여 다른 클라이언트의 프로젝트를 찾을 수는 없습니다. Kliv가 구축할 시스템의 모양은 다음과 같습니다.
클라이언트
각 클라이언트는 조직입니다. 사용자, 프로젝트, 파일, 승인 및 청구 내역이 해당 벽 안에 있습니다.
프로젝트
각각에 속하는 파일과 스레드를 사용하여 개요, 개념, 수정 라운드, 승인 등의 단계를 수행하세요.
제공물
소스 파일, 프리젠테이션 및 최종본 — 클라이언트별로 공유되며 기본적으로 비공개입니다.
승인
사인오프는 숨겨진 이메일 스레드가 아닌 작업에 대한 기록된 상태입니다.
보유자 및 인보이스
구독 상태, 인보이스, 구매 내역 등 상업적 관계가 동일한 고객 기록에 첨부됩니다.
요청
수신 클라이언트 요청의 대기열이며 요청을 제기한 클라이언트로 범위가 지정됩니다.
누가 무엇을 보는지
데이터베이스가 시행하는 규칙
- 클라이언트 사용자는 자신의 조직에 속한 행만 읽을 수 있습니다. URL이나 ID를 추측하면 아무것도 반환되지 않습니다.
- 파일은 기본적으로 비공개입니다. 공유는 링크별로가 아닌 클라이언트별로 이루어집니다.
- 결제 세부정보는 팀의 모든 구성원이 아닌 고객 소유자에게 표시됩니다.
- 보유 기간이 만료되면 권한이 제한된 영역을 닫습니다. 누구도 액세스 권한을 취소하는 것을 기억할 필요가 없습니다.
결과는 일반적인 카테고리로서의 “포털”이 아닙니다. 클라이언트, 단계, 파일, 승인, 지불 및 권한이 모두 동일한 관계를 설명하는 소프트웨어로 전환된 전달 모델입니다.
Kliv가 조립하는 것
플랫폼 제품 쇼핑 목록 — 각 제품은 내장되어 있으며 나머지 제품과 함께 조합됩니다.
클라이언트별로 벽으로 둘러싸인 하나의 포털
각 클라이언트는 조직입니다. 클라이언트의 사람들은 자신의 프로젝트와 파일을 볼 수 있으며 다른 클라이언트의 프로젝트와 파일은 볼 수 없습니다. 페이지 로직이 아닌 데이터베이스에서 시행됩니다.
충전 방법
대행사가 비용을 청구할 수 있는 세 가지 방법
대행사는 한 가지 물건만 판매하는 경우가 거의 없습니다. 동일한 클라이언트가 전략 스프린트로 시작하여 월간 리테이너로 전환한 다음 출시 중에 추가 생산 용량을 구매할 수 있습니다. 포털은 모든 관계를 동일한 인보이스 템플릿에 강제로 적용하는 대신 이러한 형태를 직접 이해해야 합니다.
월간 리테이너
$6,000/월
지속적인 참여를 통한 성장 클라이언트
요청 대기열, 월별 보고, 공유 파일 보관소 및 두 가지 전략 호출.
- 잠금 해제
- 활성 구독은 공개 요청, 활성 결과물, 보고 및 승인된 자산 등 관계에 속하는 포털의 일부를 엽니다.
- 결제
- 변경 사항에 대해 공정하게 비례 배분하여 매월 갱신합니다. 카드에 문제가 발생하면 복구 이메일이 발송되고 청구가 해결될 때까지 액세스 권한이 제한될 수 있습니다.
- 환불
- 환불 요청은 자금 이동 전 승인 단계를 거칩니다.
고정 범위 프로젝트
1회 $18,000
범위가 정의된 브랜드 새로고침 클라이언트
프로젝트 타임라인, 소스 파일 업로드, 컨셉 프레젠테이션, 수정 라운드 및 최종 전달.
- 잠금 해제
- 구매하면 해당 프로젝트의 공간이 열립니다. 고객은 내부 작업 공간이 아닌 자신의 범위에 연결된 작업을 볼 수 있습니다.
- 결제
- 고객의 청구 페이지에 청구 1회, 영수증 1회, 전체 구매 내역이 표시됩니다. 프로젝트가 완료되면 공간은 보관 모드로 전환됩니다.
- 환불
- 동일한 승인 흐름 — 환불은 실수가 아닌 결정입니다.
사용 기반 추가 기능
추가 서류당 $250
실행 중 볼륨이 급증하는 콘텐츠 클라이언트
기본 리테이너와 측정된 추가 항목(랜딩 페이지 개요, 추가 편집 동영상)이 포함된 볼륨을 초과합니다.
- 잠금 해제
- 측정은 클라이언트의 로그인 활동에 대해 실행되므로 포함된 항목, 사용된 항목, 청구되는 항목이 양쪽에서 모두 표시됩니다.
- 결제
- 추가 요금은 미터에 적립되며 구독과 함께 청구됩니다. 승인된 추가 항목이 포함된 측면 스프레드시트는 없습니다.
- 환불
- 이의가 제기된 항목은 동일한 승인 기반 환불 절차를 통해 해결됩니다.
출시 전
출시 전 첫 주
클라이언트 포털을 시작하지 않고 희망합니다. 이것이 첫 번째 주가 실제로 보이는 모습입니다. 그리고 포털이 이미 1년을 보낸 것으로 끝납니다.
포털 형성
스튜디오 운영 방식(고객 도착 방법, 배송 단계, 팀 구성원 등)을 설명하세요. Kliv는 클라이언트 조직, 사용자의 언어로 된 프로젝트, 이미 설치된 벽 등 첫 번째 미리보기를 빌드합니다.
사용자의 것으로 만드세요
대화를 통해 일반 라벨 대신 무대 이름, 브랜드, 도메인 등을 지적하여 구체화하세요. 모든 변경사항은 다른 사람이 보기 전에 미리보기로 표시됩니다.
실물 로드
실제 제안(리테이너 계획, 프로젝트 제품)을 만들고 팀을 초대하고 실제 고객 브리핑을 이동하여 실제 콘텐츠가 포함된 포털을 확인하세요.
부수어 보세요
테스트 클라이언트로 로그인하고 벽을 확인하세요. 다른 클라이언트의 프로젝트를 볼 수 있나요? 결제를 실행하고, 고의로 카드를 실패시키고, 환불을 요청하세요. 복구 이메일과 승인 단계가 제 역할을 하는지 지켜보세요.
그런 다음 1년 동안 리허설
이것은 다른 구축 방법이 제공하지 않는 부분입니다. Sandbox에서 시뮬레이션된 돈과 시뮬레이션된 시간을 사용하여 12개월을 빨리 감습니다. 보유자가 갱신되고, 카드가 3월에 만료되고 4월에 복구되고, 취소하면 올바른 문이 닫히는 것을 지켜보세요. 게시할 때 추측을 전달하는 것이 아니라 이미 1년 동안 사용자의 비즈니스를 운영한 포털을 전달하는 것입니다.
맞춤형 위험이 없는 맞춤형
예산, 계약자 및 유지 관리 계약을 의미하는 데 사용되는 맞춤형 소프트웨어입니다. 이것은 다른 거래입니다.
엔터프라이즈급 부품
로그인, 데이터베이스에서 시행되는 권한, 청구, 감사, 이메일 — 맞춤형 시스템의 구성 요소는 모든 Kliv 앱이 실행되는 것과 동일하게 강화된 부분입니다. 검증된 인프라를 조합합니다. 코드를 처음부터 시작하지 않습니다.
변경사항은 순서대로 배송됩니다
프로세스가 변경되면 그렇게 말하세요. 변경 사항은 대화에 내장되어 있으며 실시간 미리보기에서 검토하고 게시할 때까지 사용자에게 아무 것도 전달되지 않습니다. 시뮬레이션된 비용과 시간을 사용하여 Sandbox에서 커머스 변경 사항을 연습할 수도 있습니다.
아무도 일몰할 수 없습니다
기성 도구는 공급업체의 일정에 따라 가격이 조정되고, 재설계되고, 폐기되며 사용자의 작업 흐름도 그에 맞춰 진행됩니다. Kliv 앱은 사용자가 변경할 때만 변경됩니다. 그것은 다른 사람의 좌석이 아닌 사용자의 제품입니다.
한 문장으로 말해보세요
“각 클라이언트가 자신의 프로젝트와 파일만 볼 수 있는 클라이언트 포털을 빌드하고, 보유자는 매월 요금을 청구하며, 새 클라이언트 요청에 따라 우리 팀을 위한 Trello 카드가 생성됩니다.”
이것이 진정한 시작 방법입니다. 설명하고 대화를 통해 다듬으세요.
제작 또는 구매
그냥 포털을 구매하면 어떨까요?
| 기성품 | Kliv | |
|---|---|---|
| 클라이언트 분리 | 작업 공간 및 권한 체크박스 — 수동으로 구성되며 누군가가 참여할 때마다 다시 확인됩니다. | 각 클라이언트는 조직입니다. 행 수준 데이터베이스 규칙은 숨길 뿐만 아니라 클라이언트 간 읽기도 불가능하게 만듭니다. |
| 배송 단계 | 파이프라인 라벨 이에 맞게 프로세스를 조정하세요. | 사용자의 단어(요약, 개념, 라운드, 승인)는 사용자가 이미 전달하는 방식을 모델링했습니다. |
| 비용 구조 | 사용자당, 월별 — 비용은 수익이 아닌 팀과 함께 증가합니다. | 사용자는 시스템을 소유하고 이를 통해 고객에게 비용을 청구합니다: 리테이너, 프로젝트, 계량된 추가 기능 |
| 작업 방식 변경 | 기능 요청, 로드맵 투표, 기다림 | 대화 속 문장, 미리보기, 게시 |
| 사용자의 데이터 | 계획에 따라 허용되는 형식으로 내보낼 수 있습니다. | 프로젝트, 파일, 승인 및 청구 내역은 자체 데이터베이스의 행입니다. |
클라이언트 분리
기성품: 작업 공간 및 권한 체크박스 — 수동으로 구성되며 누군가가 참여할 때마다 다시 확인됩니다.
Kliv: 각 클라이언트는 조직입니다. 행 수준 데이터베이스 규칙은 숨길 뿐만 아니라 클라이언트 간 읽기도 불가능하게 만듭니다.
배송 단계
기성품: 파이프라인 라벨 이에 맞게 프로세스를 조정하세요.
Kliv: 사용자의 단어(요약, 개념, 라운드, 승인)는 사용자가 이미 전달하는 방식을 모델링했습니다.
비용 구조
기성품: 사용자당, 월별 — 비용은 수익이 아닌 팀과 함께 증가합니다.
Kliv: 사용자는 시스템을 소유하고 이를 통해 고객에게 비용을 청구합니다: 리테이너, 프로젝트, 계량된 추가 기능
작업 방식 변경
기성품: 기능 요청, 로드맵 투표, 기다림
Kliv: 대화 속 문장, 미리보기, 게시
사용자의 데이터
기성품: 계획에 따라 허용되는 형식으로 내보낼 수 있습니다.
Kliv: 프로젝트, 파일, 승인 및 청구 내역은 자체 데이터베이스의 행입니다.
자주 묻는 질문
클라이언트 분리는 실제로 어떻게 시행되나요?
데이터베이스에서. 모든 클라이언트는 조직이며 행 수준 규칙은 사용자가 자신의 프로젝트와 파일만 읽을 수 있음을 의미합니다. 격리는 데이터의 속성이지 숨기려고 기억한 링크가 아닙니다.
고객이 포털을 통해 보유자에게 비용을 지불할 수 있나요?
예 — 일할 계산 및 일시 중지, 일회성 프로젝트 비용 및 셀프 서비스 청구 페이지가 포함된 월별 보유자입니다. 만료된 카드는 자동으로 재시도되고 추적됩니다.
우리 팀이 이미 사용하고 있는 도구에 연결되나요?
그렇습니다. 새로운 클라이언트 요청으로 Trello 카드를 생성할 수 있고 승인으로 Slack을 핑할 수 있습니다. 클라이언트가 하나의 깨끗한 포털을 얻는 동안 팀은 도구를 그대로 유지합니다.
계약업체의 접근이 제한될 수 있나요?
예 — 역할은 동일한 신원 시스템의 일부이므로 계약자는 자신에게 할당된 프로젝트만 볼 수 있으며 인보이스, 보유 기간, 다른 고객은 볼 수 없습니다. 규칙은 데이터베이스에 있으므로 어디에서나 적용됩니다.
계약이 종료되면 고객의 공간은 어떻게 되나요?
오프보딩에서 말하는 내용은 무엇이든 가능합니다. 일반적인 패턴: 리테이너가 종료되면 공간이 아카이브로 이동합니다. 최종 파일, 인보이스 및 승인은 계속 읽을 수 있는 상태로 유지되는 반면, 새로운 범위를 구매할 때까지 새로운 요청 및 개정 라운드가 닫힙니다.
우리는 일부 고객에게 월별 비용을 청구하고 일부 고객에게는 프로젝트별로 비용을 청구합니다. 하나의 포털이 두 가지를 모두 처리할 수 있나요?
예 — 리테이너는 구독이고 프로젝트는 동일한 카탈로그의 일회성 구매이며, 클라이언트는 두 가지를 동시에 보유할 수 있습니다. 각각은 공간의 일부를 잠금 해제하고 인보이스는 하나의 청구 페이지에 표시됩니다.
