Leads

This is a CRM segregated by programs. Tabs exist for pages: School Leads, Tennis Leads, S&C Leads, and Upcoming.

Different groups have different pipeline stages, but these are hard-coded. Admins cannot add their own pipeline stage ^hptjs.

The leads page can be viewed by alphabetical list of leads or by a kanban style view of pipeline stages. Clicking a lead opens a model to edit fields, assign to a user, or move them into an alternative pipeline (change from Academics to Tennis, for example).

Users can search by parent name, child name, phone number, or email address.

Both views have toggle buttons for the lead’s category (Adults, Juniors, Academy, Other), and the list view has toggle buttons for each pipeline stage.

Leads' children are text fields. Prospective students do not exist inside of the data model as a "person". Users are currently inputting multiple children into the same field.

There is no logging of conversations, no SMTP email integration, etc, making hand-offs difficult. Currently, users email candidates outside the app via gmail, and while there is a "notes" section, it is universal and not tied to conversation ^5ryrs.

Within the leads section, a “recipients” tab shows a list of employees within the current department (academics, tennis, etc.), with check boxes to select if that employee receives and email/push notification when a new lead is created for that department.

Recipients

A tab for upcoming students shows which students have been accepted into school for the upcoming year. This only shows incoming students converted from "School Leads." Tennis and S&C leads are not tracked this wa ^oezxy.

This page uses a cards view that may not be the best way to represent this information. List view seems superio ^4xqyr.

This content is identical to the "Upcoming" tab in the "Full Time Academy" SIS. This view should not be duplicated in two location ^dg1ps.

How are upcoming students converted into enrolled students? Does that happen as a scheduled task, or is it a manual process? In the data model, Student should be an entity, with "upcoming" a possible enrollment statu ^wwa1s.