Written by Kenn, Founder & CEO of NextLevel Growth
This case study documents an active internal system. It focuses on the operational problem, the design decisions, and the lessons learned—not inflated growth claims.
The operational problem
A growing Discord server can quickly become difficult to manage when approvals, applicants, staff duties, announcements, and private records are handled through scattered messages. The goal was to create a single operational layer for the NextLevel team while preserving Discord as the community interface.
What the system includes
The Node.js and Discord.js bot separates Owner and Admin controls. The Owner can review access requests, manage admins, send announcements, inspect attendance, and oversee records. Admins receive their own authenticated control area with only the actions needed for their role. Applicant stages move from initial application through interview, assessment, contract, and onboarding.
Access screening design
New members receive a Pending Approval role and a private screening conversation. The system records the requested access type and can collect a LinkedIn profile, referral source, and introduction. The Owner retains the final decision. A key lesson was that a form must support the decision, not prevent it: the Owner also needs a manual approval path when a legitimate member has not completed every field.
Permission maintenance
Discord permissions are powerful but easy to overcomplicate. Early maintenance routines could recreate member-specific overwrites or make approval slow when many channels were processed one at a time. The improved approach treats role-based access as the main control, preserves intentional manual denials, repairs missing screening records, retires duplicate records, and moves heavy cleanup away from the approval interaction.
Duty tracking
Staff duty is measured by active participation rather than a simple login timestamp. The system supports time-in, pause and resume behavior around voice activity, a daily requirement, owner visibility, and reminders. The practical lesson is that attendance logic needs recovery after restarts and must not reset legitimate progress when a user briefly disconnects.
What we would do earlier next time
We would define the record lifecycle before adding interface buttons: one active screening per user, explicit final statuses, idempotent maintenance, and a timeout for every external operation. We would also test with a normal member account in a staging server before applying permission changes across production channels.
Current status and limits
The system is actively maintained and continues to evolve. This page does not claim that automation replaces human review. The Owner remains accountable for access decisions, and staff still need written procedures for unusual cases. The strongest result so far is operational clarity: each major action has a place, a responsible role, and a recoverable record.
About this resource: NextLevel publishes practical material drawn from active systems, client work, and documented project experience. Read our editorial standards and author profile.