Always Be Closing

Always Be Closing

Unity
Unity
C#
C#
Figma
Figma
HTML/CSS/JS
HTML/CSS/JS
Published Jun 2025|
Simulation

A software simulation designed for Stanford University to train salespeople to be more effective in sales calls. Used to teach STRAMGT351, a sales management course.

GitHub
Monitor content
Monitor frame

Always Be Closing is a customer management software simulation that supplements STRAMGT351, a sales course at Stanford. The application gives hundreds of students a simulated environment to practice sales calls and close deals before they step into the real world.

STRAMGT 351: Building & Managing Sales Organizations — course listing

STRAMGT 351: Building & Managing Sales Organizations

Product and audience

The simulation guides the player through a sales representative's journey of converting leads into opportunities, and opportunities into customers. The course comprises students across multiple years, but primarily focuses on graduate students in the Graduate School of Business.

The game replaced an activity offered in previous years of the course that initially focused on managing numbers in a sales spreadsheet. Many of the early design and tech choices were guided by the need to define a balance of fun and learning.

Always Be Closing — simulation interface preview

Always Be Closing interface

Built for scale: Firebase, AWS, Airtable, and Claude

With 20,000+ monthly requests, reliability and performance were important. I designed and optimized the backend around Firebase for real-time and auth, AWS for hosting and assets, and Airtable as a database and interface for the professor to use to create and assign sessions. The application also contains a virtual boss who answers questions about the player's sales pipeline; the Claude API allows the simulation to respond intelligently to student choices for more guided learning opportunities.

Airtable view used to manage Always Be Closing player performance data

Airtable interface for tracking game sessions and player performance in testing environment

Design process: 20+ playtesting sessions

The design process was driven by frequent, structured playtesting. I helped run and analyze 20+ playtesting sessions with students, teaching assistants, and instructors to test fun, difficulty curves, and UI clarity. All feedback went straight into sprint planning and shaped everything from onboarding (via an interactive tutorial) to the way sales scenarios were presented (in modals rather than banner notifications).

The application was built in Unity and deployed for Mac and Windows. The builds were versioned and used throughout iterative testing.

Build folder showing versioned Always Be Closing releases

Versioned builds used throughout iterative testing