Kliv

    Giải pháp / Agency và studio

    Cổng khách hàng vận hành cả doanh nghiệp

    Mỗi khách hàng có không gian riêng có tường ngăn — tệp, trạng thái, deliverable — trong khi retainer tự lập hóa đơn và công cụ dự án của bạn luôn đồng bộ.

    Tất cả ngành

    Lý do để xây

    Vì sao xây cái này thay vì dùng SaaS cổng khách hàng?

    SaaS cổng khách hàng tính giá theo ghế và được nặn cho agency trung bình — mà agency của bạn thì không. Bạn phải đổi tên các giai đoạn giao hàng cho khớp nhãn của họ, xuất bảng tính cho những phần họ không mô hình hóa được, và trả thêm mỗi khi đội lớn lên. Kliv xây cổng quanh studio của bạn: giai đoạn của bạn, ngôn ngữ của bạn, trải nghiệm khách hàng của bạn, trên domain của bạn.

    Quy trình giao hàng là điểm khác biệt — brief, concept, vòng sửa, sign-off — nên cổng phải mô hình hóa nó đúng nghĩa. Mỗi khách hàng là một tổ chức với người, dự án và tệp riêng, được ngăn ở cơ sở dữ liệu. Khi bạn tinh chỉnh cách giao hàng, cổng đi theo bằng một câu nói, không phải feature request gửi vendor.

    Giải phẫu hệ thống

    Cổng thật sự biết gì

    Một cổng agency phải tách hai thứ mà công cụ dự án chung thường làm mờ: cách đội bạn làm việc bên trong, và thứ mỗi khách hàng được phép thấy. Giám đốc marketing ở một khách hàng có thể thấy lịch campaign, tệp thương hiệu, hóa đơn và thread sửa đổi của họ — và không thể phát hiện dự án của khách hàng khác bằng cách đổi URL hay đoán ID. Đây là hình dạng hệ thống Kliv sẽ xây.

    Khách hàng

    Mỗi khách hàng là một tổ chức — người dùng, dự án, tệp, phê duyệt và lịch sử billing của họ nằm bên trong bức tường đó.

    Dự án

    Mang các giai đoạn của bạn — brief, concept, vòng sửa, sign-off — cùng tệp và thread thuộc về từng giai đoạn.

    Deliverable

    Tệp nguồn, bài thuyết trình và bản cuối — chia sẻ theo từng khách hàng, mặc định là riêng tư.

    Phê duyệt

    Sign-off là trạng thái được ghi trên công việc, không phải thread email bị chôn.

    Retainer và hóa đơn

    Quan hệ thương mại — trạng thái gói đăng ký, hóa đơn, lịch sử mua — gắn với cùng record khách hàng.

    Yêu cầu

    Hàng đợi các yêu cầu khách hàng gửi vào, nằm trong phạm vi khách hàng đã tạo chúng.

    Ai thấy gì

    Đội studioThấy xuyên qua các tài khoản khách hàng họ quản lý — dự án, tệp, billing.
    Chủ sở hữu phía khách hàngThấy dự án, hóa đơn, phê duyệt và tệp chia sẻ của tổ chức họ.
    Người đóng góp phía khách hàngTải tệp nguồn lên và bình luận trên bản nháp — không billing, không hợp đồng.
    ContractorThấy các dự án họ được phân công — không điều khoản retainer, không khách hàng khác.

    Quy tắc cơ sở dữ liệu thực thi

    • Người dùng phía khách hàng chỉ đọc được hàng thuộc tổ chức của họ — đoán URL hay ID cũng trả về rỗng.
    • Tệp mặc định là riêng tư; chia sẻ theo khách hàng, không theo link.
    • Chi tiết billing hiển thị với chủ sở hữu phía khách hàng, không phải mọi người trong đội của họ.
    • Khi retainer hết hạn, quyền dùng đóng các khu vực đặt sau cổng — không ai phải nhớ thu hồi quyền truy cập.

    Kết quả không phải “một cổng” như danh mục chung. Nó là mô hình giao hàng của bạn biến thành phần mềm: khách hàng, giai đoạn, tệp, phê duyệt, thanh toán và quyền đều mô tả cùng một quan hệ.

    Kliv lắp ráp những gì

    Một danh sách mua sắm các mảnh nền tảng: từng mảnh có sẵn, từng mảnh kết hợp được với phần còn lại.

    Một cổng, có tường ngăn cho từng khách hàng

    Mỗi khách hàng là một tổ chức: người của họ thấy dự án và tệp của họ, không bao giờ của khách hàng khác. Thực thi ở cơ sở dữ liệu, không trong logic trang của bạn.

    Retainer tự chạy

    Retainer hằng tháng với phân bổ phí công bằng và tạm dừng — dunning đuổi theo thẻ hết hạn để bạn không phải làm.

    Deliverable, chia sẻ an toàn

    Chia sẻ tệp theo từng khách hàng cho brief, asset và bản cuối — mặc định là riêng tư.

    Công cụ của đội bạn, đã nối vào

    Yêu cầu mới từ khách hàng trở thành thẻ Trello; Slack ping khi họ phê duyệt.

    Trợ lý biết tài khoản

    Khách hàng hỏi “dự án của tôi đang ở đâu?” và tác nhân trả lời từ dữ liệu riêng của họ — giới hạn trong tổ chức của họ.

    Cách thu phí

    Ba cách một agency có thể thu phí

    Agency hiếm khi bán một thứ. Cùng một khách hàng có thể bắt đầu bằng sprint chiến lược, chuyển sang retainer hằng tháng, rồi mua thêm năng lực sản xuất trong một đợt ra mắt. Cổng nên hiểu trực tiếp các hình dạng đó thay vì ép mọi quan hệ vào cùng một template hóa đơn.

    Retainer hằng tháng

    $6,000/tháng

    Khách hàng tăng trưởng trong engagement đang diễn ra

    Hàng đợi yêu cầu, báo cáo hằng tháng, kho tệp chia sẻ và hai cuộc gọi chiến lược.

    Quyền dùng
    Gói đăng ký còn hoạt động mở các phần của cổng thuộc về quan hệ đó: yêu cầu mở, deliverable đang chạy, báo cáo và asset đã phê duyệt.
    Billing
    Gia hạn hằng tháng với phân bổ phí công bằng khi thay đổi. Nếu thẻ thất bại, email khôi phục được gửi và quyền truy cập có thể thu hẹp đến khi billing được sửa.
    Hoàn tiền
    Yêu cầu hoàn tiền đi qua bước phê duyệt trước khi tiền di chuyển.

    Dự án scope cố định

    $18,000 một lần

    Khách hàng làm mới thương hiệu với scope đã xác định

    Timeline dự án, upload tệp nguồn, trình bày concept, vòng sửa và giao bản cuối.

    Quyền dùng
    Giao dịch mua mở không gian của dự án đó — khách hàng thấy công việc gắn với scope của họ, không phải workspace nội bộ của bạn.
    Billing
    Một khoản thu, một biên nhận, toàn bộ lịch sử mua trên trang billing của khách hàng. Khi dự án hoàn tất, không gian chuyển sang chế độ archive.
    Hoàn tiền
    Cùng luồng phê duyệt — hoàn tiền là một quyết định, không phải tai nạn.

    Phần cộng thêm theo usage

    $250 mỗi brief thêm

    Khách hàng nội dung có volume tăng mạnh trong các đợt ra mắt

    Một retainer nền cộng phần thêm đo được — brief landing page, video chỉnh sửa bổ sung — vượt ngoài volume đã gồm.

    Quyền dùng
    Metering chạy trên hoạt động đã đăng nhập của khách hàng, nên thứ đã gồm, thứ đã dùng và thứ sẽ được billing đều hiển thị cho cả hai bên.
    Billing
    Phần thêm tích lũy trên meter và billing cùng gói đăng ký — không có bảng tính phụ cho các khoản thêm đã duyệt.
    Hoàn tiền
    Line item bị tranh chấp được xử lý qua cùng luồng hoàn tiền đặt sau phê duyệt.

    Trước khi ra mắt

    Tuần đầu tiên, trước khi ra mắt

    Bạn không ra mắt cổng khách hàng rồi hy vọng. Đây là hình dạng thật của tuần đầu tiên — và nó kết thúc với việc cổng đã sống qua một năm.

    Ngày 1

    Định hình cổng

    Mô tả cách studio làm việc: khách hàng đến thế nào, các giai đoạn giao hàng, ai ở trong đội. Kliv xây bản xem trước đầu tiên — tổ chức khách hàng, dự án bằng ngôn ngữ của bạn, các bức tường đã dựng sẵn.

    Ngày 2

    Làm nó thành của bạn

    Tinh chỉnh bằng trò chuyện và bằng cách chỉ vào thứ cần đổi: tên giai đoạn của bạn thay cho nhãn chung, thương hiệu của bạn, domain của bạn. Mỗi thay đổi đi vào bản xem trước trước khi ai khác thấy.

    Ngày 3

    Nạp thứ thật

    Tạo các offer thật — gói retainer, sản phẩm dự án — mời đội của bạn, và đưa một brief khách hàng thật vào để xem cổng với nội dung thật.

    Ngày 4

    Thử phá nó

    Đăng nhập như khách hàng test và kiểm tra các bức tường: họ có thấy dự án của khách hàng khác không? Chạy checkout, cố ý làm thẻ thất bại, yêu cầu hoàn tiền — xem email khôi phục và bước phê duyệt làm đúng việc của chúng.

    Rồi diễn tập một năm

    Đây là phần không cách xây nào khác cho bạn: trong Sandbox, với tiền mô phỏng và thời gian mô phỏng, tua nhanh mười hai tháng. Xem retainer gia hạn, một thẻ hết hạn vào tháng Ba và khôi phục vào tháng Tư, một lượt hủy đóng đúng cánh cửa. Khi bạn publish, bạn không ship một phỏng đoán — bạn ship một cổng đã chạy một năm của doanh nghiệp.

    Bespoke, không kèm rủi ro bespoke

    Phần mềm tùy chỉnh từng có nghĩa là ngân sách, nhà thầu và hợp đồng bảo trì. Đây là một thỏa thuận khác.

    Các mảnh cấp enterprise

    Đăng nhập, quyền được cơ sở dữ liệu thực thi, billing, audit, email: các thành phần bên dưới hệ thống bespoke của bạn là cùng những mảnh cứng cáp mà mọi app Kliv chạy trên. Bạn kết hợp hạ tầng đã được chứng minh; bạn không đặt viết code từ số không.

    Thay đổi publish có trật tự

    Khi quy trình của bạn đổi, hãy nói ra: thay đổi được xây trong cuộc trò chuyện, bạn review nó trong bản xem trước live, và không gì tới người dùng cho đến khi bạn publish. Thay đổi commerce thậm chí có thể được diễn tập trong Sandbox bằng tiền mô phỏng và thời gian mô phỏng.

    Không ai có thể khai tử nó

    Công cụ có sẵn bị đổi giá, đổi thiết kế và ngừng chạy theo lịch của vendor: workflow của bạn đi theo chúng. App Kliv của bạn chỉ thay đổi khi bạn thay đổi nó. Đó là sản phẩm của bạn, không phải một ghế trong sản phẩm của người khác.

    Nói nó trong một câu

    kliv.dev

    “Xây một cổng khách hàng nơi mỗi khách hàng chỉ thấy dự án và tệp của riêng họ, retainer được billing hằng tháng, và yêu cầu mới từ khách hàng tạo một thẻ Trello cho đội của tôi.”

    Nó thật sự bắt đầu như vậy: mô tả, rồi tinh chỉnh trong cuộc trò chuyện.

    Xây hay mua

    Vì sao không chỉ mua một cổng?

    Tách khách hàng

    Có sẵn: Workspace và checkbox quyền — cấu hình bằng tay, kiểm lại mỗi khi có người tham gia.

    Với Kliv: Mỗi khách hàng là một tổ chức; quy tắc cơ sở dữ liệu cấp hàng khiến việc đọc chéo khách hàng là bất khả, không chỉ bị giấu.

    Giai đoạn giao hàng của bạn

    Có sẵn: Nhãn pipeline của họ; bạn chỉnh quy trình cho vừa chúng.

    Với Kliv: Từ của bạn — brief, concept, vòng sửa, sign-off — được mô hình hóa theo cách bạn đã giao hàng.

    Cấu trúc chi phí

    Có sẵn: Theo ghế, theo tháng — hóa đơn tăng theo đội của bạn, không theo doanh thu.

    Với Kliv: Bạn sở hữu hệ thống — và thu phí khách hàng qua nó: retainer, dự án, phần cộng thêm đo được.

    Đổi cách bạn làm việc

    Có sẵn: Một feature request, một lượt vote roadmap, một lần chờ.

    Với Kliv: Một câu trong trò chuyện, một bản xem trước, một lần publish.

    Dữ liệu của bạn

    Có sẵn: Xuất được, trong định dạng gói của họ cho phép.

    Với Kliv: Dự án, tệp, phê duyệt và lịch sử billing là hàng trong cơ sở dữ liệu riêng của bạn.

    Câu hỏi thường gặp

    Việc tách khách hàng thật sự được thực thi bằng cách nào?

    Ở cơ sở dữ liệu. Mỗi khách hàng là một tổ chức, và quy tắc cấp hàng nghĩa là người dùng của họ chỉ có thể đọc dự án và tệp của chính họ — cô lập là thuộc tính của dữ liệu, không phải của những link bạn nhớ giấu.

    Khách hàng có thể trả retainer qua cổng không?

    Có — retainer hằng tháng với phân bổ phí công bằng và tạm dừng, phí dự án một lần, và trang billing tự phục vụ. Thẻ hết hạn được thử lại và đuổi theo tự động.

    Nó có kết nối với công cụ đội tôi đang dùng không?

    Có. Yêu cầu mới từ khách hàng có thể tạo thẻ Trello, một phê duyệt có thể ping Slack — đội của bạn giữ công cụ của mình, còn khách hàng nhận một cổng sạch.

    Contractor có thể có quyền truy cập giới hạn không?

    Có — vai trò là một phần của cùng hệ thống định danh, nên contractor thấy các dự án họ được phân công và không gì khác: không billing, không điều khoản retainer, không khách hàng khác. Quy tắc sống ở cơ sở dữ liệu, nên nó giữ ở mọi nơi.

    Điều gì xảy ra với không gian khách hàng khi engagement kết thúc?

    Theo đúng offboarding của bạn. Một mẫu thường gặp: khi retainer kết thúc, không gian chuyển sang archive — tệp cuối, hóa đơn và phê duyệt vẫn đọc được, còn yêu cầu mới và vòng sửa đóng lại cho đến khi có scope mới được mua.

    Chúng tôi billing một số khách hằng tháng và một số theo dự án. Một cổng xử lý được cả hai không?

    Có — retainer là gói đăng ký còn dự án là giao dịch mua một lần trong cùng danh mục, và một khách hàng có thể giữ cả hai cùng lúc. Mỗi loại mở phần không gian của nó, và hóa đơn nằm trên một trang billing.

    Mô tả của bạn. Kliv xây nó.

    Bắt đầu bằng một câu; ship cả hệ thống.

    Giá