제품 업데이트 소식, 어디까지 알려야 할까요? 모든 업데이트를 모든 채널로 알리면 고객은 곧 알림을 끄고, 중요한 소식까지 놓치게 됩니다. 업데이트의 무게에 따라 채널과 빈도를 나누는 원칙을 정해 두면 팀의 고민이 줄어듭니다.
업데이트를 세 등급으로 나눈다
먼저 소식의 무게를 가릅니다. 모든 고객의 사용 방식이 바뀌는 변경은 크게, 일부 기능의 개선은 보통으로, 작은 수정은 기록으로만 남기는 식입니다.
공지의 문체도 중요합니다. 개발팀이 쓴 변경 사항 목록을 그대로 옮기면 고객에게는 암호처럼 읽힙니다. 마케팅팀이 한 번 다듬어서 ‘누가, 언제, 무엇을 더 쉽게 하게 되었는지’를 중심으로 다시 쓰는 과정을 업무 흐름에 넣어 두면 공지의 반응이 달라집니다.
- 큰 변화: 이메일, 서비스 안 공지, 블로그를 모두 사용
- 보통 변화: 서비스 안 공지와 변경 내역 페이지
- 작은 변화: 변경 내역 페이지에만 기록
채널마다 맡은 역할이 다르다
이메일은 놓치면 안 되는 소식을, 서비스 안 메시지는 지금 쓰고 있는 기능과 관련된 소식을, 블로그는 맥락과 배경이 필요한 이야기를 담당합니다. 같은 문구를 복사해 세 곳에 붙이지 말고, 각 채널에서 읽는 사람의 상황에 맞게 다시 써 주세요.
서비스 안에서 보여 주는 메시지는 타이밍이 생명입니다. 새 기능이 해당 화면에서 처음 쓰일 때 짧은 안내를 띄우면 별도의 이메일 없이도 이해됩니다. 닫기 버튼을 분명히 두고 한 번 닫으면 다시 나타나지 않게 하는 것도 잊지 마세요.
모든 것을 알리는 팀은 결국 아무것도 알리지 못한다.
스토리 라이트 편집팀
‘무엇이 달라지는가’보다 ‘나에게 무엇이 좋은가’
기능 이름과 기술 용어로 시작하는 공지는 읽히지 않습니다. 고객이 이전에 겪던 불편과 이번 변화로 달라지는 한 문장의 변화를 제목에 담아 보세요.
업데이트 이후에는 반응도 살펴보세요. 공지의 열람률뿐 아니라 새 기능의 실제 사용률이 어떻게 달라졌는지를 보면 어떤 방식의 안내가 효과적이었는지 알 수 있습니다. 이 기록이 쌓이면 다음 공지의 채널과 문구를 정하는 근거가 됩니다.
정리
변경 내역 페이지를 하나 만들어 두면 작은 업데이트에 대한 부담이 줄고 고객도 필요할 때 찾아볼 수 있습니다. 공지 전에 ‘이 소식을 받는 사람이 무엇을 하면 좋은가’를 한 줄로 적어 보는 습관을 권합니다.




이 글에 첫 댓글을 남겨보세요