Phần mềm phê duyệt cho agency, gom mọi quyết định vào một hộp thư

Ma trận phê duyệt: ai quyết định gì, và bằng quyền nào

Chốt việc này một lần, trước lần triển khai đầu tiên, và mọi cuộc tranh cãi về sau xem ai lẽ ra phải duyệt một việc sẽ ngắn đi. Bảng dưới đây nêu những gì console đang thực thi hiện nay, từng dòng một.

Theo mặc định, một thành viên đội ngũ agency có thể xem, tạo và chỉnh sửa tài sản Thư viện và kế hoạch, nghĩa là họ gửi được kế hoạch để duyệt nhưng không duyệt hay xuất bản được. Một yêu cầu triển khai chiến dịch email hoặc SMS còn cần người đề nghị có quyền truy cập CRM, thứ mà thành viên đội ngũ không có theo mặc định. Quản trị viên agency giữ mọi quyền. Một quản trị viên có thể cấp quyền “Approve” hoặc “Publish” cho một trưởng nhóm, từng người một hoặc qua mẫu quyền, và một đồng nghiệp chỉ hành động trên những khách hàng họ được phân công. Quyết định nghỉ phép hoàn toàn không ủy quyền được.

Người gửi duyệt, người xem xét, người duyệt, publisher và người đề nghị, nói bằng lời giản dị

Năm từ này xuất hiện ở mọi tab. Mỗi từ chỉ có một nghĩa.

Submitter (người gửi duyệt)

Người gửi một kế hoạch để duyệt. Họ chỉnh sửa và gửi, và không duyệt được kế hoạch của chính mình trừ khi họ là quản trị viên agency.

Reviewer (người xem xét)

Người mà người gửi duyệt nêu tên trên một kế hoạch. Cái tên chỉ mang tính chỉ dẫn: nó chọn ai được báo và ai sở hữu công việc duyệt, còn bất kỳ người duyệt nào vẫn quyết định được.

Approver (người duyệt)

Bất kỳ ai giữ quyền “Approve” với khách hàng đó. Người duyệt quyết định các lượt duyệt Thư viện và phê duyệt kế hoạch.

Publisher (người có quyền Publish)

Bất kỳ ai giữ quyền “Publish” với khách hàng đó. Publisher triển khai các kế hoạch đã duyệt, quyết định yêu cầu triển khai và nhờ khách hàng duyệt tài sản Thư viện.

Requester (người đề nghị)

Người đã đề nghị một lần triển khai mà không có quyền Publish. Họ có thể hủy đề nghị của chính mình khi nó còn chờ.

Đưa việc duyệt ra khỏi chat và email trong bốn bước

Mọi người cứ duyệt ngay ở nơi họ vốn đang trò chuyện. Việc áp dụng chỉ thành công khi hộp thư dễ dùng hơn một tin nhắn, nên hãy bắt đầu với một khách hàng và một loại quyết định.

1. 1

   Liệt kê những cái gật đầu bạn đang cho hôm nay

   Trong một tuần, ghi lại mọi lần duyệt diễn ra trong chat hoặc email: một tài sản quảng cáo, một landing page, một chiến dịch, một lần triển khai, một ngày nghỉ. Xếp chúng vào bốn thứ mà hộp thư chứa, và để phần còn lại ở nguyên chỗ cũ.

2. 2

   Nêu tên người duyệt cho từng khách hàng

   Chọn ai duyệt kế hoạch và ai xuất bản cho từng khách hàng, cấp các quyền đó và phân công những người ấy cho khách hàng. Một đồng nghiệp chưa được phân công cho một khách hàng sẽ không thấy công việc của khách hàng đó trong hộp thư.

3. 3

   Chạy thử một khách hàng trong hai tuần

   Nhờ người gửi duyệt nêu tên một người xem xét và ghi lý do vào ghi chú. Khi ai đó xin một cái gật đầu trong chat, trả lời rằng việc đó đang ở trong hộp thư và quyết định ngay ở đó. Công việc duyệt, chuông thông báo và một email đã báo cho người xem xét, nên phần lớn họ biết mà không cần ai nhắc.

4. 4

   Biến hộp thư thành nơi duy nhất để gật đầu

   Sau hai tuần, chuyển khách hàng tiếp theo sang. Nói với đội ngũ rằng một lần triển khai không có kế hoạch đã duyệt thì console vẫn từ chối, và bắt đầu mỗi ngày ở tab “All”, coi một con số lớn hơn không là việc đầu tiên.

“Changed since approval” bảo vệ bạn khỏi điều gì

Cảnh báo này không phải để làm phiền. Nó đánh dấu khoảnh khắc một kế hoạch thôi là kế hoạch mà ai đó đã đồng ý.

Phép so sánh đọc ba thứ: chính kế hoạch, các mẫu email Thư viện mà một kế hoạch email gửi đi, và mọi đối tượng đã lưu đứng sau kế hoạch email, SMS hay paid: định nghĩa của đối tượng và, với danh sách tĩnh, ai nằm trong đó. Chỉnh sửa bất kỳ thứ nào trong số đó đều được tính, kể cả chỉnh một mẫu mà các chiến dịch khác dùng chung. Một phân khúc được định nghĩa bằng quy tắc vẫn có thể khớp những người khác nhau vào ngày gửi mà không khiến bản duyệt thành lỗi thời. Một lần gửi đang chờ mà bị sửa trong lúc chờ thì không duyệt được, và dòng của nó cho biết phải gửi lại.

Có hai giới hạn đáng biết. Nếu một kế hoạch bị sửa sau khi một lần triển khai đã được lên lịch, bộ điều phối so sánh lại ngay trước khi hành động, và lần triển khai khi đó thất bại kèm một lời giải thích rõ ràng, không có gì được gửi đi. Và tài sản Thư viện hoạt động khác: một tài sản mang trạng thái duyệt thay vì dấu vân tay nội dung, nên sửa một tài sản đã duyệt không làm đổi bản duyệt của nó. Mở lại lượt duyệt khi công việc thay đổi.

Mười phút rà hộp thư của một người duyệt

Hộp thư được dựng để dọn từ trên xuống. Thứ tự này đưa lên trước những quyết định đang chặn người khác.

1. 1

   Bắt đầu ở “All”

   Đọc các con số trên tab. Nếu bộ chọn trên thanh tiêu đề đã thu hẹp bộ lọc khách hàng về một tài khoản, mở rộng nó trước, để không có gì nằm chờ sau một bộ lọc mà bạn quên mất.

2. 2

   Xử lý các yêu cầu triển khai trước

   Có người đang chờ để xuất bản. Đọc các bước kiểm tra và dòng hệ quả ngắn, rồi duyệt hoặc từ chối kèm lý do. Một bước kiểm tra không đạt hiện trong hộp thoại và giữ bản duyệt lại.

3. 3

   Rồi đến các kế hoạch

   Mở từng kế hoạch từ dòng của nó. Một dòng bị gắn cờ là đã sửa sau khi gửi thì không duyệt được, nên xin gửi lại thay vì chờ. Yêu cầu chỉnh sửa kèm ghi chú nêu rõ cần đổi gì.

4. 4

   Rồi đến Thư viện

   Mở từng lượt duyệt như khách hàng sẽ thấy. Duyệt, yêu cầu chỉnh sửa, hoặc bỏ qua bước duyệt, thao tác ghi lại rằng không ai đã duyệt tài sản và không hiển thị là đã duyệt. Ghim bình luận vào đúng điểm bạn muốn nói.

5. 5

   Kết thúc bằng nghỉ phép và “Also waiting”

   Quản trị viên quyết định nghỉ phép sau cùng, kèm lý do cho mọi lần từ chối. Nếu thẻ “Also waiting” hiện các mục bảng chấm công hoặc phiên bản kịch bản đặt lịch, mở Chấm công hoặc Kịch bản đặt lịch từ các liên kết của nó.

Ba thói quen giữ lượt rà ngắn gọn: gửi kèm ghi chú, nêu tên người xem xét, và quyết định trong hộp thư thay vì trong chat. Hộp thư đọc lại mỗi khi bạn quay về tab và mỗi phút một lần khi còn mở, nên bạn có thể để nó mở và quay lại với một con số đã cập nhật.

Những gì hộp thư không làm, để không ai tưởng là nó làm

Một hàng chờ quyết định chỉ đáng tin khi ranh giới của nó rõ ràng.

• Hộp thư không gửi nhắc nhở và không leo thang. Một lần gửi kế hoạch rung chuông thông báo và gửi email cho người xem xét, hoặc cho mọi người duyệt của khách hàng khi chưa nêu ai, và tạo một công việc duyệt đến hạn sau ba ngày, nên ngày trên công việc đó trong Dự án chính là lời nhắc. Bản tóm tắt buổi sáng, mặc định gửi vào các ngày trong tuần, cũng liệt kê các lượt duyệt Thư viện, mục chấm công và nghỉ phép đang chờ bạn, nhưng không liệt kê kế hoạch hay yêu cầu triển khai. Một lần gửi Thư viện báo cho người duyệt và không tạo công việc. Một mục cứ chờ cho đến khi có người quyết định.
• Ngoài email, hiện nay nó không đăng hay gửi thay bạn. Một lần triển khai paid, social hay SMS được ghi nhận là làm thủ công: bản duyệt tạo một công việc và một file xuất của thông số đã chốt, rồi có người đánh dấu là đã triển khai, đã đăng hoặc đã gửi. Triển khai email là ngoại lệ, và nó gửi thật.
• Nó không quyết định bảng chấm công hay kịch bản đặt lịch. Chúng được đếm dưới “Also waiting” và quyết định trong công cụ riêng của chúng.
• Nó không hiện kế hoạch, lần triển khai hay hộp thư cho khách hàng. Khách hàng thấy các tài sản Thư viện bạn chia sẻ với họ, trong cổng, và duyệt những tài sản bạn nhờ họ duyệt.
• Nó chỉ cho mỗi người thấy những khách hàng họ xem được. “Approve” và “Decline” chỉ hiện ở nơi họ có quyền, một dòng kế hoạch hay lần triển khai đang chờ mà họ không quyết định được sẽ nói ai quyết định được, và tab “Time off” chỉ hiện với quản trị viên.
• Nó không triển khai lại một kế hoạch đã triển khai xong. Muốn gửi lại, sao chép kế hoạch và duyệt bản sao. Một lần triển khai thất bại, đã hủy hoặc bị từ chối thì thử lại được.

Bản duyệt của chính khách hàng nằm ở đâu

Kế hoạch và lần triển khai là quyết định nội bộ. Bản duyệt của khách hàng áp dụng cho các tài sản Thư viện bạn chia sẻ với họ.

1. 1

   Duyệt nội bộ trước

   Một tài sản chỉ được chia sẻ với khách hàng sau khi một người duyệt của agency đã duyệt hoặc đã bỏ qua bước duyệt. Các tài sản đã chia sẻ từ trước khi có phê duyệt được gắn nhãn là đã chia sẻ và không bao giờ bị chặn.

2. 2

   Chia sẻ, rồi xin khách hàng duyệt

   Người có quyền Publish chia sẻ tài sản và xin khách hàng duyệt, kèm một ghi chú tùy chọn mà khách hàng thấy cùng yêu cầu. Các bình luận đánh dấu là đã chia sẻ khách hàng cũng thấy.

3. 3

   Khách hàng trả lời trong cổng

   Quản trị viên của khách hàng duyệt, và bất kỳ thành viên cổng nào cũng có thể yêu cầu chỉnh sửa. Cả hai diễn ra ngay trên tài sản như khách hàng thấy, với bình luận mà họ có thể ghim vào đúng điểm họ muốn nói.

4. 4

   Hoàn tác, mở lại hoặc xin duyệt lại

   Khách hàng có thể hoàn tác một bản duyệt trong vòng một giờ. Sau một yêu cầu chỉnh sửa, bạn sửa và xin duyệt lại. Bạn có thể rút lại yêu cầu khi nó còn ở phía khách hàng, và mở lại lượt duyệt sau khi nó đã được duyệt hoặc bỏ qua.

Trong hộp thư, các tài sản này nằm dưới “With the client” (đang ở phía khách hàng) trên tab “Library” cho đến khi khách hàng duyệt, rồi chuyển xuống “Decided” (đã quyết định). Nếu khách hàng yêu cầu chỉnh sửa, chúng ở lại dưới “With the client” cho đến khi bạn xin duyệt lại hoặc rút yêu cầu. Việc khách hàng duyệt cần cổng khách hàng, vốn có ở các gói Scale và Enterprise. Hình thiết kế là trường hợp thường gặp, và quản lý tài sản quảng cáo cho thấy phiên bản và lượt duyệt nằm ngay trên tài sản quảng cáo như thế nào.