# RE Onboarding 

```

## Change Log

### 1.1 Change Log – Version 2.0

**Module:** Dealer Onboarding & Offboarding System
**Change Type:** Clarifications, Role Alignment & Access Control Enhancements
**Scope Enhancement :** Dealer Role and Access control
**Change demarcation** : Highlighted in Yellow
**Changes suggested by** : Ashok & Tariq
**Changed performed by** : Rohit Mandiwal
**Changes done on** : 31 - Dec- 2025

**1.1.1 Notification Channel Enhancement**

- Added **WhatsApp as a supported notification channel** for reminders and workflow
    communications (e.g., questionnaire completion and status updates), while restricting
    sensitive document sharing to email only.

**1.1.2 LOI Governance & Communication Clarifications**

- Clarified that the **Finance team is not the decision-making authority** for LOI issuance
    and is responsible only for financial validation.
- Confirmed that **LOI documents are shared exclusively via official email** and not through
    WhatsApp.
- Clarified that **LOA issuance is a parallel statutory activity** and is **not dependent on**
    **infrastructure readiness**.

**1.1.3 Dealer Code Creation Control**

- Clarified that **Dealer Codes (SAP Master) are created only upon explicit trigger by the**
    **DD Admin** , and not through automatic system generation.

**1.1.4 LOA & EOR Sequencing Correction**

- Corrected the workflow sequence to ensure that **LOA is issued prior to initiating the**
    **EOR checklist** , with EOR serving as the final readiness validation before go-live.



**1.1.7 Role & Persona Alignment**

- Added **NBH** to the personas section.
- Added **RBM** to applicable review and approval tables.
- Clarified that **DD ASM is responsible for interview scheduling and coordination** , with
    no Admin involvement.

**1.1.8 Access Control & Visibility Refinements**

- Defined **view-only access** for DD ASM, DD ZM, and RBM at relevant workflow stages.
- Granted **approval visibility** to DD Lead where applicable.
- Enabled **DD ASM and DD ZM** to upload site readiness and LOA-related documents,
    with **DD Lead, RBM, and ZBH** having view access.
- Limited applicant and dealer portal access to **stage-specific and context-specific**
    **scenarios only**.
- Confirmed that **dealer portal access is revoked after resignation or termination**.

**1.1.9 Terminology & Documentation Corrections**

- Clarified **KT Matrix as Kepner Tregoe Matrix** for consistency and correctness.

**1.1.10 Super Admin Role Introduction**

- Introduced a **Super Admin (Master Role)** with end-to-end access and workflow control
    across modules.
- Defined segregation of duties by splitting Super Admin into **two DD Admin roles** with
    clearly scoped responsibilities.





## 1 System Overview & Problem Statement

**1.1.1 System Overview**

The **Dealer Onboarding and Offboarding System** for **Royal Enfield (RE)** is designed to **digitize,
standardize, and streamline** the complete dealer lifecycle — from **application and
evaluation** to **approval, resignation, termination, and full-and-final (F&F) settlement**.

At present, the process operates through **manual coordination** , involving **emails, spreadsheets,
and physical documentation** , which makes it difficult to maintain visibility, accountability, and
consistency across teams.

The proposed solution introduces a **centralized digital platform** that brings all stakeholders onto
a single workflow. It ensures that every stage — **onboarding, operational approvals, financial
diligence, legal validation, and final closure** — follows a **structured and traceable process**.

The system integrates seamlessly with existing RE applications such as **SSO** , **SAP** , and **Finance
modules** , providing **role-based access** , **real-time tracking** , and **secure document management**.
It also offers **automated workflows** , **configurable approval hierarchies** , and **AI-assisted decision
support** to improve efficiency and reduce turnaround time.

By moving to a digital workflow, Royal Enfield will achieve higher levels of **process
efficiency** , **data accuracy** , and **transparency** , ensuring faster decision-making and stronger
control over the dealer network lifecycle.

## 2 Intended Audience

This document is intended for all stakeholders involved in the **design, implementation, approval,
and operational use** of the **Dealer Onboarding and Offboarding System** at **Royal Enfield (RE)**.

The following user personas and roles are part of the system:

### 2.1 Business & Functional Users

**2.1.1 Dealer Development (DD) Team**

- **Super Admin (Master Role):**
    The **Super Admin has unrestricted access** across all modules and workflows, with
    authority to **configure, override, and influence workflow behavior** at every level.


```
The Super Admin role is segregated into two DD Admin roles , each with clearly defined
scopes to ensure segregation of duties and governance control.
```
- **DD-Admin:** System administrator responsible for user setup, role mapping, hierarchy
    configuration, and workflow management.
- **DD-AM (Area Manager):** Reviews and manages applications within assigned regions;
    performs preliminary screening.
- **DD-ZM (Zonal Manager):** Conducts the first level of dealer evaluation along with RBM;
    prepares presentation decks for final interviews.
- **DD-Lead:** Reviews zonal evaluations, validates recommendations, and forwards
    shortlisted applicants for senior-level approval.
- **DD-Head: DD Head** is engaged in the **final review and approval** of shortlisted dealer
    applications before the **NBH interview** , and later **oversees final verification and LOI**
    **issuance** after all evaluations are complete.

**2.1.2 Regional Sales & Business Team**

- **RBM (Regional Business Manager):** Participates in early-stage evaluations, provides
    ground-level business insights, and recommends suitable candidates.
- **ZBH (Zonal Business Head):** Conducts the second-level review along with DD-Lead;
    provides strategic feedback on market and location viability.
- **NBH (National Business Head):** Holds final authority for approval or rejection of dealer
    onboarding; reviews consolidated feedback from all levels.

**2.1.3 Supporting Departments**

- **Finance Team:** Reviews financial due diligence reports, validates F&F (Full and Final)
    settlements, and manages monetary closure during offboarding.
- **Legal Team:** Reviews agreements, issues **Letters of Intent (LOI)** or **Termination Letters** ,
    and ensures all documentation aligns with company policy.
- **Brand Experience / Architecture Team:** Manages **EOR (Essential Operating**
    **Requirements)** and ensures adherence to brand and infrastructure standards.

**2.1.4 Dealers**

Once a dealer is **successfully onboarded and activated in the system** , the Dealer role is enabled
with controlled, role-based access to initiate and track select lifecycle requests. This
enhancement introduces **structured self-service capabilities for dealers** , while ensuring all
actions remain governed by defined validations, internal reviews, and approval workflows as per
RE standards.

The Dealer role is enabled to perform the following activities:

```


### 2.2 External & Integrated Stakeholders

**2.2.1 FDD (Financial Due Diligence Partner)**

External agency responsible for assessing the applicant’s financial health, verifying credentials,
and uploading due diligence reports into the system.


**2.2.2 Dealer / Applicant**
External user who applies for dealership, uploads required documents, participates in
interviews, and later accesses the portal for resignation or closure status.

## 3 Definitions and Acronyms

```
Acronym Full Form / Description
RE Royal Enfield
DD Dealer Development
DD-AM Dealer Development – Area Manager
DD-ZM Dealer Development – Zonal Manager
DD-Lead Dealer Development – Lead
DD-Head Dealer Development – Head
RBM Regional Business Manager
ZBH Zonal Business Head
NBH National Business Head
ASM Area Sales Manager
FDD Financial Due Diligence (External Partner/Agency)
LOI Letter of Intent
EOR Essential Operating Requirements
LOA Letter of Appointment
F&F Full and Final (Dealer Settlement)
KT Matrix Evaluation Matrix used for scoring applicants
```
## 4 HiFi Wireframes & Flow of Application

HiFi Wireframes : https://mono-human-93592950.figma.site

### 4.1 Dealer onboarding - Process Flow Overview

The **Dealer Onboarding Workflow** outlines the end-to-end sequence through which a dealership
application progresses — from initial registration to final inauguration and operational readiness.


**4.1.1 Step-by-Step Process Flow**

```
4.1.1.1 Application Initiation
```
- The **applicant (dealer prospect)** submits an online application through the Dealer
    Onboarding Portal.
- The system checks the **location’s availability** in the Royal Enfield dealership network:
    o If the location has **no open opportunity** , a **Non-Opportunity Email** is triggered
       automatically.
    o If an opportunity exists, the applicant receives an **Opportunity Email** with login
       credentials and a link to the **Dealer Questionnaire**.

```
4.1.1.2 Questionnaire Completion
```
- The applicant fills out the **comprehensive questionnaire** covering business, infrastructure,
    and financial readiness.
- The system auto-scores responses, generating a **Questionnaire Score** and **initial**
    **ranking** for that applicant.


- Completed applications move to the **Admin review bucket**.
- The system shall trigger automated reminders to users for completing the
    questionnaire. These **reminders will be sent through WhatsApp** , to ensure timely
    submission. Reminder needs to be configured from Admin.

```
4.1.1.3 Admin Validation & Shortlisting
```
- **DD-Admin** reviews all submitted applications and validates details and attached
    documents.
- Based on eligibility, applications are either **shortlisted** for evaluation or **archived** for
    future opportunities.
- Shortlisted applications are distributed to respective **zones or regions** for further
    assessment.

```
4.1.1.4 Interview Evaluation (Multi-Level Process)
```
- Admin schedules interviews in **Level 1** , **Level 2** , and **Level 3** , as applicable.
- Each interview can be **Virtual or Physical** , with calendar invites sent via Google Calendar.
- Evaluators at each level (DD-ZM, RBM, DD-Lead, ZBH, NBH, DD-Head) record their
    feedback through:
       o **KT Matrix Scoring** (quantitative)
       o **Interview Feedback Form** (qualitative)
- The system consolidates panel feedback and generates an **AI-driven summary and**
    **ranking** for decision support.

```
4.1.1.5 Financial Due Diligence (FDD) & Finance Review
```
- Upon shortlisting, the application is assigned to the **FDD Team (external agency)** for
    financial validation.
- FDD users, using SSO credentials, can:
    o View assigned applications in a restricted interface.
    o Upload FDD reports and add remarks in the **Work Notes** section.
    o Flag cases of **non-responsiveness** or incomplete data, returning them to Admin.
- The **Finance team** reviews submitted FDD reports, validates findings, and decides
    whether the application proceeds to **LOI approval**. The finance team is not the decision
    maker for LOI Issuance.

```
4.1.1.6 LOI (Letter of Intent) Approval & Issuance
```
- Based on Finance clearance, **DD-Head and NBH** review and approve the **LOI request**.
- The system tracks document approvals, timestamps, and supporting artefacts.


- Once approved, the LOI document is generated, uploaded, and shared **with the**
    **applicant via official email communication** and not on WhatsApp
- Notification emails are triggered to all relevant stakeholders.

```
4.1.1.7 Dealer Code Generation & Setup
```
- After LOI issuance, the **DD-Admin triggers** the Dealer Code creation process. Based on
    this trigger, the **Dealer Code is created in the SAP Master** and **mapped to the applicant**
    within the system.
- The code links all downstream modules, including Architectural, Statutory, and EOR
    checklists.

```
4.1.1.8 Architectural Work & Statutory Documentation
```
- Architectural activities are initiated (site plans, layout approvals, branding elements).
- The applicant and assigned Architecture Team upload documents, drawings, and
    blueprints.
- In parallel, the applicant uploads **Statutory Documents** such as:
    o GST certificate, PAN, Partnership Deed, Firm Registration, Rental/Lease
       Agreement, etc.
- Each upload is timestamped and visible with file name, uploader, and document type.

```
4.1.1.9 Payment Verification & Finance Validation
```
- Applicant uploads proof of advance payment or security deposit.
- The **Finance team** verifies payment details (transaction ID, amount, and bank record).
- Status is updated to **Verified** once the payment is reconciled.
- Verified payment triggers readiness for final operational setup.

```
4.1.1.10 Essential Operating Requirements (EOR) Checklist
```
- All functional teams (Sales, Service, IT, Finance, Training, Architecture) verify their
    respective readiness parameters.
- Progress is tracked through a **completion bar** until 100% EOR compliance is achieved.
- The **EOR checklist is initiated only after LOA issuance**. All functional teams verify their
    respective readiness parameters, and progress is tracked until **100% EOR compliance** is
    achieved.

```
4.1.1.11 LOA (Letter of Agreement) & Final Go-Live
```
- After LOI issuance and Dealer Code generation, the **Letter of Agreement (LOA) is**
    **generated and approved by NBH and DD-Head**. Upon successful LOA issuance, the


```
application proceeds to the Essential Operating Requirements (EOR) checklist for final
readiness verification.
```
- Final verification includes:

```
o EOR document review
o Brand readiness assessment
o Site validation and inspection
```
- The **LOA** officially authorizes the dealership to operate under Royal Enfield.

```
4.1.1.12 Inauguration & Closure
```
- Post-authorization, the **Inauguration** event is scheduled and logged.
- Completion of inauguration marks the dealership as **Active** in the system.

```
4.1.1.13 System-Driven Governance & Audit
```
- Each stage automatically logs:
    o User action, timestamp, and remarks
    o Uploaded artefacts and version control
    o Notifications sent and approvals received
- The entire lifecycle remains accessible under **Audit Trail** for future reference, compliance,
    or offboarding workflows.




**4.5.2 Step-by-Step Process Flow**

```
4.5.2.1 Security Deposit Validation (Onboarding Stage)
```
- **Trigger:**
    Initiated when a new dealer’s onboarding application reaches the Finance stage after
    DD approval.
- **Action:**
    The **Finance Team** verifies the **Security Deposit** payment made by the dealer
    via **RTGS/NEFT** or other approved channels.
- **Outcome:**
    o Verified deposits are marked as _Approved_ , triggering system notifications to DD-
       Admin and DD-Lead.



4.5.2.5 Payment Processing & Record Update
```
- **Action:**
    Finance executes the financial transaction (payment to or recovery from dealer).
- **System Steps:**
    o Enters **Mode of Payment** , **Transaction Reference Number** , **Date** , and **Remarks**.
    o Uploads proof of payment (RTGS confirmation or bank statement).
    o Marks case as _Finance Approved_ and sends completion notification to DD-Admin
       and Legal.
    o System automatically updates the **Progress Timeline** and **Audit Trail**.

```

## 5 System Features & Requirements

Here, we describe the **system features** along with their respective **Width** and **Depth** to provide
complete visibility of each requirement.

The **Width** defines the **functional coverage** of a feature — outlining what the feature does,
its **boundaries, use cases, and user interactions**. It answers the question: _“What scenarios and
actions are covered by this feature?”_

The **Depth** captures the **operational and behavioral details** — describing how the feature
behaves through its **logic, workflow, system responses, and edge-case handling**. It answers the
question: _“How does the system execute and respond in these scenarios?”_

---

## 6 Dealer onboarding

### 6.1 Dealership Application Form

**6.1.1 Functionality Scope**

The **Dealer Application Form** is the entry point for individuals or businesses applying to become
an authorized **Royal Enfield dealer**. This form captures all essential applicant details to initiate
the onboarding workflow. It ensures structured data collection, validation, and consent before
the request enters the evaluation process.


**6.1.2 Width**

- Accessible from the **Royal Enfield official website** and internal campaigns (QR-based or
    direct link).
- Available as part of the **Dealer Onboarding module** under the section _“Apply for_
    _Dealership.”_
- On successful submission, the application is routed to the **DD-Admin** and **respective**
    **zonal evaluation team** for screening.

**6.1.3 Depth**

- The form captures applicant identity, contact, business, and location information through
    mandatory fields such as:
       o **Full Name** , **Mobile Number** , **Email Address** , **Age**
       o **Country** , **State** , **District** , **Pincode**
       o **Interested City for Dealership** , **Company Name** , **Education Qualification**
       o **How did you hear about us?**
       o Ownership details — _“Do you own a Royal Enfield?”_ and _“Are you an existing_
          _dealer/vendor?”_
       o **Address** and **Description** fields capturing business background, experience, and
          dealership intent
- The form enforces **mandatory validations** (e.g., email format, mobile number pattern,
    field completeness) before submission.
- Applicants must acknowledge the **Terms and Conditions** via a mandatory consent
    checkbox, ensuring compliance with RE’s data privacy policy.
- Upon clicking **Submit Application** , data is securely stored in the system database and
    auto-routed to the assigned **region/zone hierarchy**.
- The system sends an acknowledgment **notification to the applicant via email and**
    **registered mobile number**. Mobile-based notifications will be delivered through
    WhatsApp.
- **Form will be having a disclaimer:** A consent checkbox is mandatory in the
    application form. The applicant must acknowledge this disclaimer before
    submission: _“By submitting this form, you agree to our privacy policy and terms of_
    _service. We will use your information to process your dealership application.”_

**6.1.4 Personas-Wise Accessibility & Visibility**

```
Persona Accessibility Visibility Scope
Applicant / Dealer
Prospect
```
```
Can view and fill the form; required to submit
all mandatory details
```
```
Full visibility for own
submission
```



### 6.3 Dashboard

The **Dashboard** is an open element that is **currently under discussion** and will be finalized in later
phases. It is expected to serve as a central view for users to monitor workflow status, pending
approvals, and key metrics once its structure and content are defined.

### 6.4 Opportunity & Non Opportunity

**6.4.1 Functionality Scope**

The **Opportunity & Non-Opportunity Management** module classifies all dealer applications
received through the **Dealer Application Form** into two distinct categories as
**Opportunity** and **Non-Opportunity**. This classification is determined automatically based on the
applicant’s **preferred dealership location** and the **current availability** of opportunities defined
in the system. In certain cases, an applicant may express interest in a specific location (e.g.,
Chennai) where an opportunity is not currently open. Such applications will remain on hold and
can be reactivated or re-sent once the opportunity for that location becomes available. The


system shall allow the applicant to reinitiate the opportunity request without re-entering all
previous details. The module ensures that every application is properly acknowledged and
routed for further processing or stored for future reference, maintaining transparency and
traceability in applicant communication.

**6.4.2 Width**

2.1 The module appears under the **Dealer Onboarding** workspace with two key views:

- **Opportunity Requests** – Displays all applications where dealership opportunities are
    currently open in the requested region.
- **Non-Opportunity Requests** – Captures applications for regions where dealership
    opportunities are not available at the time of submission.

2.2 Both views can be accessed by **DD-Admin, DD-Lead, and DD-ZM** users based on their defined
RBAC access levels.

2.3 Each application record displays critical information such as **Registration Number, Name,
Preferred Location, Status, Applicant Location, Progress, and Application Date**.

**6.4.3 Depth**

3.1 When a dealer submits an application, the system checks the **preferred city and
region** against the **Opportunity Town Master** configured by the admin.

3.2 Based on this validation, the following actions occur automatically:

1. If an **opportunity exists** , the applicant receives an **Opportunity Email** , confirming that
    their location is currently under consideration.
2. If **no opportunity exists** , a **Non-Opportunity Email** is triggered, informing the applicant
    that the region is closed for dealership openings but that their information will be
    retained for future reference so in case any opportunity pops up later, he can be
    contacted.
    3.3 All submitted applications initially land with the **Admin** , who performs a preliminary
    validation and shortlist them into appropriate zonal or regional queues.
    3.5 Both Opportunity and Non-Opportunity records are time-stamped and retained for
    audit visibility and future lead generation reference.


**6.4.4 Flow**

```
Step Source → Destination Description / Action
```
```
1
```
```
Dealer Applicant → Application
Form
```
```
Applicant submits dealership request with preferred
city.
```
```
2 System → Opportunity Validation Engine System verifies if the preferred city exists in the Opportunity Master.
```
```
3 Validation Engine → Applicant Sends Opportunity or Non-Opportunity Email based on
result.
```
```
4 System → DD-Admin
```
```
All applications (both categories) are routed to Admin
for validation.
```
```
5 DD(respective Zone)-Admin → DD - ZM / DD-Lead^ Admin distributes qualified opportunities to respective zones for next-level evaluation.
```
**6.4.5 Personas-Wise Accessibility & Visibility**

```
Persona Accessibility Visibility Scope
Applicant Receives automated acknowledgment and opportunity
status email
```
```
None beyond
email notification
DD-Admin Full access to both Opportunity and Non-Opportunity
queues; performs initial validation and assignment
```
```
Complete
visibility
DD-ZM / DD-
Lead / RBM
```
```
View and act on assigned Opportunity Requests only Restricted to
assigned zone or
region
System
(Automation
Layer)
```
```
Performs validation and triggers automated
notifications.
The system triggers automated notifications across
configured channels, including email and WhatsApp ,
based on workflow events and application status
changes.
```
```
Background
execution only
```

### 6.5 Questionnaire Response

The **Questionnaire Response & Scoring** module captures, displays, and evaluates responses
submitted by dealer applicants during the onboarding process. It enables Admin to view all
applicant answers in a structured format with predefined scoring and section-wise weightage.
The objective is to ensure that each applicant is evaluated objectively and consistently based on
parameters such as personal background, financial capacity, and business readiness. The overall
questionnaire score directly contributes to the applicant’s ranking within the region or city for
fair selection and further shortlisting. Questions are to be managed from Admin with versions.

**6.5.1 Width**

- Accessible under **Application Details → Questionnaire Response tab**.
- Displays categorized sections such as:
    o Personal Information
    o Financial Information
    o Business Information (if applicable)
- Each response card shows the **question, applicant’s answer, and the score obtained** out
    of the assigned weightage (e.g., 5/5, 8/10).
- The top-right corner displays the **aggregate questionnaire score** , expressed as a numeric
    total (e.g., _78/100_ ).

**6.5.2 Depth**

- The questionnaire is to be created by Admin which will be common for all. There will be
    versioning of it in case the questions are added or changed over time.


- Each question carries a **predefined weightage** configured by the Admin under the
    Questionnaire Master.
- The system automatically calculates the total score once the applicant submits the
    questionnaire.
- Evaluation parameters include as example:
- https://docs.google.com/forms/d/1YfTGFNx4zrul0YkJmCp7P0jyJKTiPRMxFvgZE8pmO9g/
    edit
-
    o **Personal Details:** State, Age, Qualification, and Business Experience
    o **Financial Details:** Net worth, investment capacity, and funding sources
    o **Business Readiness:** Infrastructure preparedness, local market knowledge, and
       management strength
- The cumulative score determines the **applicant’s rank** relative to others in the same
    location.
- All responses and scores are stored ensuring transparency and audit traceability.
- Any updates to the scoring model or questionnaire format are logged and version-tagged
    for future reference.

**6.5.3 Personas-Wise Accessibility & Visibility**

```
Persona Accessibility Visibility Scope
Applicant Can fill and submit questionnaire during
onboarding.
```
```
Own submission only.
```
```
DD-Admin Can view all applicant responses and manage
questionnaire versions.
```
```
Full visibility.
```
```
DD-ZM / DD-Lead /
RBM
```
```
Can view applicant responses and scores for
evaluation or ranking purposes.
```
```
Restricted to
assigned regions.
System
(Automation Layer)
```
```
Performs automatic scoring, rank generation,
and data versioning.
```
```
Background
execution.
```

### 6.6 Shortlisting Process

**6.6.1 Functionality Scope**

This functionality allows the **DD-Admin** to review all dealer applications received through the
questionnaire responses and shortlist the qualified ones for further evaluation. Admin can view applicant
details, compare preferred and available locations, and assign shortlisted applications to the
respective **DD-ZM** and **RBM** for next-level processing. Each shortlisted record can include remarks
capturing the rationale for selection or any special observation. Once assigned, the shortlisted
applications move to the **Dealership Requests** page for regional evaluation and workflow initiation.

**6.6.2 Width**

- Display of all received applications in a tabular view.
- Search and filter for quick reference.
- Ability to select multiple applications for shortlisting.
- Option to assign shortlisted applications to **DD-ZM** and **RBM** users via email ID.
- Field to capture optional remarks during shortlisting.
- Confirmation dialog before final submission.
- Status transition of applications from _“Submitted”_ to _“Shortlisted”_.
- Automated notification and dashboard update for assigned users.

**6.6.3 Depth**

- Admin can evaluate each application based on scoring, questionnaire performance, and location
    preference before shortlisting.


- The shortlisted applications are automatically linked to both **DD-ZM** and **RBM** under their zonal
    purview.
- Each assignment creates an audit entry with timestamp, assigning authority, and remarks for
    traceability.
- Only valid user email IDs mapped to internal roles (DD-ZM/RBM) can be selected.
- System triggers workflow notifications and emails to the assigned reviewers with application
    references.
- Applications remain editable for Admin until confirmation of shortlisting.
- Assigned users can view assigned applications in their dashboards for evaluation.

**6.6.4 Personas-wise Accessibility & Visibility**

```
Persona Accessibility / Actions Visibility
DD-Admin Can view all received applications, shortlist eligible ones,
enter remarks, and assign to DD-ZM & RBM.
```
```
Full access to all
applications and history.
DD-ZM Can view shortlisted applications assigned to their zone
and proceed with evaluation.
```
```
Zone-wise shortlisted
applications.
RBM Can view and evaluate shortlisted applications for their
respective regions.
```
```
Region-wise shortlisted
applications.
ZBH / DD-Lead
/ NBH
```
```
Can view summary of shortlisted applicants for
monitoring and audit.
```
```
Read-only access.
```
```
Applicant Can view the updated application status as Shortlisted in
their dashboard.
```
```
Own application only.
```
### 6.7 Shortlisted Applicants

**6.7.1 Functionality Scope**

The **Dealership Requests** screen serves as a centralized workspace for managing and tracking
all **shortlisted dealer applications** that have successfully progressed through initial evaluation
stages. It consolidates applications that are ready for multi-level approval and further processing,
ensuring clear visibility of their current stage, location, and progress. This screen allows internal
users such as **DD-Lead, DD-ZM, and DD-Admin** to monitor real-time progress, review application


details, and proceed with subsequent workflow actions such as interviews, EOR tracking, and
final approval.

**6.7.2 Width**

- Located under the **Dealer Onboarding module → Dealership Requests**.
- Accessible to internal stakeholders involved in the approval cycle.
- Displays tabular data including:
    o ID and Applicant Name
    o Preferred and Applicant Location
    o Status (e.g., _Shortlisted, Level 1 Pending, Level 2 Approved, EOR In Progress_ )
    o Progress percentage bar
    o Date of Application and View Action Button
- Includes search, filter, and export options to enhance navigation and reporting efficiency.

**6.7.3 Depth**

- The screen lists only those applications that have been **shortlisted** from the Opportunity
    stage or advanced through earlier workflow levels.
- Each record dynamically reflects its **workflow status** , For example:
    o _Shortlisted_ – application qualified for initial evaluation.
    o _Level 1 Pending_ – awaiting review by DD-ZM and RBM.
    o _Level 2 Approved_ – cleared by DD-Lead and ZBH.
    o _Level 3 Pending -_ awaiting review by NBH + Head.
    o _EOR In Progress_ – dealership architecture and statutory stages initiated.
- The **Progress bar** visually indicates the percentage completion of each application’s end-
    to-end journey.
- Users can click **View** to open the Application Detail View for in-depth review and decision-
    making.
- All updates and transitions in application status are **system-driven** , ensuring traceability
    and eliminating manual tracking.

**6.7.4 Personas-Wise Accessibility & Visibility**

```
Persona Accessibility Visibility
Scope
DD-Admin Can view and monitor all shortlisted applications across
zones.
```
```
Full system
visibility.
DD-ZM / RBM Can access applications belonging to their assigned region
for Level 1 evaluation.
```
```
Regional
visibility.
DD-Lead / ZBH Can review and approve Level 2 applications. Zone-specific
visibility.
```

```
System
(Automation
Layer)
```
```
Updates workflow status and progress dynamically. Background
execution.
```
```
NBH The NBH oversees strategic decision-making across
dealer onboarding, resignation, and termination
workflows, and participates in critical approval and
governance checkpoints.
```
### 6.8 Application Detail View

**6.8.1 Functionality Scope**

The **Application Detail View** provides a consolidated and comprehensive overview of a dealer
applicant’s profile for internal reviewers such as the **DD-Admin, DD-ZM, and DD-Lead**. It
centralizes all relevant information submitted by the applicant and derived from the
questionnaire evaluation to support ranking and decision-making. This screen allows authorized


users to review applicant details, track progress, view ranks within the same city or region, and
take context-specific actions such as approving, rejecting, assigning, or scheduling interviews.

**6.8.2 Width**

- Located within the **Dealer Onboarding Module → Opportunity Requests → Application**
    **Detail** view.
- Accessible after selecting any applicant record from the Opportunity Requests list.
- Displays sections such as **Applicant Information** , **Summary** , **Actions** , and **Work Notes**.

**6.8.3 Depth**

- The **Applicant Information** section displays essential profile details including:
    o Full Name, Email, Mobile Number, and Age
    o Education Qualification and Past Experience
    o Preferred Location, Residential Address, and Business Address
    o Questionnaire Score (auto-calculated from applicant’s responses)
- The **Summary Panel** on the right-hand side presents:
    o Registration ID and Current Status of the application
    o Applicant’s **Rank** relative to other candidates in the same city, based on
       questionnaire scores
    o Visual **Progress Bar** indicating the current stage in the onboarding lifecycle
- The **Actions Panel** allows the reviewer to:
    o Approve or Reject the application at the respective level based on RBAC
    o Add **Work Notes** or comments visible to internal users
    o Schedule an Interview or Assign the application to another reviewer
- The **Work Notes Section** provides an audit of all communications and remarks exchanged
    during evaluation, maintaining process traceability.
- The **Ranking** is dynamically calculated based on the questionnaire’s total score within
    each city, ensuring comparative evaluation transparency.

**6.8.4 Personas-Wise Accessibility & Visibility**

```
Persona Accessibility Visibility Scope
DD-Admin Full access to view, edit, assign, and update
applicant details
```
```
Complete visibility
```
```
DD-ZM / DD-Lead /
RBM
```
```
Can review applicant profile, approve/reject,
add notes, and view rank
```
```
Region- or city-specific
visibility
System (Automation
Layer)
```
```
Auto-calculates rank and score; updates
status dynamically
```
```
Background operation
```

### 6.9 Interview Scheduling & Coordination

The **Interview Scheduling & Coordination** module enables the **Admin** to set up, manage, and
communicate interview sessions between dealership applicants and Royal Enfield’s evaluation
panel members. It supports scheduling across **Level 1, Level 2, and Level 3** interviews, ensuring
structured coordination and traceability. The feature provides flexibility to conduct interviews in
either **virtual** or **physical** mode and ensures timely notification of all stakeholders through
automated Google calendar invites. The goal is to streamline interview planning, eliminate
manual follow-ups, and ensure every shortlisted applicant is evaluated by the appropriate
authority as per the defined onboarding workflow.

**6.9.1 Width**

- Accessible under **Application Detail View → Schedule Interview**.
- Managed exclusively by **DD-Admin** for all interview levels.
- The form includes:
    o **Interview Type:** Level 1, Level 2, or Level 3
    o **Interview Mode:** Virtual (via Google Meet) or Physical (on-site venue)
    o **Date & Time:** Calendar-based selection
    o **Participants:** Field for adding evaluator email addresses (comma-separated)
    o **Meeting Link / Location:** Manually entered by Admin based on interview mode
- Once scheduled, the system sends **Google Calendar invites** to all participants and the
    applicant with the interview details embedded.

**6.9.2 Depth**

- **Interview Levels:**
    o _Level 1:_ Conducted by DD-ZM and RBM for preliminary evaluation and KT Matrix
       review.
    o _Level 2:_ Conducted by DD-Lead and ZBH for business and operational assessment.
    o _Level 3:_ Conducted by NBH and DD-Head as the final approval stage.


- The **Admin** manually adds the **Google Meet link** (for virtual interviews) or **venue**
    **address** (for physical sessions) before scheduling.
- After scheduling, a **Google Calendar invitation** is automatically triggered to all
    participants and the applicant, containing the meeting details, mode, and timing.
- The system automatically updates the **Application Timeline** to reflect the scheduled
    interview with date, time, and mode tags.
- All scheduling actions, including edits or reschedules, are captured in the **Audit Trail** for
    traceability.
- The feature ensures complete visibility and coordination across all levels of the interview
    process.

**6.9.3 Personas-Wise Accessibility & Visibility**

```
Persona Accessibility Visibility Scope
DD-Admin Can create, edit, and manage interview
schedules for all levels.
The DD ASM is responsible for interview
scheduling and coordination with dealer
prospects.
The Admin role does not participate in
interview scheduling and only facilitates
system - level access and configuration.
```
```
Full visibility.
```
#### DD-ZM / RBM / DD-

```
Lead / ZBH / NBH / DD-
Head
```
```
Receive Google Calendar invitations with
meeting details; can view schedule over
Google Calendar
```
```
Restricted to
assigned level and
applicant.
Applicant / Dealer
Prospect
```
```
Receives interview schedule via email and
Google Calendar invite with meeting details.
```
```
View-only for own
interview details.
System (Automation
Layer)
```
```
Sends Google Calendar invites, updates
application status, and logs actions in the Audit
Trail.
```
```
Background
execution.
```
### 6.10 Interview Evaluation & Feedback Management


**6.10.1 Functionality Scope**

The **Interview Evaluation & Feedback Management** module enables Royal Enfield’s internal
panel members to evaluate dealership applicants through structured, multi-level assessments. It
captures both **quantitative scoring** (via the KT Matrix) and **qualitative insights** (via structured
feedback forms) to ensure a balanced and transparent evaluation process. This module
standardizes the review and ranking procedure across **three interview levels** , integrates **AI-
assisted recommendations** , and provides consolidated visibility for final approval. It ensures that
each shortlisted applicant is assessed fairly, with complete traceability from panel feedback to
final NBH decision.

**6.10.2 Width**

- Accessible from **Application Detail View → Interview Evaluation** section.
- Used during all **three interview levels** :
    o **Level 1:** DD-ZM + RBM – Initial evaluation and KT Matrix scoring.
    o **Level 2:** DD-Lead + ZBH – Strategic and operational capability assessment.
    o **Level 3:** NBH + DD-Head – Final review and approval decision.


- Comprises two core components:
    o **KT Matrix Evaluation Form** – Records structured scores across weighted
       parameters.
    o **Interview Feedback Form** – Captures remarks, performance summaries, and
       recommendations.
- Once submitted, all feedback becomes read-only and is logged in the **Audit Trail** for
    compliance and future reference.

**6.10.3 Depth**

- **Multi-Level Interview Workflow:**
    o Applicants progress sequentially through Level 1, Level 2, and Level 3.
    o Interviews may be conducted **virtually via Google Meet** or **physically at**
       **designated venues**.
    o **DD-Admin** or **DD-Head** schedules interviews and sends **Google Calendar**
       **invites** to all panelists and the applicant.
    o The **Google Meet link** (for virtual sessions) or **venue address** (for physical sessions)
       is entered manually during scheduling.
- **KT Matrix Evaluation & Ranking:**
    o Panelists evaluate applicants using the configurable **KT Matrix** , which contains
       weighted parameters contributing to a total of 100%.
    o Evaluation fields include:
       ▪ Age and Qualification
       ▪ Local Knowledge and Influence
       ▪ Passion for Royal Enfield and Riding
       ▪ Business Acumen and Investment Capacity
       ▪ Base Location vs Applied Location
       ▪ Property Ownership, Time Availability, and Future Expansion Plans
    o The system auto-calculates total KT Matrix scores and updates the **applicant’s**
       **rank** within the city or region.
    o Ranking updates dynamically as evaluations are submitted, ensuring real-time
       comparison across applicants.
- **Interview Feedback Form:**
    o Enables panelists to provide qualitative assessments beyond numeric scoring.
    o Key feedback areas include:
       ▪ Strategic Vision and Market Understanding
       ▪ Management Capabilities
       ▪ Operational Readiness
       ▪ Key Strengths and Areas of Concern
    o Each panelist submits an **Overall Performance Score** and **Final**
       **Recommendation** ( _Approve_ , _Reject_ , or _Hold_ ).


```
o Remarks are consolidated for transparency and displayed in the application
timeline.
o All records are time-stamped and locked post-submission to preserve integrity.
```
**6.10.4 Panel Feedback & AI Recommendation**

- After each interview round, all **panel members except NBH** record their individual
    remarks, ratings, and recommendations in the system using the **Dealer Interview**
    **Recommendation Sheet (For CCO_NBH Approval.xlsx)** format.
- The **standard panel composition** includes:
    o Applicant (Prospect)
    o RBM (Regional Business Manager)
    o ZBH (Zonal Business Head)
    o DD-ZM (Zonal Manager)
    o DD-Lead
    o DD-Head
    o NBH (National Business Head – Final Approver)
- Each panelist logs their evaluation covering both **quantitative scores** (via KT Matrix)
    and **qualitative insights** (via feedback forms).
- Once all inputs are submitted, the system consolidates feedback and scoring data, then
    passes it to the **AI engine (Gemini API)**.
- The AI processes the inputs and generates a **two- to three-line summarized**
    **recommendation** that highlights:
       o Consensus trend across panelists
       o Applicant’s key strengths and differentiators
       o Potential concerns or areas for improvement
- The **AI-generated summary** is then presented to the **NBH** in editable format, allowing
    review and refinement before finalizing the decision.
- The **NBH** may:
    o Approve the AI-generated recommendation directly, or
    o Modify the summary to incorporate additional observations before final
       submission.
- This process ensures every recommendation reflects **data-backed consensus, AI-**
    **supported insights, and human judgment** , maintaining full transparency, accountability,
    and audit readiness.

**6.10.5 Personas-Wise Accessibility & Visibility**

```
Persona Accessibility Visibility Scope
DD-ZM / RBM
(Level 1)
```
```
Fill KT Matrix, record evaluation, remarks, and
recommendations. Filled by both.
```
```
Region-specific
visibility.
```

```
DD-Lead / ZBH
(Level 2)
```
```
Assess business strategy and operations, provide
structured feedback and score. Filled by both
```
```
Zone-level visibility.
```
```
NBH / DD-Head
(Level 3)
```
```
Review consolidated feedback, AI summary, and
finalize applicant decision.
```
```
Full visibility.
```
```
DD-Admin Monitor feedback submissions and completeness
across all interview levels.
```
```
Complete visibility
for compliance.
System
(Automation
Layer)
```
```
Consolidates scores, generates AI summaries, and
logs actions for audit.
```
```
Background
execution.
```
### 6.11 Interview Feedback & Evaluation Summary

**6.11.1 Functionality Scope**

The **Interview Feedback & Evaluation Summary** module consolidates all interview-level
assessments, feedback remarks, and scoring for each applicant in the dealership onboarding
process.
It provides a transparent, structured, and comparable view of candidate evaluations across levels,
helping decision-makers validate suitability based on quantified scores, qualitative remarks, and
panel feedback.


**6.11.2 Width**

- Accessible under the **Interviews tab** within the Application Detail View.
- Displays interview data level-wise, including:
    o **Interviewer Name and Role**
    o **Individual Scores** (out of configured weightage)
    o **Evaluator Remarks** and **Feedback Summary**
    o **Level-wise Overall Assessment and Decision Status**
- Supports multiple interview rounds such as **Level 1 (DD-ZM / RBM)** , **Level 2 (ZBH / DD**
    **Lead)** , and **Level 3 (DD Head / NBH)**.

**6.11.3 Depth**

```
6.11.3.1 Interview Recording & Display
```
- Each panel member records their evaluation through structured scoring criteria linked to
    the **KT Matrix**
- **KT Matrix (Kepner Tregoe Matrix)** is used to assess structured decision parameters
    during evaluation.
- The KT Matrix auto-calculates weighted scores based on parameters such as:
    o Business Acumen
    o Market Understanding
    o Financial Readiness
    o Passion for the Brand
    o Leadership and Team Capability
- Individual evaluator entries capture:
    o **Interviewer Name & Designation (Role)**
    o **Score / Weightage**
    o **Remarks** (qualitative observation)
    o **Feedback Summary** (behavioral and communication assessment)
- Scores from all panelists are auto-averaged to display the **Level Total Score** and **Rank** for
    each candidate.

```
6.11.3.2 Level-Wise Summaries
```
- Each interview level concludes with a **Level Summary** section containing:
    o **Decision Status:** _Approved / Rejected / Hold_
    o **Approver Comments:** Automatically tagged with evaluator roles (e.g., “Approved
       by both ZBH and DD Lead”).
    o **Overall Assessment:** Concise narrative summarizing candidate strengths,
       e.g., _“Strong candidate with excellent business plan and clarity of thought.”_


- This ensures consistent evaluation format and avoids subjective or incomplete data
    entries.

```
6.11.3.3 Data Traceability & Access Control
```
- Each interview and feedback entry is timestamped and recorded in the **Audit Trail** for
    compliance.
- Panel members can only view their respective entries until the stage closes.
- Once finalized, the complete evaluation summary becomes visible to higher authorities
    (DD-Head, NBH) for reference during final selection.
- No feedback modification is allowed post submission to preserve data integrity.

**6.11.4 Personas-Wise Accessibility & Visibility**

```
Persona Accessibility Visibility Scope
Interview Panel (DD-ZM /
RBM / ZBH / DD Lead / DD
Head / NBH)
```
```
Can record scores, remarks, and feedback
for assigned levels.
```
```
Access limited to
their interview
stage.
DD-Admin Can view all level-wise feedback and
compile summaries for reporting.
```
```
Full visibility and
export control.
DD-Head / NBH Can review all interview levels,
aggregated scoring, and AI
recommendations before final approval.
```
```
Read-only visibility
at summary stage.
```
```
Applicant / Dealer Prospect No access to internal evaluation data. Not visible.
System (Automation Layer) Aggregates scores, computes averages,
and stores all evaluation logs for audit
traceability.
```
```
Background
operation.
```
### 6.12 Application Approval & Rejection Workflow


**6.12.1 1. Functionality Scope**

The **Application Approval & Rejection Workflow** manages structured decision-making at each
level of the dealer onboarding process. It enables authorized evaluators and interview panel
members to **approve or reject** dealership applications with mandatory remarks and optional
attachments, ensuring transparent and traceable decisions. This feature operates throughout all
workflow stages — from **Level 1 to Level 3** — and captures evaluation outcomes in a unified
format that becomes part of the applicant’s permanent record. Each action taken is time-
stamped, logged, and visible to subsequent reviewers, promoting accountability across the
approval chain.

**6.12.2 Width**

- Integrated into the **Application Detail View** and accessible to all reviewers participating
    in the **approval hierarchy**.
- The feature appears as an **action modal** during each evaluation stage, allowing the panel
    to record feedback through one of two options:
       o **Approve Application** – with required remarks and optional document upload.
       o **Reject Application** – with mandatory justification for rejection.
- Available at all major decision levels:
    o **Level 1:** DD-ZM + RBM
    o **Level 2:** DD-Lead + ZBH
    o **Level 3:** NBH + DD-Head
- Each level’s action (approve or reject) is visible in the **Application Progress**
    **Tracker** and **Audit Trail**.

**6.12.3 Depth**

- **Approval Action:**
    o The panelist provides a **mandatory remark** summarizing the rationale behind
       approval.
    o Supporting documents, if any (e.g., business justification, property proof, or
       presentation decks), can be attached optionally.
    o Upon submission, the system updates the application status (e.g., _Level 1_
       _Approved, Level 2 Approved_ ) and logs the decision details for audit tracking.
    o It Also triggers the application to subsequent next level
- **Rejection Action:**
    o The panelist provides a **mandatory reason for rejection** , clearly outlining the
       grounds for disqualification.
    o The system changes the status to _Rejected_ and notifies the applicant and
       previous-level reviewers via email and WhatsApp.


```
o Rejected applications are archived for reference and may be reopened only
through Admin authorization.
```
- **Feedback Integration:**
    o Each level’s panel (DD-ZM, RBM, DD-Lead, ZBH, NBH, DD-Head) must record their
       respective feedback before submitting approval or rejection.
    o The recorded remarks automatically feed into the **consolidated interview and**
       **feedback record** , used for AI-assisted summary generation at the NBH stage.
- **Audit & Traceability:**
    o Every approval or rejection entry is **time-stamped** with user ID and role.
    o The system maintains a **complete audit trail** showing who approved, rejected, or
       commented, along with corresponding remarks and uploaded documents.
    o This ensures transparent review continuity across all approval levels.

**6.12.4 Personas-Wise Accessibility & Visibility**

```
Persona Accessibility Visibility Scope
DD-ZM / RBM
(Level 1)
```
```
Approve or reject applications post-KT Matrix
evaluation.
```
```
Region-specific
visibility.
DD-Lead / ZBH
(Level 2)
```
```
Review Level 1 feedback, provide comments, and
approve or reject accordingly.
```
```
Zone-level visibility.
```
```
NBH / DD-Head
(Level 3)
```
```
Final approval or rejection with AI-assisted
recommendation review.
```
```
Complete visibility.
```
```
DD-Admin Monitor decision trail, manage reassignments, and
maintain approval integrity.
```
```
Full administrative
visibility.
System
(Automation
Layer)
```
```
Updates application status, logs actions, and
triggers notifications via email & whatsapp to
applicant
```
```
Background
operation.
```

### 6.13 Work Notes & Internal Communication Trail

**6.13.1 Functionality Scope**

The **Work Notes & Internal Communication Trail** module serves as the centralized collaboration
channel for each dealership application. It enables authorized Royal Enfield stakeholders to
record, track, and exchange contextual comments directly within the system, eliminating the
need for external emails or offline communication.

Each work note is linked to a specific application, allowing panel members and reviewers to
maintain a continuous, transparent record of discussions and decisions. The feature improves
traceability, facilitates faster internal communication, and ensures that every remark is
permanently associated with its respective application record.

Work Notes serve as the **official communication channel for Send Back actions** , capturing
reviewer remarks and notifying concerned users within the resignation workflow. Work Notes
act as the **official communication channel for all Send Back and Revoke actions** across the
resignation workflow.


**6.13.2 Width**

- Accessible under **Application Detail View → Work Notes** tab.
- Available to all internal users participating in the onboarding and approval workflow (DD-
    ZM, RBM, DD-Lead, ZBH, DD-Head, NBH, Finance, and Legal).
- Displays a **chronological thread** of messages, with each entry showing the **comment**
    **author, role, timestamp, and tagged participants**.
- Allows cross-functional interaction and tagging for efficient information exchange and
    resolution tracking.

**6.13.3 Depth**

- **Comment Logging:**
    o Users can post comments, share clarifications, or document updates related to an
       application.
    o Each message is stored under the respective application ID to preserve discussion
       context.
- **Tagging & Notifications:**
    o Authorized users can **tag other stakeholders** using the “@mention” feature to
       seek inputs or actions.
    o Tagged users receive **email notifications** and **system alerts** with a direct link to
       the corresponding work note.
- **Visibility & Access Control:**
    o All internal users (RE employees) involved in the workflow can view the entire
       communication thread for the application.
    o **FDD (Financial Due Diligence) users** , being external partners, can **add comments**
       **or upload clarifications** related to their scope of review but **cannot view**
       **comments made by other users**.
    o This restricted access ensures confidentiality of internal deliberations while still
       allowing FDD to communicate and provide input efficiently.
- **Integration & Traceability:**
    o Work Notes are linked with system actions such as **interview**
       **scheduling** , **approvals** , and **feedback submissions** for contextual reference.
    o So every activity will also be logged in work note as well.
    o Every note is **timestamped** and logged under the **Audit Trail** for compliance
       verification.

**6.13.4 Personas-Wise Accessibility & Visibility**

```
Persona Accessibility Visibility Scope
```

#### DD-ZM / RBM / DD-

```
Lead / ZBH / NBH / DD-
Head
```
```
Can post, tag users, and view all
comments related to the application.
```
```
Full visibility within
their assigned region or
zone.
DD-Admin Can monitor all communication threads,
ensure comment quality, and flag
unresolved discussions.
```
```
Complete visibility.
```
```
Finance / Legal Can view and contribute to discussions
when tagged for specific clarifications.
```
```
Tag-based visibility.
```
```
FDD (External Agency) Can post comments and attach files
related to financial review but cannot
view others’ remarks.
```
```
Restricted visibility –
view only own
comments.
System (Automation
Layer)
```
```
Sends notifications for tags, logs all
messages, and maintains chronological
order in the Audit Trail.
```
```
Background operation.
```
### 6.14 System Notifications & Alerts

**6.14.1 Functionality Scope**

The **System Notifications & Alerts** module ensures timely communication of important events
and workflow updates to all authorized users involved in the dealer onboarding and offboarding
process. It serves as an in-application and email-based alert mechanism that informs users about
key actions such as application assignments, interview scheduling, document verification, and
status updates.

**6.14.2 Width**

- Accessible from the **top navigation bar** under the bell icon in the application interface.


- Displays a **dropdown list of recent notifications** , each showing:
    o A concise description of the event (e.g., _“Interview scheduled for APP-001”_ ).
    o The timestamp indicating when the event occurred.
    o A visual indicator for unread alerts.
- Includes a **“View All Notifications”** option that redirects users to the complete
    notification history page.
- Notifications are automatically generated for workflow events such as:
    o New application assignment
    o Interview scheduling or rescheduling
    o Document verification completion
    o Feedback submission
    o Application approval or rejection
    o Comment tagging in Work Notes

**6.14.3 Depth**

- **Trigger Logic:**
    o Notifications are auto-triggered by specific actions performed within the system,
       such as approval submission, interview creation, or applicant tagging.
    o Each alert is linked to the corresponding application ID, ensuring contextual
       reference when accessed.
- **Delivery Channels:**
    o Notifications appear as **in-system pop-ups** and are also stored under the
       notification dropdown.
    o For critical actions (e.g., interview scheduling or application assignment), an **email**
       **alert** is also sent to the concerned user.
    o For critical actions (e.g., interview scheduling, application assignment, or pending
       user actions), alerts are **sent via email and through WhatsApp**.
- **Read & Unread Management:**
    o Unread notifications are highlighted with an indicator dot until opened.
    o Once viewed, alerts are marked as read and retained in the user’s notification
       history for reference.
- **Audit Traceability:**
    o All notifications are logged under the **Audit Trail** , maintaining a traceable record
       of all communication triggers and delivery timestamps.

**6.14.4 Personas-Wise Accessibility & Visibility**

```
Persona Accessibility Visibility Scope
DD-ZM / RBM / DD-
Lead / ZBH / DD-Head /
NBH
```
```
Receive workflow alerts (assignments,
interviews, document verification, feedback).
```
```
Role-specific
notifications.
```

```
DD-Admin Can view and manage all notifications
generated across modules for monitoring
purposes.
```
```
Full visibility.
```
```
Finance / Legal / FDD Receive notifications related to their assigned
applications or document validation events.
```
```
Restricted to tagged
or assigned cases.
Applicant / Dealer
Prospect
```
```
Receive notifications for interview schedules,
approvals, feedback outcomes, and pending
actions via email and WhatsApp.
```
```
External limited
scope.
```
```
System (Automation
Layer)
```
```
Generates, delivers, and logs notifications
with timestamps.
```
```
Background
operation.
```
### 6.15 FDD (Financial Due Diligence) & Finance Module

**6.15.1 Functionality Scope**

The **FDD & Finance Module** manages the complete **Financial Due Diligence (FDD)** and
subsequent **Finance Review** workflow for dealership onboarding. It enables external FDD
partners to securely access their assigned applications, upload financial evaluation reports, and
collaborate with internal stakeholders through integrated Work Notes.
The module ensures **restricted access, secure data handling, and traceable financial review** ,
providing a seamless interface for Royal Enfield’s internal teams and external agencies to
collaborate while maintaining compliance and confidentiality.


**6.15.2 Width**

- Accessible through **RE SSO credentials** created for authorized external FDD partners.
- Once logged in, FDD users can view **only the applications assigned to them** for financial
    due diligence.
- Available features for the FDD role include:
    o **Limited Application View** — displaying key applicant details necessary for
       financial review.
    o **Document Upload Interface** — to submit financial artefacts and reports.
    o **Work Notes Section** — to raise queries or communicate updates with the RE
       Admin team.
    o **Submit Report Action** — for finalizing FDD evaluation.
- For internal users (Finance Team), this module extends to review, validate, and finalize
    financial recommendations post-FDD submission.

**6.15.3 Depth**

```
6.15.3.1 FDD Workflow & Capabilities
```
- **Access & Authentication:**
    o Each FDD partner receives a **dedicated SSO login** configured through RE’s identity
       system, ensuring secure and auditable access.
    o Upon login, the FDD user dashboard displays **only assigned applications** marked
       for due diligence.
    o External users have **limited access** — they cannot view internal remarks,
       evaluations, or other applications outside their assignment.
- **Application View & Interaction:**
    o FDD users can access restricted details such as applicant name, business location,
       and required financial documents.
    o They can upload their findings under the **Documents Section** and communicate
       updates or issues through **Work Notes**.
    o The Work Notes act as a **query and escalation tool** — allowing FDD users to
       request missing documents, seek clarifications, or flag non-responsive applicants.
- **Work Notes Integration:**
    o FDD users can add notes tagged to **DD-Admin** or **Finance Team** for specific actions.
    o In case the applicant fails to respond or provide requested documents, the FDD
       user adds a note citing **“Non-responsiveness from applicant”** and **returns the**
       **application** to Admin for closure or reallocation.
    o All such notes are logged chronologically with timestamps and author details for
       compliance.
- **Document Upload & Submission:**


```
o FDD users upload essential financial documents and reports such as:
▪ Bank Statements
▪ Income Tax Returns
▪ Credit Reports
▪ Property Papers
▪ Business Valuation Reports
o Each file entry records:
▪ File Name and Type
▪ Upload Date and Time
▪ Uploaded By (User ID / Role)
o Once the report is complete, the FDD user marks it as Submitted , which locks
further edits.
```
- **Finance Team Review:**
    o After submission, the **Finance Team** reviews the FDD report and uploaded
       artefacts.
    o They evaluate whether the applicant qualifies financially to move forward in the
       onboarding process.
    o Finance team members may also log remarks, flag discrepancies, or mark an
       application as **“Approved for Next Stage”** or **“Rejected on Financial Grounds.”**
    o Their decision updates the **Application Journey Tracker** and notifies **DD-**
       **Admin** and **NBH**.
- **Confidentiality & Audit Compliance:**
    o FDD users cannot view internal evaluations, interview feedback, or progress notes
       beyond their assigned stage.
    o All uploads, submissions, and Work Note interactions are **timestamped** and
       recorded under the **Audit Trail**.
    o The Finance Team’s review decisions are also logged for traceability and reporting.

**6.15.4 Personas-Wise Accessibility & Visibility**

```
Persona Accessibility Visibility Scope
FDD Team
(External Partner)
```
```
Can log in via SSO, view assigned
applications only, upload documents, and
communicate via Work Notes.
```
```
Restricted to assigned FDD
stage and specific
applications.
DD-Admin Can assign applications to FDD users,
monitor progress, and review Work Notes
or returned cases.
```
```
Full visibility across all
applications.
```
```
Finance Team Reviews submitted FDD reports, validates
financial compliance, and approves or
rejects based on findings.
```
```
Complete visibility of all
financial artefacts and
remarks.
DD-Head / NBH View finance-approved FDD reports for final
validation before LOI approval.
```
```
Read-only visibility post-
finance review.
```

```
System
(Automation
Layer)
```
```
Controls access through SSO, logs all
interactions, updates status, and notifies
stakeholders.
```
```
Background operation.
```
### 6.16 LOI Approval & Issuance

**6.16.1 Functionality Scope**

The **LOI Approval & Issuance** module governs the structured process of validating, approving,
and issuing the **Letter of Intent (LOI)** once the dealer applicant successfully clears all financial and
operational evaluations. It ensures that every LOI is issued only after submission and verification
of mandatory documents, confirmation of the security deposit, and formal approval by
authorized stakeholders — **Finance, DD-Head, and NBH**. This module brings
complete **transparency, document-level traceability, and compliance integrity** , ensuring that no
dealership appointment progresses without validated and approved documentation.

**6.16.2 Width**

- Accessible under **Application Journey → LOI Approval / LOI Issue** stages.
- Used sequentially by **DD-Admin** , **Finance** , **DD-Head** , and **NBH**.
- Major functional components include:
    o **LOI Document Request**
    o **Security Deposit Confirmation**
    o **Approval Chain (Finance → DD-Head → NBH)**
    o **Final LOI Preparation and Issuance**


- Once approved, the LOI is issued and the application progresses automatically to **Security**
    **Details** and **Dealer Code Generation** stages.

**6.16.3 Depth**

```
6.16.3.1 Document Request & Collection
```
- Upon completion of the final interview and financial approval, the **DD-Admin** triggers an
    automated **LOI Document Request** to the applicant.
- The applicant is required to upload the prescribed set of documents and artefacts in
    a **Linked Folder** , following the official naming convention:
       o **Region → Name of Prospect → Location → Interview Date → LOI Issuance Date.**
- The folder and files are reviewed by the Admin and Finance teams for completeness
    before progressing to approval.

```
6.16.3.2 Mandatory LOI Document Checklist
```
The following artefacts must be submitted before the LOI can be approved:

- DIP Booklet – filled and signed by RBM
- Profile Sheet
- Dealership Application Form
- Interview Feedback Forms (RBM and ZBH)
- Land Selection Criteria Sheet
- Logic Note and Comparative Logic Note
- Zonal Evaluation Form
- Authorization Letter
- City Map (PPT)
- Proposed Location Photos (minimum 20, PPT)
- Layout Drawings (PPT)
- Viability Sheet
- Project Plan
- Self-signed PAN/Aadhaar of all partners (both sides)
- CIBIL Reports of all partners
- Dealership Name & Address Email from RBM
- Rental / Lease Agreement or Consent Letter from Landlord
- Security Deposit Proof (to be uploaded **only after** document set completion)


```
6.16.3.3 Folder Verification & Tracking
```
- The Admin verifies that all files are uploaded in the specified folder format and uses
    metadata such as **Interview Date** , **LOI Issuance Date** , and **Document Ageing** (days
    between interview and issuance) to track process efficiency.
- Any missing or incorrect artefacts trigger a system reminder to the applicant or DD-Admin
    for rectification before the approval process can begin.

```
6.16.3.4 Security Deposit Validation
```
- After successful folder verification, the **Admin requests the applicant to perform the**
    **security deposit transfer via RTGS**.
- Deposit proof (transaction slip or confirmation) is uploaded into the folder and validated
    by Finance.
- Only after deposit confirmation does the system allow LOI preparation to proceed.

```
6.16.3.5 Approval Workflow
```
- The **LOI document** is generated using the approved RE format and automatically
    populated with applicant and dealership details.
- The approval routing follows this sequence:
    o **Finance Team:** Reviews document completeness and verifies the security deposit.
    o **DD-Head:** Validates business justification and network alignment.
    o **NBH:** Provides final release authorization through the system.
- Each approver records mandatory remarks before submission, ensuring transparency at
    every step.
- Once NBH approves, the LOI is marked as **“Ready to Issue.”**

```
6.16.3.6 LOI Issuance
```
- **DD-Admin** uploads the final signed LOI under the **LOI Issue** stage.
- The system triggers:
    o An **official email notification** with the issued LOI is sent to the dealer upon
       completion of the LOI issuance stage. This will **not be sent on WhatsApp.**
    o Alerts to **Finance** , **DD-Head** , and **NBH** confirming completion of issuance.
- The applicant must upload an **LOI Acknowledgement Copy** with seal and signature to
    confirm receipt.

```
6.16.3.7 Document & Artefact Tracking
```
- Every LOI-related artefact includes:
    o File Name and Type


```
o Uploaded By (User Role and Name)
o Upload Timestamp
o Version (Draft, Final, Signed Copy)
o Download Link
```
- Each file upload, review, and replacement is logged under the **Audit Trail** to maintain a
    chronological record of actions.

**6.16.4 Personas-Wise Accessibility & Visibility**

```
Persona Accessibility Visibility Scope
DD-Admin Initiates document requests, validates uploads,
manages security deposit confirmation, and
uploads final LOI.
DD ASM, DD ZM, and RBM shall have view-only
access to the workflow.
The DD Lead shall have approval visibility , without
direct approval authority at this stage.
```
```
Full access and edit
rights.
```
```
Finance Team Verifies security deposit and financial artefacts
before LOI preparation.
```
```
Full visibility for
validation.
DD-Head Approves LOI content and validates alignment with
dealership network plans.
```
```
Approval-level
visibility.
NBH Provides final release authorization and approves
LOI issuance.
```
```
Full visibility for
sign-off.
Applicant / Dealer
Prospect
```
```
Uploads required LOI documents and provides
security deposit confirmation.
```
```
Access limited to
own uploads.
System
(Automation
Layer)
```
```
Monitors document checklist, logs folder actions,
routes approvals, calculates ageing, and triggers
notifications.
```
```
Background
operation.
```
### 6.17 Dealer Code Generation, Architectural Work & Statutory Documentation............


**6.17.1 Functionality Scope**

This consolidated module covers the post-LOI implementation stages that transition a selected
dealer from approval to operational readiness. It manages three critical workflows:

- **Dealer Code Generation** – creation of a unique, system-integrated dealership identifier.
- **Architectural Work** – coordination between Admin and Brand Experience teams to
    execute layout, design, and site readiness.
- **Statutory Documentation** – collection and validation of mandatory compliance
    documents.

Together, these processes ensure the dealership becomes fully compliant, aligned with Royal
Enfield’s brand standards, and ready for inauguration.

**6.17.2 Width**

- Accessible sequentially in the **Application Journey** after _LOI Issued_.
- Managed by **DD-Admin** , with participation from **Architecture / Brand Experience**.
- Progress and status for each sub-module are reflected in the **Progress Tracker**.

**6.17.3 Depth**

```
6.17.3.1 A. Dealer Code Generation
```
- Once the LOI is acknowledged, **DD-Admin** initiates **dealer code creation** through SAP
    using an **OData API integration**.
- The system generates and stores multiple associated codes for:
    o **Sales Code**
    o **Service Code**
    o **Genuine Motorcycle Accessories (GMA) Code**
    o **Gear Code**
- These codes uniquely identify all dealer operations across RE systems (DMS, MSD, CRM).
- Code creation details (initiator, timestamp, and reference IDs) are recorded in the **Audit**
    **Trail**.
- The application status updates automatically to _Dealer Code Generated_ and triggers
    notifications to DD-Admin, Finance, and Legal.

```
6.17.3.2 Architectural Work (Brand Experience Team)
```
- After code generation, **DD-Admin assigns the case** to the **Architecture / Brand**
    **Experience Team** for site design and infrastructure execution.


- The workflow covers:
    o **Part A – Architecture:**
       ▪ Admin assigns case → Architecture Team.
       ▪ Architecture uploads **DWG layout** and **site dimension drawings**.
       ▪ Dealer provides written consent via email confirming acceptance of layout
          as per Vastu and design guidelines.
       ▪ Final layout issued to dealer along with **multiple drawing sets** for
          construction reference.
       ▪ Dealer initiates infrastructure work; progress tracked through uploaded
          photographs or reports.
    o **Part B – Statutory Fulfilment:**
       ▪ Admin and Architecture teams collect mandatory statutory compliance
          documents from the dealer.
       ▪ These include government, financial, and brand compliance artefacts
          required before EOR.
- The Architecture team updates milestone completion, and all uploads (drawings,
    approvals, and dealer confirmations) are recorded with timestamps and uploader details.

```
6.17.3.3 Statutory Documentation
```
- At this stage, **DD-Admin** collects and verifies all statutory and regulatory documents
    necessary for legal and operational readiness.
- The standard document checklist includes:
    o GST Registration Certificate
    o PAN
    o Nodal Agreement
    o Cancelled Cheque
    o Partnership Deed / LLP / MOA / AOA / COI
    o Firm Registration Certificate
    o Rental / Lease / Land Agreement
    o Virtual Code Confirmation
    o Domain ID for _@dealer.royalenfield.com_
    o MSD (Microsoft Dynamics) Configuration confirmation (ledger setup)
    o LOI Acknowledgement Copy (signed by dealer)
- Each document record displays:
    o File name and type
    o Uploaded by (user role and name)
    o Upload timestamp
    o Version (if replaced or re-uploaded)
- Files are viewable and downloadable from within the application, and all versions are
    retained for compliance audits.


- The **Finance and Legal teams** verify documents, update status to _Verified / Pending / Re-_
    _submit Required_ , and add remarks.
- Once all statutory items are verified, the system automatically transitions the application
    to the **EOR (Essential Operating Requirements)** stage.

**6.17.4 Personas-Wise Accessibility & Visibility**

```
Persona Accessibility Visibility Scope
DD-Admin Initiates dealer code creation, coordinates
architectural assignments, and collects
statutory documents.
DD ASM, DD ZM, and RBM shall have view-
only access for monitoring and reference
purposes.
```
```
Full visibility and
control.
```
```
Architecture / Brand
Experience Team
```
```
Uploads drawings, issues layout approvals,
and updates site readiness milestones.
```
```
Limited to assigned
applications.
Finance Team Reviews statutory artefacts (GST, banking,
MSD) and confirms financial readiness.
```
```
Verification-level
visibility.
Legal Team Verifies agreements, firm registration, and
compliance documents.
```
```
Tag-based visibility
for assigned items.
Dealer / Applicant Uploads statutory artefacts and provides
consent on architecture layouts.
```
```
Restricted to own
uploads.
System (Automation
Layer)
```
```
Syncs SAP dealer code generation, updates
stage transitions, and logs all artefacts with
timestamps.
```
```
Background
operation.
```
### 6.18 LOA Issuance, Essential Operating Requirements & Inauguration

**6.18.1 Functionality Scope**

The **LOA Issuance, Essential Operating Requirements (EOR) & Inauguration** module captures
the final execution phase of the dealer onboarding lifecycle. It ensures that only those dealerships
which have fulfilled all architectural, statutory, and financial prerequisites are authorized to
commence operations under Royal Enfield’s network.
This module manages the formal **Letter of Agreement (LOA)** release, verification of **EOR
compliance** , and the **dealership inauguration process** , providing complete visibility, audit
control, and cross-departmental coordination before official go-live.

The **Letter of Agreement (LOA) is a parallel statutory activity** and is **not dependent on
infrastructure readiness** for issuance. LOA processing and issuance proceed **in parallel with**


**statutory compliance checks** , while infrastructure readiness is tracked independently for final
go-live.

**6.18.2 Width**

- Accessible sequentially in the **Application Journey** , following completion of statutory
    compliance and architectural validation.
- Managed primarily by **DD-Admin** , with review and approvals by **DD-**
    **Head** , **NBH** , **Architecture** , **Training** , and **Brand Experience** teams.
- Tracks readiness status and documents through EOR and Inauguration milestones.

**6.18.3 Depth**

```
6.18.3.1 LOA (Letter of Agreement) Issuance
```
- Once statutory verification and site readiness are complete, **DD-Admin** initiates the **LOA**
    **document preparation**.
- The **LOA** serves as Royal Enfield’s formal authorization, confirming that the dealer has
    met all required pre-operational standards.
- The approval routing follows:
    o **DD-Head:** Reviews infrastructure completion, EOR readiness, and compliance
       artefacts.
    o **NBH:** Grants final sign-off authorizing the dealership to operate.
- The finalized LOA document is uploaded into the system by DD-Admin, tagged with:
    o Issue Date
    o Authorized Signatory (DD-Head / NBH)
    o Document Version and Upload Timestamp
- The LOA issuance automatically updates the Application Journey status to _“Authorized for_
    _Operations.”_
- System-generated notifications are sent to all relevant teams, confirming dealership
    activation.

```
6.18.3.2 Essential Operating Requirements (EOR)
```
- The **EOR checklist** ensures that each new dealership is fully operationally ready prior to
    launch.
- It includes mandatory pre-opening parameters across business, facility, and IT domains,
    such as:
       o Display Vehicle Readiness


```
o Brand Signage Installation
o Training Completion for Sales and Service Teams
o MSD / DMS Configuration and Connectivity
o Availability of Service Tools, Equipment, and Spare Inventory
o Safety, Security, and Facility Compliance Checks
o Test Ride Vehicles and Customer Experience Readiness
```
- Each EOR line item is verified and marked as _Complete / Pending / Non-Compliant_ by the
    respective functional team (Architecture, Training, IT, Service).
- The system records:
    o EOR Checklist File
    o Verification Date
    o Verified By (User and Role)
    o Comments or Exception Notes
- Once all checklist parameters are marked as _Complete_ , DD-Admin updates the EOR stage
    status to _EOR Completed_.
- This completion enables scheduling of the final **Inauguration**.

```
6.18.3.3 Inauguration & Go-Live
```
- Upon EOR completion, **DD-Admin** coordinates with the **NBH, ZBH, RBM** , and **Brand**
    **Experience** teams to finalize the inauguration plan.
- The **inauguration details** are logged in the system, including:
    o Inauguration Date and Venue
    o Attendees (NBH, DD-Head, ZBH, RBM, Architecture, Brand Experience)
    o Photographs and Event Summary Report
- Post-event, the Admin uploads the **Inauguration Report** and related media (photographs,
    press releases, or video references).
- The system marks the application as _“Dealership Live / Onboarded.”_
- Key metadata such as inauguration date, event photos, and final status are stored under
    the **Application Journey** for historical tracking.

**6.18.4 Personas-Wise Accessibility & Visibility**

```
Persona Accessibility Visibility Scope
DD-Admin Manages LOA creation, tracks EOR checklist
completion, and logs inauguration details.
The DD ASM is authorized to upload LOA-
related documents to support statutory and
compliance verification
```
```
Complete visibility
and control.
```
```
DD-Head / NBH Approve LOA issuance and review final
readiness for operational authorization.
```
```
Approval-level
visibility.
```

```
Architecture /
Brand Experience
```
```
Verify physical readiness, signage, and brand
compliance.
```
```
Access limited to
assigned EOR items.
Training / IT /
Service Teams
```
```
Verify operational readiness across staff
training, tools, and systems configuration.
```
```
Tag-based visibility.
```
```
Dealer / Applicant Acknowledges LOA receipt and supports
inauguration planning.
```
```
Restricted to their
assigned application.
System
(Automation Layer)
```
```
Logs EOR verifications, uploads inauguration
metadata, triggers status updates and
notifications.
```
```
Background
operation.
```
### 6.19 Essential Operating Requirements (EOR) Checklist

**6.19.1 Functionality Scope**

The **Essential Operating Requirements (EOR) Checklist** module ensures that all pre-launch
business, infrastructure, compliance, and operational prerequisites are fulfilled before a
dealership is formally inaugurated.

**6.19.2 Width**

- Accessible under the **EOR Checklist tab** in the Application Detail View.
- Displays a checklist of all operational readiness parameters with their current completion
    status.
- Each item includes:
    o Parameter Name (e.g., _Sales Standards, DMS Infra, Manpower Training_ )


```
o Status Indicator ( Pending / Completed / Verified )
o Assigned Team or Reviewer (Architecture, IT, Finance, Training, etc.)
```
- The progress bar at the top dynamically updates the **EOR completion percentage** based
    on verified items.
- Supports both in-system verification and document-based validation uploads.

**6.19.3 Depth**

```
6.19.3.1 EOR Parameter Configuration
```
- The checklist is pre-configured with mandatory items applicable to every dealership
    before activation.

```
6.19.3.2 Status Management & Verification
```
- Each item can be marked as _Pending_ , _In Progress_ , or _Completed_ by the respective
    responsible department.
- Functional owners (Finance, Training, IT, etc.) verify and mark their sections complete.
- The **DD-Admin** oversees all updates, ensuring every checklist item is validated before
    final approval.
- Completion of all mandatory parameters automatically updates the stage to _EOR_
    _Completed_.
- Remarks or proof of completion (documents, screenshots, or photos) can be attached to
    each item for audit purposes.

```
6.19.3.3 Progress Calculation & Tracking
```
- The system automatically calculates the EOR completion percentage based on total
    verified parameters.
- Visual progress indicators are shown both at item and overall level.
- Hover or click actions reveal who completed each parameter and when.
- The **Audit Trail** logs each checklist update with timestamps for traceability.

```
6.19.3.4 Integration with Inauguration Readiness
```
- Once the EOR checklist reaches 100% completion, the system triggers a readiness alert
    to **DD-Head** and **NBH**.
- The application automatically transitions to the **Inauguration Stage** , initiating event
    scheduling and brand readiness verification.
- EOR verification data remains accessible for post-launch audits.


**6.19.4 Personas-Wise Accessibility & Visibility**

```
Persona Accessibility Visibility Scope
DD-Admin Monitors and updates EOR checklist progress,
consolidates remarks, and verifies stage
completion.
DD ASM and DD ZM are authorized to upload
site readiness details.
DD Lead, RBM, and ZBH shall have view-only
access for review and governance.
```
```
Full visibility and
edit rights.
```
```
Architecture / Brand
Experience
```
```
Update and mark parameters complete as per
their domain.
```
```
Tag-based
restricted visibility.
DD-Head / NBH View final EOR completion status and remarks
before authorizing inauguration.
```
```
Read-only visibility
for approval.
Dealer / Applicant May be asked to upload supporting artefacts
(photos, certificates, invoices).
```
```
Limited to assigned
items.
System (Automation
Layer)
```
```
Calculates completion percentage, updates
stage transitions, and logs verification activities.
```
```
Background
operation.
```
### 6.20 Progress Tracker.......................................................................................................


**6.20.1 Functionality Scope**

The **Application Journey & Progress Tracker** provides a complete visual representation of the
dealership application’s lifecycle — from submission through multi-level evaluations, due
diligence, and final dealership inauguration. It will be maintained in itemized way for each
applicant
It allows all authorized Royal Enfield users to track each milestone in real time, review supporting
documents, and monitor who performed specific actions and when. This ensures **end-to-end
transparency, document-level traceability, and operational accountability** throughout the
dealer onboarding and approval process.

**6.20.2 Width**

-
- Accessible within **Application Detail View → Progress Tab**.
- Displays a **vertical, stage-based timeline** of all workflow steps with corresponding
    completion statuses.
- Each milestone includes:
    o Stage title and brief description (e.g., _1st Level Interview – DD-ZM + RBM_
       _Evaluation_ ).
    o Evaluator details and assigned roles.
    o Status indicator ( _Completed, In Progress, Pending_ ).
    o Date and timestamp of completion.
    o **Document and artefact count** , with clickable links to download or review the
       uploaded files.
- Covers all workflow phases — from **application submission** to **inauguration and go-live**.
- LOI Issue → Dealer Code Generation → **LOA Issuance** → **EOR Checklist Completion** →
    Inauguration & Go-Live

**6.20.3 Depth**

```
6.20.3.1 Stage-Wise Progress Representation:
```
```
o Submitted: Application logged with basic details and initial document uploads.
o Questionnaire: Applicant questionnaire completed and scored.
o Shortlist: DD-Admin review with uploaded validation documents.
o 1st Level Interview: Conducted by DD-ZM and RBM , with evaluator remarks and
attachments.
o 2nd Level Interview: Conducted by DD-Lead and ZBH , capturing evaluation
documents and recommendations.
```

```
o 3rd Level Interview: Conducted by NBH and DD-Head , includes final approval
documentation and AI recommendation summary.
o FDD (Financial Due Diligence): Handled by the FDD partner for financial validation;
documents uploaded for review.
o LOI Approval: Preparation and verification for Letter of Intent issuance.
o Security Deposit: Security and compliance document verification stage.
o LOI Issue: Formal Letter of Intent generated and uploaded.
o Dealer Code Generation : Dealer Code creation is initiated upon trigger by the DD-
Admin , created in the SAP Master , and logged against the application for audit
and traceability.
o Architectural Work: Contains sub-steps —
▪ Assigned to Architecture Team
▪ Architectural Document Upload
▪ Architecture Team Completion
o Statutory Documents: Eleven-step checklist for compliance uploads including:
▪ GST Certificate
▪ PAN
▪ Nodal Agreement
▪ Cancelled Cheque
▪ Partnership Deed / LLP / MOA / AOA / COI
▪ Firm Registration Certificate
▪ Rental / Lease / Land Agreement
▪ Virtual Code
▪ Domain ID
▪ MSD Configuration
▪ LOI Acknowledgement Copy
o LOA (Letter of Agreement): Issued after LOI acceptance.
o EOR (Essential Operating Requirements): Verification of pre-opening operational
criteria.
o Inauguration: Final dealership launch milestone.
```
**6.20.3.2** Document & Artefact Management:

```
o At every stage, the tracker displays document and artefact names , along
with downloadable links for review.
o Each document entry includes:
▪ File name and type (PDF, image, Excel, etc.)
▪ Uploaded by (user name and designation)
▪ Upload timestamp and workflow stage
o This provides clear visibility into which document was added, by whom, and at
what level.
```

```
o Documents can be previewed or downloaded directly from the tracker for audit
and compliance review.
o Any re-upload or replacement creates a versioned entry , preserving historical
visibility.
```
```
6.20.3.3 Evaluator Tracking & Status Indicators:
```
```
o Evaluator details (e.g., DD-ZM, RBM, ZBH, DD-Head, NBH) are shown for each
interview and approval stage.
o Completed steps are marked in green with timestamps; pending stages appear
grey.
o In-progress stages update dynamically as actions are performed.
```
**6.20.4 Personas-Wise Accessibility & Visibility**

```
Persona Accessibility Visibility Scope
DD-ZM / RBM / DD-
Lead / ZBH / DD-Head /
NBH
```
```
Can view all stages, download documents,
and verify evaluator remarks for assigned
applications.
```
```
Role-based visibility
within region or
zone.
DD-Admin Full access to track overall progress, verify
documents, and audit stage-wise actions.
```
```
Complete visibility.
```
```
FDD (External Agency) Can upload and review documents related to
financial due diligence but cannot access
internal stages.
```
```
Restricted to FDD
workflow stage.
```
```
Finance / Legal Can review and upload documents within
assigned compliance or verification stages.
```
```
Tag-based visibility.
```
```
System (Automation
Layer)
```
```
Updates stage completion, uploads
metadata, and logs all actions in the Audit
Trail.
```
```
Background
operation.
```
```
Applicant + DD ASM
Access
```
```
The applicant shall have limited, stage-
specific access to the portal.
The DD ASM is granted access to designated
stages for document upload and
coordination activities.
```

### 6.21 Central Document Repository

**6.21.1 Functionality Scope**

The **Central Document Repository** serves as a unified digital storage system that consolidates all
applicant documents, artefacts, and submissions across the dealer onboarding and offboarding
lifecycle.
It provides authorized users with **quick, structured, and traceable access** to every document
uploaded during the application process — ensuring consistency, transparency, and audit
readiness across departments.

**6.21.2 Width**

- Accessible from the **Documents tab** within each application’s detail view and from
    the **Central Repository dashboard** for cross-application reference.
- Displays a **tabular view** with the following columns:
    o **File Name** (hyperlinked to the document)
    o **Type** (e.g., PDF, JPG, XLSX, DOCX)
    o **Upload Date**
    o **Uploader** (user name and designation)
    o **Actions** (download or view document)
- Includes an **Upload Document** button for authorized users to add new or supplementary
    files.
- Supports **document preview and download** with automatic logging into the Audit Trail.


**6.21.3 Depth**

- **Document Aggregation:**
    o All documents uploaded by the applicant or internal users — across stages such
       as Application Submission, FDD, LOI, Statutory, and EOR — are automatically
       consolidated here.
    o The system captures metadata for each file:
       ▪ File name and format
       ▪ Uploaded by (user and role)
       ▪ Timestamp of upload
       ▪ Stage and status of workflow at upload time
    o Ensures centralized visibility and prevents duplication of files across stages.
- **Access & Visibility:**
    o Each user role (Admin, Finance, Architecture, Legal, etc.) can view only those files
       relevant to their assigned application stage.
    o Files uploaded by applicants are visible to authorized RE personnel
- **Data Integrity & Auditability:**
    o Every upload, download, or replacement is automatically logged in the **Audit**
       **Trail** with timestamp and user identity.
    o The repository supports RE’s internal compliance requirement for **document**
       **retention and traceability** , ensuring complete transparency in every workflow.

**6.21.4 Personas-Wise Accessibility & Visibility**

```
Persona Accessibility Visibility Scope
DD-Admin Full access to upload, view, and download all
documents across applications.
```
```
Complete
visibility and
control.
Finance / Legal /
Architecture / Brand
Experience Teams
```
```
View and verify documents relevant to their
assigned stages (FDD, LOI, Statutory, EOR).
```
```
Role-based
restricted
visibility.
DD-Head / NBH Read-only access to review applicant artefacts
and approvals for final decision-making.
```
```
Read-only
visibility.
System (Automation
Layer)
```
```
Aggregates documents from all workflow
stages, maintains version control, and syncs
logs with Audit Trail.
```
```
Background
operation.
```
```
Applicant + DD ASM
Access
```
```
The applicant shall have limited, stage-
specific access to the portal.
The DD ASM is granted access to designated
stages for document upload and
coordination activities.
```

### 6.22 Audit Trail & Activity Log..........................................................................................

**6.22.1 1. Functionality Scope**

The **Audit Trail & Activity Log** module maintains a complete chronological record of all system
activities, transactions, and user actions performed throughout the dealer onboarding and
offboarding lifecycle. It provides an **immutable, timestamped, and role-based** view of every
workflow step, ensuring **traceability, accountability, and compliance** across all process stages.

Resignation Sent Back by ZBH – Remarks posted via Work Notes.
Resignation Sent Back by DD-Lead – Remarks posted via Work Notes.
Resignation Revoked by NBH – Action logged with justification.

**6.22.2 2. Width**

- Accessible under the **Audit Trail tab** in the **Application Detail View** for every applicant.
- Displays a structured log of all activities related to that specific application.
- Each log entry includes:
    o **Action Type** (e.g., Application Submitted, Questionnaire Completed, Interview
       Scheduled, LOI Issued).
    o **Performed By** (user name and designation, or “System” for automated actions).
    o **Description / Remarks** (detailing what was done).
    o **Timestamp** (exact date and time of the event).
- Entries are displayed in descending chronological order to ensure the latest actions are
    always visible.


**6.22.3 3. Depth**

```
6.22.3.1 Activity Logging
```
- Every workflow event — from form submission to final approval — is automatically logged
    by the system.
- Typical recorded events include:
    o Application creation, submission, and status transitions.
    o Interview scheduling and completion.
    o Document uploads, downloads, and version updates.
    o FDD submissions and Finance validations.
    o LOI, LOA, and EOR stage completions.
    o Inauguration logging and closure actions.
    o WhatsApp Notification Triggered – Questionnaire Reminder Sent to Applicant.
- System-triggered events (e.g., _Questionnaire Link Sent_ , _Automated Email Triggered_ ) are
    explicitly marked as performed “by System.”
- User-initiated actions record both name and role for audit clarity.
- Dealer Resignation Initiated by Dealer – Request submitted via dealer portal.

```
6.22.3.2 Description & Detailing
```
- Each entry provides a concise description of the event and its context.
    o Example:
       ▪ _Application Submitted by Amit Sharma — Initial application form_
          _submitted._
       ▪ _Questionnaire Completed by Applicant — Scored 85/100._
       ▪ _LOI Approved by DD-Head — Document ready for issue._
- Any event with system interaction or document movement captures associated metadata
    such as document name, file type, and upload path.

```
6.22.3.3 Search, Filter & Export Capabilities
```
- Users can **search** or **filter** logs by:
    o Date Range
    o Action Type
    o User or Role
- The entire log can be **exported as a PDF** for audit or compliance reporting.

```
6.22.3.4 Integration with Other Modules
```
- The Audit Trail is integrated with all system modules, including:
    o **Documents Repository:** Logs every upload, download, or version replacement.


```
o Work Notes: Captures internal discussions and query responses.
o Notifications: Records every alert or email triggered by the system.
o Interview Feedback: Stores evaluator submissions and decision timestamps.
o LOI / LOA / EOR Stages: Marks approvals, uploads, and status changes.
```
- This unified tracking ensures there are **no unrecorded actions** , regardless of user role or
    stage.

```


