laxman h 2b73036bb9 notification service enhanced even more detailed way added more templates documentented i splitted based on modulewise

2026-04-30 18:49:11 +05:30

94 KiB

Raw Blame History

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 Authorization) & Final Go-Live

After LOI issuance and Dealer Code generation, the Letter of Authorization (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:

If an opportunity exists , the applicant receives an Opportunity Email , confirming that their location is currently under consideration.
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

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 Authorization (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 Authorization (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 Authorization) 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 Details: 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 Authorization): 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.

94 KiB Raw Blame History Unescape Escape

RE Onboarding

2.2 External & Integrated Stakeholders

3 Definitions and Acronyms

4 HiFi Wireframes & Flow of Application

4.1 Dealer onboarding - Process Flow Overview

5 System Features & Requirements

6 Dealer onboarding

6.1 Dealership Application Form

6.3 Dashboard

6.4 Opportunity & Non Opportunity

6.5 Questionnaire Response

6.6 Shortlisting Process

6.7 Shortlisted Applicants

6.8 Application Detail View

6.9 Interview Scheduling & Coordination

DD-ZM / RBM / DD-

6.10 Interview Evaluation & Feedback Management

6.11 Interview Feedback & Evaluation Summary

6.12 Application Approval & Rejection Workflow

6.13 Work Notes & Internal Communication Trail

DD-ZM / RBM / DD-

6.14 System Notifications & Alerts

6.15 FDD (Financial Due Diligence) & Finance Module

6.16 LOI Approval & Issuance

6.17 Dealer Code Generation, Architectural Work & Statutory Documentation............

6.18 LOA Issuance, Essential Operating Requirements & Inauguration

6.19 Essential Operating Requirements (EOR) Checklist

6.20 Progress Tracker.......................................................................................................

6.21 Central Document Repository

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

94 KiB

Raw Blame History