문의 채널은 있는데 정작 유저가 어디를 눌러야 할지 몰라 첫 질문도 못 남긴다면, 티켓 봇이 있어도 절반은 실패입니다.이 단계에서 중요한 건 카테고리보다 첫 클릭입니다.이 글은 문의를 어떻게 처리할지보다, 유저가 어떤 문구를 보고 어느 버튼을 눌러야 하는지를 설계하는 입구 분기 글입니다.1. 유저는 분류 체계보다 '내 상황과 비슷한 버튼'을 찾는다초반 서버에서 버그문의, 결제문의, 파트너문의, 일반문의를 전부 따로 열면 오히려 더 어렵습니다.처음 들어온 사람은 자기 문의가 어디에 해당하는지 바로 판단하지 못하는 경우가 많습니다.그래서 처음에는 문의-안내 채널 하나에서 시작하고, 버튼이나 짧은 설명으로 분기시켜야 합니다.티켓 생성 구조는 티켓 디스코드 봇 만들기, 카테고리 구조는 디스코드 티켓 카테고리 설..

티켓 채널은 잘 열리는데 운영이 오히려 더 지저분해졌다면, 문제는 봇이 아니라 백오피스 정보구조입니다.문의, 신고, 결제, 제휴가 한 카테고리에 다 몰리면 티켓 자동화는 사실상 아무 것도 해결하지 못합니다.이 글은 티켓 채널을 여는 글이 아니라, 열린 티켓을 어떤 카테고리와 권한 체계 아래에 배치할지 설계하는 글입니다.1. 티켓이 열리는 것과 티켓이 정리되는 것은 다른 일이다초반에는 티켓 카테고리 하나로도 충분합니다.다만 아래 상황이 보이면 분리 시점을 검토해야 합니다.운영 문의와 신고 문의가 자주 섞인다담당 역할이 서로 다르다처리 우선순위가 다르다기록 보존 기간이 다르다한 카테고리 안에 모든 문의를 넣으면 결국 운영진이 제목만 보고 내용을 추측하게 됩니다.2. 초반 서버에서 무난한 구조작은 서버라면 아..

이벤트 채널은 사람을 모으기 위한 장식이 아니라 서버 활동 리듬을 만드는 도구입니다.그냥 채널 하나를 만들고 공지만 올리면 반응이 생각보다 약합니다.이벤트가 읽히고 참여까지 이어지려면 채널 구조와 공지 방식이 같이 맞아야 합니다.이벤트 운영은 아이디어보다 동선 설계에서 더 자주 갈립니다.1. 이벤트 채널을 따로 두는 기준서버가 아주 작다면 공지 채널 하나로도 버틸 수 있습니다.다만 아래 상황이 보이면 이벤트 채널을 분리해야 합니다.이벤트 공지가 일반 공지에 자주 섞인다참여 방법 설명이 길다모집, 결과 발표, 후기까지 남겨야 한다월 2회 이상 반복 이벤트를 연다이벤트 공지가 늘어났는데도 공지 채널 하나만 쓰면 중요한 운영 공지가 묻히기 쉽습니다.2. 기본 구조는 세 칸이면 충분하다처음부터 채널을 너무 많이..

디스코드 서버는 만든 뒤가 더 중요합니다.채널과 규칙을 잘 깔아 두어도 처음 들어온 사람이 바로 나가면 홍보가 거의 의미가 없습니다.서버 홍보는 링크를 많이 뿌리는 작업이 아니라, 들어온 사람이 왜 남아야 하는지 먼저 정리하는 작업에 가깝습니다.유입은 홍보글에서 시작되지만 잔류는 서버 구조에서 결정되는 경우가 많습니다.1. 홍보 전에 먼저 점검할 것홍보부터 시작하면 초반 유입이 그대로 이탈로 바뀌기 쉽습니다.아래 네 가지는 최소한 맞춰 둔 뒤 링크를 열어야 합니다.서버 소개문이 한눈에 이해되는가규칙 채널과 공지 채널이 위쪽에서 바로 보이는가처음 들어온 사람이 질문할 채널이 보이는가초대 링크가 만료되지 않도록 설정했는가소개문 문구가 아직 애매하다면 디스코드 서버 소개문 작성법부터 먼저 손보면 됩니다.입구 ..

서버 소개문은 짧지만 생각보다 중요합니다.새 유저는 서버 이름, 아이콘, 공지보다도 소개 문구 몇 줄로 분위기와 목적을 먼저 판단하는 경우가 많습니다.특히 공개 커뮤니티 서버라면 소개문 하나로 유입 품질이 달라질 수 있습니다.소개문 몇 줄이 유입 품질을 바꾸는 경우를 실제로 자주 봅니다.1. 소개문은 운영자 소개가 아니다서버 소개문은 운영팀 자랑이 아니라 서버 용도를 설명하는 문장입니다.누구를 위한 서버인지, 들어오면 무엇을 할 수 있는지, 어디부터 보면 되는지가 먼저 보여야 합니다.자기소개보다 유저 입장에서 필요한 정보를 앞에 둬야 합니다.2. 아래 세 가지가 들어가면 기본은 된다이 서버가 무엇을 다루는가어떤 사람이 들어오면 맞는가처음 들어오면 어디를 보면 되는가이 세 가지가 있으면 소개문 길이가 길지..

서버를 어느 정도 꾸며 놓고 나면 그다음은 보안입니다.역할 구조가 애매하거나 @everyone 권한이 넓으면 스팸, 광고, 채널 오염이 금방 들어옵니다.초반 서버일수록 큰 사고 한 번으로 운영 의욕이 꺾이는 경우가 많습니다.보안 점검은 사고가 난 뒤보다 채널 구조를 다듬는 시점에 같이 해 둬야 합니다.1. @everyone 권한부터 줄인다가장 먼저 볼 항목입니다.초반 서버에서 @everyone에 너무 많은 권한이 열려 있는 경우가 많습니다.보통은 아래 정도부터 제한하는 쪽이 안전합니다.Manage ChannelsManage RolesMention @everyone, @here, and All RolesCreate Instant InviteManage Webhooks기본 역할은 최대한 좁게 두고 필요한 역..