# 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: 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 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. ```