# RE Onboarding & Offboarding System # Requirements ``` System Requirements Specifications ``` ## 16 - Oct- 2025 ## Version 1. 4 ## Contents - Change Log - 1.1 Change Log – Version 2.0 - 1.2 Change Log – Dealer Self-Service Enablement - 1 System Overview & Problem Statement - 2 Intended Audience - 2.1 Business & Functional Users - 2.2 External & Integrated Stakeholders - 3 Definitions and Acronyms - 4 HiFi Wireframes & Flow of Application - 4.1 Dealer onboarding - Process Flow Overview - 4.2 Dealer Resignation – Process Flow Overview - 4.3 Dealer Termination – Process Flow Overview - 4.4 Dealer Full & Final (F&F) Settlement – Process Flow - 4.5 Finance Team – Process Flow - 5 System Features & Requirements - 6 Dealer onboarding - 6.1 Dealership Application Form - 6.2 SSO Login - 6.3 Dashboard - 6.4 Opportunity & Non Opportunity - 6.5 Questionnaire Response - 6.6 Shortlisting Process - 6.7 Shortlisted Applicants - 6.8 Application Detail View - 6.9 Interview Scheduling & Coordination - 6.10 Interview Evaluation & Feedback Management - 6.11 Interview Feedback & Evaluation Summary - 6.12 Application Approval & Rejection Workflow - 6.13 Work Notes & Internal Communication Trail - 6.14 System Notifications & Alerts - 6.15 FDD (Financial Due Diligence) & Finance Module - 6.16 LOI Approval & Issuance - 6.17 Dealer Code Generation, Architectural Work & Statutory Documentation............ - 6.18 LOA Issuance, Essential Operating Requirements & Inauguration - 6.19 Essential Operating Requirements (EOR) Checklist - 6.20 Progress Tracker....................................................................................................... - 6.21 Central Document Repository - 6.22 Audit Trail & Activity Log.......................................................................................... - 7 Dealer Resignation - 7.1 Dealer Resignation Request (Initiation) - 7.2 Resignation Management Dashboard - 7.3 Resignation Details & Review - 7.4 Resignation Request Review & Action Management - 7.5 Resignation Progress Tracker - 7.6 Documents & Audit Trail - 8 Termination - 8.1 Create Termination Request - 8.2 Termination Ticket overview - 8.3 Termination Approval & Review Process - 8.4 Termination Progress Timeline - 9 Admin Section - 9.1 Master Configuration – Organization - 9.2 Zone, Region & Area Configuration - 9.3 Roles & permissions - 9.4 SLA Configuration & Escalation Management - 9.5 Email & Letter Templates Management - 9.6 Opportunity Management (Geography & Window Setup) - 10 F&F Case - 10.1 F&F Settlement Progress Timeline - 10.2 Department Responses - 11 Finance Dashboard - 11.1 Finance Dashboard Page - 11.2 F&F Settlement Module - 12 Dealer Persona - 12.1 Dealer Resignation - 12.2 Dealer Constitutional Change Management - 13 Non-Functional Requirements - 14 Technology Matrix - 15 Infra requirements & System Hygiene - 16 Not in scope ## 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.5 Dealer Resignation Access & Workflow Enhancements** - Enabled **dealer portal access** for initiating resignation requests and uploading required information. - Clarified that the **Legal team issues the Resignation Acceptance Letter** in all cases. - Expanded review authority to allow **ZBH, DD Lead, DD Head, and NBH** to **Send Back or** **Revoke resignation requests** , with communication routed through **Work Notes**. - Confirmed that **Full & Final (F&F) settlement is triggered strictly on the Last Working** **Day (LWD)** and not based on approval date. **1.1.6 Termination Workflow Governance Updates** - Clarified that **CEO is the final approving authority** for dealer termination cases. - Included **CCO and CEO** as approval authorities with **Approve / Hold / Reject** options. - Confirmed that the **Legal team issues termination letters only after CEO approval**. - Removed **dealer portal access** from termination workflows. - Extended **Send Back / Revoke** authority to **ZBH and DD Lead** for termination reviews. - Aligned **F&F trigger for termination** to occur strictly on the **Last Working Day (LWD)**. **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.2 Change Log – Dealer Self-Service Enablement **Version:** v2. **Section Impacted:** Section 12 – Dealer Portal (12.1 onwards) **Module:** Dealer Onboarding & Offboarding System **Change Type:** Dealer Feature Enablement (Section 12 onwards) **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** : 5 - Jan- 2026 **1.2.1 Introduction of Dealer Portal** - Introduced a **Dealer Portal capability** enabling onboarded dealers to initiate and track post-onboarding lifecycle requests through the portal. - Dealer actions are governed by **role-based access controls** , approval hierarchies, and audit mechanisms. **1.2.2 Dealer Resignation Enablement** - Enabled **dealer-initiated resignation requests** at outlet level via the portal. - Added structured resignation submission with: o Last Operational Date (Sales & Services) o Reason for resignation o Mandatory document readiness guidance - Enabled **dealer withdrawal option** for resignation requests **only until the case is** **pending with NBH**. - Clarified that **Legal team issues the Resignation Acceptance Letter** post approvals. - Ensured **F&F settlement is triggered based on Last Working Day (LWD)** and not approval date. - Restricted dealer portal access **post resignation closure**. **1.2.3 Dealer Relocation Request Enablement** - Enabled dealers to **initiate and track relocation requests** through a guided workflow. - Added support for: o Manual or map-based location entry o Distance calculation from existing location o Property type selection and expected relocation date - Introduced **document-driven relocation validation** , including statutory, legal, property, and infrastructure documents. - Implemented **multi-level approval workflow** with Work Notes–based communication and audit trail. - Ensured dealer has **view and upload access only** , with approvals retained by RE stakeholders. **1.2.4 Dealer Constitutional Change Enablement** - Enabled dealers to **initiate constitutional change requests** post onboarding. - Supported all approved constitution change scenarios: o Proprietorship, Partnership, LLP, and Private Limited permutations - Implemented **dynamic document requirement determination** based on target constitution. - Explicitly confirmed **no OCR-based document validation** ; all validations are manual and role-driven. - Ensured statutory compliance via Legal review before master data updates. **1.2.5 Post-Exit Access Control** - Enforced system rule to **revoke dealer portal access** once resignation or termination is completed. ## 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: - **Resignation Initiation** ``` The dealer can initiate the resignation process directly through the portal , submit the reason for exit, and track the status of the request across the defined review, clearance, and closure stages. ``` - **Relocation Request Submission** ``` The dealer can submit a relocation request in scenarios where there is an intent to shift the dealership from the current location to a new proposed location. The request is routed for internal feasibility assessment, validation, and management approval before execution. ``` - **Change in Constitution Request** ``` The dealer can initiate a Change in Constitution request to seek approval from RE management for ownership or structural changes within the dealership. Upon approval, the dealer may proceed with the legally compliant transition. ``` ``` Supported Change in Constitution scenarios include: ``` ``` o Proprietorship (Single Owner) → Partnership o Proprietorship → LLP (Limited Liability Partnership) o Proprietorship → Private Limited o Partnership → LLP o Partnership → Private Limited o Private Limited → LLP o Private Limited → Partnership ``` All dealer-initiated requests are subject to **defined validations, mandatory document submissions, role-based reviews, and approvals**. The dealer’s access is **restricted to initiation, document upload, and status visibility** , with **final decision-making authority retained by authorized internal stakeholders of RE** ### 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.2 Dealer Resignation – Process Flow Overview **4.2.1.1 Overview** ``` The Dealer Resignation Process manages the structured offboarding of a dealership initiated by the dealer. The process begins when a dealer formally submits their resignation via email to the Area Sales Manager (ASM) , after which the workflow transitions into the system-managed approval sequence. ``` ``` Dealer resignation requests are initiated by the dealer through the portal and subsequently reviewed and processed by Admin, Finance, Legal, and relevant business stakeholders. ``` ``` This flow ensures that each resignation is verified, discussed, and approved across all required levels — maintaining proper documentation, compliance, and traceability until the final Legal Acceptance Letter is issued. ``` **4.2.2 Step-by-Step Process Flow** ``` 4.2.2.1 Dealer Initiation ``` - The dealer submits a **formal resignation email** on the dealership’s official letterhead to the **ASM**. - The resignation reason must be clearly stated (e.g., personal, financial, business restructuring). - The **dealer is provided portal access** to initiate the resignation request directly through the system. The dealer submits resignation details, reason for exit, and proposed timeline via the portal, after which the request enters the internal review and clearance workflow. ``` 4.2.2.2 ASM Review ``` - The **ASM** reviews the dealer’s resignation request and supporting letter. - Uploads the **resignation email** and **dealer’s letterhead document** onto the portal. - Adds remarks summarizing the discussion and reason for resignation. - Forwards the request to **RBM + DD-ZM** for evaluation. ``` 4.2.2.3 RBM + DD-ZM Joint Evaluation ``` - The **Regional Business Manager (RBM)** and **Dealer Development Zonal Manager (DD-** **ZM)** review the uploaded documents. - Conduct a joint discussion with the dealer to confirm the intent and understand any issues. - Uploads the **Minutes of Meeting (MOM)** or discussion summary. - Adds comments and recommendations before forwarding to **Zonal Business Head** **(ZBH)**. - Actions available at this stage: o **Approve** → Send forward for next-level review o **Send Back for Clarification** → Returns to ASM o **Withdraw** → Cancels the request (with remarks logged) ``` 4.2.2.4 ZBH Review ``` - The **Zonal Business Head (ZBH)** reviews the resignation summary and all remarks. - Adds their comments and recommendations. - Forwards the request to **DD-Lead** through the system. - Worknote is updated automatically to reflect action and timestamp. - The resignation request is reviewed by authorized business stakeholders, including **RBM, ZBH, and DD-Head**. During the review stage, the **ZBH is authorized to** ``` Send Back or Revoke the resignation request for clarification or correction. Send Back actions are communicated to the dealer and internal teams through Work Notes , with mandatory remarks captured for traceability. ``` ``` 4.2.2.5 DD-Lead Review ``` - The **DD-Lead** consolidates all discussions, documents, and feedback. - Prepares a **Resignation Presentation** with recommendations and supporting data. - Uploads the presentation to the portal. - Forwards the case to **NBH** for final decision. - The resignation request is reviewed by the **DD-Lead and DD-Head**. At this stage, both roles are authorized to **Send Back or Revoke** the resignation request for clarification, correction, or reconsideration. **Send Back actions are communicated through Work** **Notes** , with **mandatory remarks** recorded for audit and traceability. ``` 4.2.2.6 NBH Final Approval ``` - The **National Business Head (NBH)** reviews the entire resignation dossier. - Adds final remarks with one of the following outcomes: o **Approve** → Case moves automatically to Legal for letter issuance. o **Send Back for Clarification** → Returns to DD-Lead or ZBH for revalidation. o **Hold** → Temporarily pauses the process pending further discussion. - Upon approval, the system triggers a **Worknote Notification** to DD-Lead, RBM, ZBH, and Finance teams. - The resignation request is reviewed by the **NBH** , who may **Approve, Send Back, or** **Revoke** the request based on business considerations. Any **Send Back or Revoke action** **must be accompanied by remarks recorded in Work Notes** , ensuring transparent communication and governance. ``` 4.2.2.7 Legal Acceptance Letter ``` - Once approved by **NBH** , the request is **auto-assigned to the Legal team**. - Legal verifies the uploaded resignation and issues a **Resignation Acceptance Letter**. - The letter is uploaded to the portal, visible to all relevant personas including **DD-** **Admin** and **DD-AM**. - Legal can also raise clarifications through worknotes if required. - Upon completion of all approvals, the **Legal team issues the official Resignation** **Acceptance Letter** and shares it with the dealer through authorized communication channels. ``` 4.2.2.8 DD-Admin Closure ``` - The **DD-Admin** downloads and shares the final **Resignation Acceptance Letter** with the dealer. - Marks the resignation as completed and triggers the **F&F (Full and Final) process** by forwarding the case to the Finance team. - The **Full & Final (F&F) settlement process is initiated only on the Last Working Day** **(LWD) of the dealership**. The system shall **enable and trigger the F&F workflow strictly** **based on the LWD date** , and **not based on the resignation approval date**. ### 4.3 Dealer Termination – Process Flow Overview ``` 4.3.1.1 Overview ``` ``` The Dealer Termination Process governs the structured offboarding of a dealership initiated internally by Royal Enfield due to operational, contractual, or ethical concerns. It ensures that any termination—whether due to working-capital issues, poor performance, or unethical practices —is investigated, documented, reviewed at multiple managerial levels, and legally validated before final execution. The process maintains full transparency and traceability through digital records, comments, and worknotes until the Termination Letter is issued and the Full & Final (F&F) settlement begins. ``` **4.3.2 Step-by-Step Process Flow** ``` 4.3.2.1 ASM – Case Initiation ``` - The **Area Sales Manager (ASM)** regularly visits dealers and records **Minutes of Meeting** **(MOM)** for performance or compliance concerns. - After two consecutive unsatisfactory commitments or escalations, the ASM initiates a **Termination Request** in the portal. - Fills all operational details (Dealer Code, LOI, LOA, Sales Data, etc.), selects a **Termination Category** (Working Capital, Performance, Unethical Practice), and uploads supporting documents (MOMs, commitments, dealer letters). - Submits the case to **RBM + DD-ZM** for review. ``` 4.3.2.2 RBM + DD-ZM Review ``` - The **Regional Business Manager (RBM)** and **Dealer Development Zonal Manager (DD-** **ZM)** jointly evaluate the case. - Conduct a meeting with the dealer and record fresh MOMs; upload dealer commitments on letterhead. - Provide remarks and supporting evidence. - Actions available: o **Approve** → Forward to ZBH o **Send Back for Clarification** → Returns to ASM with comments o **Withdraw** → Terminates workflow with justification ``` 4.3.2.3 ZBH Review ``` - The **Zonal Business Head (ZBH)** reviews the full chronology (ASM visits, RBM/DD-ZM remarks, uploaded MOMs). - Validates escalation authenticity and dealer communication record. - Adds remarks and forwards to **DD-Lead** for deeper review. - The termination request is reviewed by the **ZBH** , who is authorized to **Approve, Send** **Back, or Revoke** the termination request. **Send Back actions are communicated** **through Work Notes** , with **mandatory remarks** recorded for traceability. ``` 4.3.2.4 DD-Lead Review & Legal Assignment ``` - The **DD-Lead** cross-verifies case chronology with all stakeholders (ASM, RBM, ZBH). - Prepares a **Termination Presentation** summarizing facts, dealer history, and recommendations. - Assigns the case to **Legal Team** for inputs through the system (visible in worknotes). - The termination request is reviewed by the **DD-Lead** , who is authorized to **Send Back or** **Revoke** the termination request for clarification or reconsideration. All such actions require **mandatory remarks captured in Work Notes**. ``` 4.3.2.5 Legal Verification ``` - The **Legal Team** reviews documentation, ensures contractual breaches are well- supported, and checks all precedents. - May raise queries via **Worknotes** or **Send Back** the case to DD-Lead for clarification. - Once satisfied, forwards the verified case back to **DD-Lead** for next action. ``` 4.3.2.6 DD-Lead → DD-Head Review ``` - The **DD-Lead** attaches Legal’s feedback and forwards the case to **DD-Head** for strategic review. - **DD-Head** validates the case, evaluates impact, and presents it to **National Business** **Head (NBH)** for final business decision. ``` 4.3.2.7 NBH Evaluation ``` - The **NBH** reviews all documentation and Legal remarks. - May choose one of three actions: o **Go Ahead** → Approve for issuance of **Show Cause Notice (SCN)** o **Hold Decision** → Pause temporarily for further monitoring or negotiation o **Raise Query** → Sends back to DD-Lead for additional input ``` 4.3.2.8 Show Cause Notice (SCN) Issuance ``` - Upon NBH approval, the system triggers Legal to prepare and issue the **SCN**. - The **DD-Lead** formally shares the SCN with the dealer through **DD-Admin**. - Dealer replies to the SCN by email or letter, which **DD-Admin uploads** to the portal. - For termination cases, the **F&F settlement process is triggered only on the Last** **Working Day (LWD)**. The system shall **control the F&F trigger based on the LWD date** , irrespective of the termination approval date. ``` 4.3.2.9 Evaluation of Dealer Response ``` - The **DD-Lead** , **ZBH** , **RBM** , and **DD-Head** jointly review the dealer’s SCN response. - Uploads internal comments, Legal feedback, and recommendation for NBH’s final decision. ``` 4.3.2.10 NBH Final Decision ``` - The **NBH** reviews the compiled case with Legal advice and decides among: o **Approve Termination** → Moves to CEO/CCO for confirmation o **Reconsider** → Allow additional time or corrective action o **Reject** → Case closed without termination ``` 4.3.2.11 11. CEO & CCO Authorization ``` - **CEO** and **Chief Commercial Officer (CCO)** review the NBH-approved termination. - Provide authorization on the portal. - Once signed off, the decision becomes final. ``` 4.3.2.12 12. Legal Termination Letter ``` - The **Legal Team** generates the **Termination Letter** to the portal. - The letter is auto-visible to **DD-Lead** , **DD-Admin** , and **Finance**. - A system notification is triggered to all linked personas. ``` 4.3.2.13 13. DD-Admin Communication & F&F Trigger ``` - The **DD-Admin** shares the official **Termination Letter** with the dealer and field team. - Marks the case as “Terminated” in the portal. - Forwards the case to **Finance** for **Full & Final Settlement** initiation. - Updates the worknote with final remarks and due-date for settlement. ### 4.4 Dealer Full & Final (F&F) Settlement – Process Flow ``` 4.4.1.1 Overview ``` The **Full & Final (F&F) Settlement Process** governs the financial closure of a dealership following **Resignation** or **Termination**. It ensures that all financial obligations between Royal Enfield and the dealer — including **security deposits, recoveries, payables, and department-wise dues** — are transparently reconciled, verified, and documented before closure. **4.4.2 Step-by-Step Process Flow** ``` 4.4.2.1 F&F Initiation ``` - Triggered automatically once the **Resignation Acceptance Letter** or **Termination** **Letter** is uploaded by **Legal**. - The **DD-Admin** or **DD-Lead** initiates the F&F case in the **Finance Dashboard** , which creates a unique **FNF Case ID** linked to the dealer code. - The system auto-fetches dealer details, associated documents, resignation/termination date, and due dates. - Notification is sent to the **Finance Team** and all functional departments to begin the clearance process. ``` 4.4.2.2 Department-wise Response Collection ``` - The system automatically prompts all mapped **functional departments (16 in total)** to submit their clearance inputs — including NOC, payables, recoveries, and remarks. - Each department updates: o Financial dues (if any) o Clearance confirmation (NOC) o Supporting document uploads (e.g., debit note, invoice copy) - The system dynamically updates progress (e.g., _12/16 Departments Responded_ ) with color-coded indicators: o 🟢 **No Dues** – Cleared ``` o 🔴 Dues Pending – Outstanding financial liability o ⚪ Pending – Awaiting department input ``` - SLA-based reminders are auto-triggered for pending responses nearing the deadline. ``` 4.4.2.3 Finance Summary Consolidation ``` - Once all departments respond, the **DD-Admin Team** consolidates inputs into the **Final** **F&F Summary Sheet** , which consists of: o **Payables to Dealer** (e.g., refundable deposits, reimbursements) o **Receivables from Dealer** (e.g., outstanding invoices, recoveries) o **Deductions** (policy penalties, non-compliance adjustments) - The system automatically calculates: - Net Settlement = Total Payables – Total Receivables – Total Deductions - Finance reviews and adjusts entries as needed, attaching relevant proofs for transparency. - Status updates to _Finance Summary Prepared_ once complete. ``` 4.4.2.4 Internal Review & Clarification ``` - The **Finance Team** may use the **Work Note** section to raise clarifications to **DD-** **Lead** , **Legal** , or concerned departments. - If discrepancies exist (e.g., mismatched values or missing NOCs), the case remains _Under_ _Clarification_ until resolved. - Once validated, Finance locks the summary for further edits. ``` 4.4.2.5 Dealer Discussion & Acknowledgment ``` - The **Finance Team** , along with **Legal** and **DD-Lead** , discusses the settlement summary with the dealer. - Dealer acknowledgment is captured either via written confirmation or attached email communication. - The case then proceeds for **Final Finance Approval**. ``` 4.4.2.6 Final Finance Approval & Payment Processing ``` - The **Finance Team** reviews the approved summary and enters payment or recovery details: o **Transaction Type:** RTGS / NEFT / Cheque o **Transaction ID & Date** o **Bank Name & Account Details** (auto-fetched from dealer profile) o **Settlement Remarks** - Finance takes one of three actions: ``` o Approve Settlement → Marks the case as “Finance Approved.” o Request Clarification → Sends query to DD-Lead or Admin. o Reject Summary → Returns for re-verification. ``` - Upon approval, notifications are sent to DD-Admin and Legal for record update. ``` 4.4.2.7 F&F Completion & Closure ``` - Once approved, the case is automatically marked **Completed** , and the **Finance** **Dashboard** updates status as _F&F Closed_. - The **Settlement Proof** (e.g., payment confirmation or recovery adjustment) is uploaded by Finance. - The **DD-Admin** communicates official closure to the dealer and archives all artefacts. - System triggers final alerts to DD-Lead, NBH, and Legal confirming completion. - The case is archived in the **Audit Trail** for future reference. ### 4.5 Finance Team – Process Flow ``` 4.5.1.1 Overview ``` The **Finance Team Process Flow** governs all financial activities related to dealer lifecycle management — from **security deposit validation at onboarding** to **final settlement at resignation or termination**. It ensures complete financial traceability, proper verification of payments, and compliance with Royal Enfield’s financial governance standards. The process flow integrates with **Admin, Legal, Dealer Development (DD)** , and **Departmental Modules** , ensuring accurate financial updates and timely closure of all financial transactions. **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. ``` o The verified payment data is stored permanently in the dealer’s financial profile for audit and reference. ``` ``` 4.5.2.2 Financial Summary Preparation ``` - **Action:** Once departmental inputs are received, Finance consolidates all data into the **F&F** **Summary Sheet**. - **System Steps:** o Segregates entries under: ▪ **Payables to Dealer** (e.g., refundable deposits, reimbursements) ▪ **Receivables from Dealer** (e.g., outstanding payments, penalties) ▪ **Deductions** (e.g., policy recoveries, warranty holdbacks) o The system auto-calculates: o Net Settlement = Total Payables – Total Receivables – Deductions o Finance validates each record, uploads supporting documents (receipts, invoices, credit notes), and adds remarks. - **Outcome:** The computed **Net Settlement Amount** is reflected in the dashboard, categorized as _Payable to Dealer_ or _Recoverable from Dealer_. ``` 4.5.2.3 Internal Clarification & Approval ``` - **Action:** Finance initiates clarification rounds with departments or DD-Lead for mismatched data. - **System Steps:** o Uses the **Work Notes** section for comments, tagging users like _@DD-_ _Lead_ , _@Legal_ , or _@Admin_. o Tracks status as _Pending Clarification_ until resolved. o After reconciliation, Finance locks the summary and updates case status to _Ready for Approval_. ``` 4.5.2.4 Final Review & Dealer Confirmation ``` - **Action:** Finance conducts an internal review of the consolidated settlement and initiates a financial discussion with the dealer. - **System Steps:** o Reviews summary details on-screen with Legal and DD-Lead. o Records dealer’s acknowledgment via Work Note or attached email confirmation. o Once confirmed, proceeds to payment verification. ``` 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**. ``` 4.5.2.6 F&F Completion & Closure ``` - **Action:** Finance reviews all entries, confirms ledger reconciliations, and marks case as **Completed**. - **System Steps:** o Locks financial data and supporting artefacts. o Status changes to _Closed – F&F Completed_. o Final confirmation sent to all stakeholders — DD-Lead, NBH, DD-Head, Legal, and DD-Admin. o Finance Dashboard updates counters under “Completed Cases.” ## 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.2 SSO Login **6.2.1 Functionality Scope** The **User Authentication & Secure Login** module ensures controlled access to the **Dealer Onboarding and Offboarding System** through **Royal Enfield’s Single Sign-On (SSO) bridge** integrated with **Active Directory (AD)**. This guarantees that only **authorized RE employees** can access the platform while maintaining identity consistency across all RE applications. The feature upholds organizational standards of **security, traceability, and role- based access control (RBAC)**. **6.2.2 Width** - The login interface is the **entry point** to the system and is accessible via the internal RE portal or direct system URL. - It contains the following key fields and actions: o **Email Address** (RE domain-based ID) o **Password** (validated via Active Directory) o **Remember Me** (optional session retention) o **Forgot Password** (redirects to RE’s password reset service via SSO) - Once authenticated, users are redirected to their **personalized dashboard** based on role and access level defined in RBAC. **6.2.3 Depth** - The system leverages **RE’s enterprise SSO framework** for identity validation and token- based session management. - User credentials are not stored within the application; authentication tokens are validated through **Active Directory** integration. - Upon successful login, the system fetches user metadata (name, department, role, region, and zone) to determine module visibility and permissions. - **Role-Based Access Control (RBAC)** defines feature-level authorization for each user category (e.g., DD-Admin, DD-ZM, RBM, Finance, Legal). - Unauthorized users or non-RE email domains are denied access and redirected to an error page stating: _“Access restricted to authorized Royal Enfield personnel only.”_ - User sessions are automatically logged out after 30 mins of inactivity period **6.2.4 Flow** ``` Step Source → Destination Description / Action 1 User → Login Screen User enters RE email ID and password. ``` ``` 2 ``` ``` Login Screen → SSO Bridge Credentials validated via Active Directory.^ 3 SSO → System Authentication token passed back to the application. 4 System → RBAC Engine User role and permissions are identified. ``` ``` 5 System → User Dashboard User redirected to personalized dashboard based on access level. ``` **6.2.5 Personas-Wise Accessibility & Visibility** ``` Persona Accessibility Visibility Scope All RE Employees Login access via SSO bridge ``` ``` Limited to assigned modules post-login ``` ``` External Users (Dealers, FDD Partners) ``` ``` No direct access via RE SSO ``` ``` Access provided through secure external login URLs when applicable ``` **Dependency** - SSO implementation guide and sample users are required. ### 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. ``` 6.22.3.5 Security & Data Integrity ``` - Audit logs are **read-only and non-editable** to preserve authenticity. **6.22.4 Personas-Wise Accessibility & Visibility** ``` Persona Accessibility Visibility Scope RE User except FDD ``` ``` Full access to view all logs and export reports. Complete visibility and export control. System (Automation Layer) ``` ``` Automatically records all workflow events and triggers background logging for system actions. ``` ``` Background operation. ``` ## 7 Dealer Resignation The **Dealer Resignation** process enables an existing Royal Enfield dealer to formally initiate their intent to discontinue the dealership through a structured and transparent workflow. This process captures the dealer’s resignation details, reasons for exit, and proposed timeline, ensuring all associated departments — including **DD-Admin, DD-** **Head, Finance, Legal, and Regional Teams** — are informed and involved in the validation and clearance stages. Each resignation request undergoes systematic review, covering asset recovery, financial reconciliation, documentation verification, and contractual obligations before final approval and closure. ### 7.1 Dealer Resignation Request (Initiation) **7.1.1 Functionality Scope** The **Dealer Resignation Request** process begins when a dealer formally communicates their intent to resign via an **official email** to ASM. Once received, the **DD-ASM** initiates the resignation process in the system by creating a digital record using the _Create Resignation Request_ form. The form captures critical dealership, operational, and contextual information — such as business constitution, sales data, and closure type — ensuring that the request is documented in a structured, traceable, and standardized manner. This process establishes a single source of truth for all resignation-related data, facilitating transparent coordination among **DD-Head, Finance, Legal, and Regional Teams** for subsequent review and action. Dealer can login exclusively and can only initiate the Resignation request. The **Dealer Resignation Request is initiated by the dealer through the portal** , providing a structured mechanism to formally submit the intent to discontinue the dealership. The dealer captures resignation details, reason for exit, and the proposed effective date. Upon submission, the request is routed to the internal stakeholders for review, validation, and subsequent clearance processes. The **dealer logs into the portal and initiates the resignation request** by submitting the required details and supporting information. **7.1.2 Width** - Accessible exclusively to **DD-ASM** through the **“Create Resignation Request”** interface. - Includes the following mandatory and optional input fields: o **Dealer Code** (it will be fed to SAP API to pull details.) o **Inauguration** , **LOA** , and **LOI Dates** (Will be fetched from system DB, if available) o **Last 6 Months Sales** o **Number of Dealerships / Studios** o **Constitution** (Proprietorship, Partnership, LLP, Pvt. Ltd., etc.) o **Dealership Type** (Main, Satellite, Studio, etc.) o **Type of Closure** (Voluntary, Business Transfer, Termination, etc.) o **Format Category** (Urban, Rural, etc.) o **Dealer Scorecard Band** o **Resignation Reason** (brief summary) o **Dealer Voice** (detailed justification or remarks from dealer’s email) o **Upload Document** (resignation email copy or supporting documents) - **Buttons:** o **Submit Request:** validates data and triggers routing to the next stage of review. o **Cancel:** exits without saving. **7.1.3 Depth** - Upon submission by **DD-Admin** , the system performs the following o Validates the **Dealer Code** against the dealership master from SAP API to be provided by RE o Generates a unique **Resignation Request ID** and logs submission details (timestamp, user, and role). o Stores the uploaded resignation email or document in the **Central Document** **Repository** for reference. o Automatically notifies the **DD-Head** and relevant stakeholders that a new resignation has been logged. o Marks the case status as **“Resignation Initiated”** in the workflow tracker. o He will also upload the resignation PPT which is build off the system. **7.1.4 Personas-Wise Accessibility & Visibility** ``` Persona Accessibility Visibility Scope Dealer / Applicant ``` ``` Sends official resignation email to Royal Enfield. The dealer is provided portal access to upload resignation-related documents and responses during the applicable workflow stages. ``` ``` Email communication only (no direct system access). ``` ``` For termination cases, dealer upload access is restricted as per defined governance rules. DD-Admin/DD- ASM ``` ``` Creates resignation request in system, uploads dealer’s email, validates data, and submits for approval. ``` ``` Full access for initiation. ``` ``` DD-Head / ZBH / NBH ``` ``` Receives system notification upon submission; can view request details and attached resignation communication. ``` ``` Read-only visibility at initiation stage. ``` ``` System (Automation) ``` ``` Validates dealer code, generates request ID, logs submission details, and triggers workflow routing. ``` ``` Background operation. ``` ### 7.2 Resignation Management Dashboard **7.2.1 Functionality Scope** The **Resignation Management Dashboard** serves as the central workspace for monitoring and managing all dealer resignation requests initiated within the system. It provides a consolidated view of active, pending, and completed cases, enabling stakeholders such as **DD-Admin, ASM, DD-Lead, ZBH, NBH, and Legal Teams** to review progress, take required actions, and ensure compliance with the defined offboarding workflow. The **ZBH can review resignation requests and perform Send Back or Revoke actions** prior to final approval. Each action requires **mandatory remarks** and is recorded against the resignation case. RBM, **ZBH, DD-Lead, DD-Head, and NBH** can review resignation requests and are authorized to **Send Back or Revoke** requests at their respective stages. All such actions require **mandatory remarks** and are logged for audit purposes. **7.2.2 Width** - Displays a **summary header** with following key counters: o **All Requests:** Total number of resignation requests recorded. o **Open:** Requests currently under review or action. o **Completed:** Finalized resignations where closure is approved. o **Requires Your Action:** Highlights cases awaiting action from the logged-in user. - Shows a **list view** of all resignation requests with the following details: o **Request ID (e.g., RES-001)** o **Dealer Name, Dealer Code, and Location** o **Format Category** (A+, A, B, etc.) o **Dealership Type** (Main, Studio, etc.) o **Reason for Resignation** o **Current Stage** (e.g., ASM Review, DD-Lead Review, NBH Approved, Legal) o **Submitted On** (auto-captured timestamp) - Action options: o **View Details:** Opens complete resignation record and attached documents. o **Create Resignation Request:** Accessible only to **DD-Admin** for entering new requests (from dealer emails). - Filter tabs: o **All Requests** , **Open** , **Completed** **7.2.3 Depth** - **Workflow Synchronization:** Each resignation request dynamically updates its stage label (e.g., _ASM Review_ , _DD-Lead Review_ , _NBH Approved_ ) based on workflow transitions. - **Notification Logic:** o The assigned reviewer (ASM, DD-Lead, or NBH) receives automated alerts for action items. o Status changes trigger notifications to the next role in sequence. **7.2.4 Personas-Wise Accessibility & Visibility** ``` Persona Accessibility Visibility Scope DD-Admin/DD-ASM Can create new resignation requests, view all regional cases, and track progress. ``` ``` Full access within Area. ``` ``` ASM / DD-Lead Can review, comment, and forward resignation requests to next approver. ``` ``` Assigned requests only. ZBH / NBH / Legal / Finance ``` ``` Can view status, add remarks, and take action at their respective workflow stage. ``` ``` Role-based access by stage. System (Automation) ``` ``` Updates request stages, triggers notifications, and logs all workflow events. ``` ``` Background process. Regional Business Manager (RBM) ``` ``` The RBM reviews and validates dealer lifecycle requests , and has review, send back, and escalation authority as per workflow stage. ``` ### 7.3 Resignation Details & Review **7.3.1 Functionality Scope** The **Resignation Details & Review** module provides a comprehensive view of all dealer resignation information captured during initiation. It enables authorized reviewers to validate dealer data, evaluate the reason and context for resignation, and take appropriate workflow actions such as **Approval, Withdrawal, Send Back, or Push to Full & Final (F&F)**. The screen consolidates dealer master data, operational metrics, and resignation specifics, ensuring reviewers have complete visibility before making decisions. **7.3.2 Width** - **Header Actions:** o **Approve:** Marks resignation as validated and forwards it to the next workflow stage (DD-Head / NBH). o **Withdrawal:** Used if the dealer retracts the resignation request or if withdrawal is approved internally. o **Send Back:** Returns the request to DD-Admin for correction or additional details. o **Push to F&F:** Moves the case to the **Full & Final Settlement** process after all approvals are secured. o **Assign User:** Allows reallocation of review responsibility to another internal user. o **View Work Notes:** Opens the shared comment thread for internal collaboration and tagging. - **Tabs:** o **Details** – Displays complete resignation information and dealer data. o **Progress** – Shows stage-wise workflow journey and current reviewer. o **Documents** – Lists uploaded resignation documents and correspondence. o **Audit Trail** – Records every action, decision, and timestamp for traceability. **7.3.3 3. Depth** - **Information Segments:** o **Request Information:** Pull dealer master details such as Dealer Code, GST, Address, Domain & Service Codes, City Category, and Dealership Name. o **Operational Details:** Displays dealership metrics including inauguration and LOA dates, number of outlets, last six-month sales, business constitution, format category, and dealer scorecard band. o **Resignation Details:** Summarizes the **Resignation Reason** and **Dealer Voice** **(Customer Description)** derived from the dealer’s email submission. **7.3.4 4. Personas-Wise Accessibility & Visibility** ``` Persona Accessibility Visibility Scope DD-Admin Read-only at this stage; may receive “Send Back” tasks for correction. ``` ``` Region-specific requests. ``` ``` ASM / DD-Lead / DD- Head / ZBH / NBH ``` ``` Can review, approve, withdraw, or forward resignations to next stage; can add remarks and push to F&F. ``` ``` Requests assigned to their hierarchy. ``` ``` System (Automation) Logs workflow actions, timestamps, and user activity; triggers stage transitions and notifications. ``` ``` Background operation. ``` ### 7.4 Resignation Request Review & Action Management **7.4.1 Functionality Scope** The **Resignation Progress Timeline** provides a transparent, stepwise view of the dealer resignation workflow — from initial submission to the issuance of the final **Acceptance Letter**. Since the **Dealer does not have portal access** for resignation, the process starts through an **email submission to the Area Sales Manager (ASM)** , followed by progressive reviews and comments at multiple organizational levels. Each approver in the chain can perform one of three key actions — **Approve** , **Send Back for Clarification** , or **Withdraw** — with remarks captured in **Work Notes** for audit and traceability. Once approved by the **National Business Head (NBH)** , the request automatically routes to the **Legal Team** for the issuance of the acceptance letter, visible to both the DD Admin and DD-ASM. The **dealer is provided portal access** to **upload resignation-related documents and responses** during the applicable workflow stages. For termination cases, **dealer upload access is restricted** as per defined governance rules. **7.4.2 Width** ``` 7.4.2.1 Stage-wise Flow Stage Responsible Role ``` ``` System / Process Description ``` 1. Dealer Resignation Submission ``` Dealer → via Email to ASM ``` - Dealer submits resignation via official email and signed letterhead. - No direct portal access. - ASM receives and verifies authenticity. 2. ASM Review DD-ASM • Uploads resignation email and presentation (e.g., _Sample resignation.pptx_ ) to portal. - Adds remarks summarizing dealer’s reason and operational background. - Forwards case to **RBM + DD-ZM** for evaluation. 3. RBM + DD-ZM Review ``` RBM & DD-ZM • Conduct joint discussion with dealer to understand cause and alternatives. ``` - Uploads discussion notes and remarks in **Work Notes**. - The final output will be submitted as Approve, Withdrawal or send back. - Has three action options: - **Approve:** Forwards case to ZBH for further review. - **Send Back:** Requests ASM to provide additional details or clarifications (remark mandatory). - **Withdraw:** Stops process if dealer withdraws or case found invalid (remark mandatory). 4. ZBH Review Zonal Business Head - Reviews RBM + DD-ZM inputs and validates zonal implications. - Adds comments in **Work Notes** and forwards to **DD Lead**. - Can perform **Approve** , **Send Back** , or **Withdraw** actions. 5. DD Lead Review ``` DD Lead • Prepares a formal Resignation Presentation PPT summarizing business rationale, sales history, dealer feedback, and proposed recommendation. ``` - Uploads the presentation and comments to the portal. - Approves and shares with **NBH** for final decision. 6. NBH Approval National Business Head - Reviews all inputs and puts **final decision remarks** in Work Notes. - On approval, system triggers notification to **DD Lead, ZBH, Zonal Team, Business Zonal Manager, and F&F**. - Automatically routes the case to **Legal Team** for Acceptance Letter issuance. 7. Legal Review & Acceptance Letter ``` Legal Team • Prepares and uploads Resignation Acceptance Letter on portal. ``` - Can raise queries in Work Notes if required. - Uploaded document is visible to **DD-Admin** and **DD-** #### ASM. - Legal completion closes workflow for the request. 8. DD Admin & ASM Notification ``` DD Admin + DD-ASM ``` - DD Admin reviews the uploaded acceptance letter. - Shares with respective **ASM (Field Team)** to communicate official closure to the dealer. **7.4.3 3. Depth** - **Action Modes Across Stages:** o **Approve:** Advances the resignation request to the next level of the workflow. _Example:_ “Reviewed with dealer and validated. Forwarding to ZBH for next stage.” o **Send Back:** Returns to the previous user or ASM for clarifications. _Example:_ “Incomplete documentation. Dealer statement on financials missing.” o **Withdraw:** Ends the process if dealer withdraws voluntarily or management disapproves continuation. _Example:_ “Dealer requested withdrawal of resignation via email dated 15-Oct.” - **Audit and Transparency:** o All actions (including remarks, uploads, and timestamps) are auto-captured in **Work Notes** and the **Audit Trail**. o Every document and PPT uploaded (e.g., _Sample resignation.pptx_ ) is linked to its stage for version tracking. - **System Automation:** o NBH approval automatically triggers Legal assignment. o SLA tracking continues at each step; escalation is logged in Work Notes if delayed. o Notifications are sent to all relevant stakeholders upon approval, send-back, or withdrawal. **7.4.4 Worknotes** The **Work Notes** feature acts as the central communication and collaboration thread within the resignation workflow. It captures all user interactions, remarks, and system- triggered updates in a structured, time-stamped format. Each stakeholder — from ASM to NBH and Legal — uses Work Notes to record discussions, queries, clarifications, and final decisions related to the resignation case will be submitted from Approval, Withdrawal or send back action. **7.4.5 Personas-wise Accessibility & Visibility** ``` Role / Persona Responsibilities System Access & Actions ``` ``` Dealer (External) Submits resignation via email on company letterhead. ``` ``` No portal access; communicates via email only. DD-ASM (Area Sales Manager) ``` ``` Initiates workflow by uploading resignation documents, adding dealer background, and forwarding case. ``` ``` Create, view, and comment rights. ``` ``` RBM + DD-ZM Conduct discussion with dealer, upload remarks, and validate reasons. ``` ``` Approve, Send Back, Withdraw, upload documents. ZBH (Zonal Business Head) ``` ``` Validate business impact; forward decision to DD Lead. ``` ``` Approve, Send Back, Withdraw rights. DD Lead Consolidates inputs; prepares final presentation with recommendations for NBH. ``` ``` Approve, Send Back, Withdraw, upload presentation. NBH (National Business Head) ``` ``` Takes final decision; puts remarks in system; triggers Legal action. ``` ``` Final Approval rights. ``` ``` Legal Uploads Resignation Acceptance Letter ; communicates queries in Work Notes. ``` ``` Upload and comment rights; visible to DD Admin & ASM. DD Admin Reviews uploaded acceptance letter; shares with ASM for final dealer communication. ``` ``` Read & Download access. ``` ``` System (Automation) ``` ``` Triggers notifications, maintains SLA counters, logs Work Notes & Audit history. ``` ``` Automated access only. ``` ### 7.5 Resignation Progress Tracker **7.5.1 Functionality Scope** The **Progress** section provides a stage-wise, visual representation of the entire dealer resignation workflow. It enables authorized users to track each approval checkpoint — from **request submission** through **multi-level review** to **final legal acceptance**. Every stage dynamically updates based on workflow actions such as _Approve_ , _Send Back_ , or _Withdraw_ , with complete traceability of remarks, uploaded documents, and timestamps. This ensures full transparency, accountability, and operational consistency across all hierarchical levels. **7.5.2 Width** - Presents a **chronological timeline** of the resignation process, beginning with _Request Submitted_ and concluding with _Legal – Resignation Letter_. - Each stage displays **status indicators** (Pending, In Progress, Approved, or Withdrawn) along with the **responsible reviewer role**. - Shows the **number of documents uploaded** at each stage, with direct view/download options. - Allows reviewers to perform three key actions — _Approve_ , _Send Back_ , and _Withdraw_ — with remarks made mandatory. - If a request is **Sent Back** , it automatically reverts to the previous stage, recording remarks in **Work Notes** and notifying the concerned user. - On **Withdrawal** , the timeline is locked and marked _Closed – Withdrawn_ for historical reference. - Once **NBH** provides final approval, the request is automatically assigned to **Legal** for acceptance letter issuance. - The **Legal stage** finalizes the process upon letter upload, marking the case _Completed_ and notifying DD-Admin and field hierarchy. **7.5.3 Depth** - Each stage retains all **remarks, approvals, timestamps, and supporting documents** for complete traceability. - Integrates seamlessly with **Work Notes** and **Audit Trail** , ensuring real-time visibility of all communications and escalations. - Supports SLA-driven reminders and escalations that reflect directly in the timeline view. - All uploaded documents (emails, resignation PPT, acceptance letter) remain permanently mapped to their respective stages. - Once the resignation is finalized, historical data stays accessible for compliance and audit review. **7.5.4 Personas-wise Accessibility & Visibility** ``` Persona / Role ``` ``` Access Level Permissions / Actions Visibility ``` ``` DD-ASM / AM ``` ``` Area Level Uploads the dealer’s resignation email and supporting PPT; initiates forwarding for ASM review. ``` ``` Can view current stage and all preceding remarks/documents. ``` ``` RBM + DD- ZM ``` ``` Regional / Zonal Level ``` ``` Reviews and discusses resignation with the dealer; provides comments and forwards to ZBH; can send back or withdraw. ``` ``` Can view all area-level details, remarks, and uploaded documents. ``` ``` ZBH Zonal Business Head ``` ``` Reviews RBM and DD-ZM inputs; adds zonal remarks and forwards to DD-Lead for review. ``` ``` Can view complete case details up to current stage. ``` ``` DD-Lead National Coordination Level ``` ``` Consolidates information; prepares resignation presentation with recommendations; forwards to NBH. ``` ``` Can view entire history, remarks, and document trail. ``` ``` NBH National Business Head ``` ``` Reviews final presentation; adds decision remarks; approves resignation for legal processing. ``` ``` Can view and comment on all prior approvals and documents. Legal Post-Approval Level ``` ``` Uploads the Resignation Acceptance Letter and closes the case; can add queries via Work Notes. ``` ``` Gains access only after NBH approval; visible to DD- Admin upon upload. ``` ``` DD-Admin Administrative Level ``` ``` Reviews and distributes acceptance letter internally; ensures completion record update. ``` ``` Can view full progress history and all final documentation. ``` ``` All Higher Roles (Read- only) ``` ``` Oversight Access for viewing status, remarks, and uploaded files for compliance or reporting. ``` ``` View-only access for all resignation-related data. ``` ### 7.6 Documents & Audit Trail **7.6.1 Functionality Scope** The **Documents** and **Audit Trail** sections collectively ensure complete transparency and traceability across the resignation workflow. The **Documents** tab serves as a centralized repository of all artefacts submitted or generated during the process — including resignation letters, presentations, communications, and acceptance letters. The **Audit Trail** automatically captures every workflow action, recording who performed it, what was changed, and when, ensuring full accountability and data integrity. **7.6.2 Width** - Allows upload and viewing of all resignation-related documents with type, uploader, and upload date clearly listed. - Supports restricted document viewing to authorized personas with download control. - Provides versioned tracking of uploaded artefacts for compliance. - The **Audit Trail** logs every stage transition, approval, comment, or document addition with precise timestamps. - Automatically records system-triggered events such as SLA reminders or email notifications. **7.6.3 Depth** - Each document remains linked to its respective workflow stage and accessible through the **Progress Timeline**. - All actions — _Approve_ , _Send Back_ , _Withdraw_ , _Upload_ , and _Assign_ — are recorded for traceability. - The system maintains an immutable historical log for governance and audit purposes. - Entries in the Audit Trail display both user-driven and automated actions to ensure comprehensive visibility. **7.6.4 Personas-wise Accessibility & Visibility** ``` Persona / Role ``` ``` Access Level Visibility & Permissions ``` ``` DD-ASM / AM ``` ``` Area Level Can upload resignation email and initial supporting documents which is the resignation PPT RBM + DD- ZM ``` ``` Regional / Zonal Level ``` ``` Can view all uploaded artefacts and upload discussion or dealer communication documents. ZBH Zonal Head Can review attached documents and see all prior uploads with remarks. DD-Lead National Coordination ``` ``` Can upload resignation presentation and verify uploaded PPT files for completeness. NBH National Business Head ``` ``` Can view all documents and approval history before finalizing decision. Legal Post-Approval Level Uploads final Acceptance Letter , visible to DD-Admin and field teams. DD-Admin Administrative Oversight ``` ``` Has full view and download access to all documents and audit logs for closure verification. ``` ## 8 Termination A **Dealer Termination** process is initiated when a dealership’s continuation is deemed non-viable due to business, financial, or ethical reasons. The termination may arise from three primary causes — **working capital inadequacy** , **continued underperformance** , or **unethical practices**. Cases involving working capital or performance issues follow a structured review and approval process, allowing the concerned dealer to provide clarification and supporting data before final decision. However, any instance of **unethical practice** — including fraud, policy breach, or reputational risk to the brand — results in **immediate termination**. All termination cases are documented within the system, with remarks, evidence, and approval trails maintained for audit and compliance verification. ### 8.1 Create Termination Request **8.1.1 Functionality Scope** The **Create Termination Request** form enables authorized users such as **DD-Lead** , **DD-Admin** , or **ASM** to initiate a termination case within the system. The form captures comprehensive dealership details including operational timelines, format type, constitution, performance data, and financial indicators. It also specifies the **Termination Category** (e.g., Working Capital, Performance Issue, or Unethical Practice), supported by descriptive justification and relevant documentation. The request forms the starting point of the digital termination workflow and ensures that all necessary contextual data and artefacts are available for subsequent reviews and escalations. **8.1.2 Width** - Allows creation of new termination requests by entering **Dealer Code** , operational details, and financial data. - Captures **Termination Category** and **Description** for clarity on grounds of termination. - Supports upload of supporting artefacts such as MOMs, dealer commitments, or financial statements. - Automatically records creator and timestamp for traceability. **8.1.3 Depth** - Integrates directly with the **Progress Timeline** , displaying real-time status updates across levels. - Each submission auto-generates an internal case ID linked to the dealer code for tracking. - Supports structured escalation logic based on the **Termination Category** — standard route for working capital/performance cases, immediate escalation for unethical practices. - Maintains versioned records for every document uploaded at creation stage. **8.1.4 Personas-wise Accessibility & Visibility** ``` Persona / Role Access Level Visibility & Permissions ASM / DD-AM Area Level Can initiate termination requests, upload MOMs and dealer commitments. RBM + DD-ZM Regional / Zonal Level ``` ``` Can view request details and validate information before escalation. ZBH Zonal Head Reviews initial request data, comments on justification, and forwards to DD-Lead. DD-Lead / DD- Admin ``` ``` National Coordination ``` ``` Can initiate, review, and forward requests; validates completeness and assigns to Legal if required. Legal Review Level Can view dealer details and supporting documents for legal evaluation. NBH National Business Head ``` ``` Can view the entire request summary before decision and closure approval. ``` ### 8.2 Termination Ticket overview **8.2.1 Functionality Scope** The **Details View** provides a consolidated summary of all key information related to the dealer under review. It includes dealership codes, operational history, financial performance, and termination-specific parameters. This enables reviewers at every level—whether ASM, ZBH, or Legal—to quickly assess background context and validate evidence before taking action. The interface also displays the current workflow stage and offers in-screen options to **Approve** , **Withdraw** , or **Send Back** the request with remarks, ensuring traceable and reason- based decisions. **8.2.2 Width** - Displays complete dealer profile: code, name, location, and GST details. - Shows operational data: inauguration date, LOA, LOI, format, constitution, and last six-month sales. - Captures termination-specific data: **Termination Category** , reason, and case severity (e.g., “High”). - Provides workflow action buttons— **Approve** , **Withdraw** , **Send Back** —with mandatory remarks input. - Integration with Work Notes for contextual communication and escalation traceability. **8.2.3 Depth** The **Detail Tab** serves as the **central operational dashboard** for viewing all dealer, operational, and termination-related data within a single, structured interface. It merges static dealer master information with dynamic workflow inputs and uploaded artefacts, ensuring contextual visibility for all stakeholders. ``` 8.2.3.1 Components & Functional Behavior ``` - **Dealer Information (Owner: DD-Admin / System Integration Layer)** Displays master data pulled from the Dealer Master table — including **Dealer Code,** **Name, Address, GST, Domain Name, City Category, Sales Code, Service Code, and GMA** **Code**. o Synced automatically from RE’s **Dealer Database (Master Registry)**. o Read-only for all personas except system admin for data correction requests. o Enables search and cross-referencing across termination, resignation, and onboarding records. - **Operational Details (Owner: DD-Lead / Workflow Engine)** Highlights the dealership’s business health indicators and structural data, including **LOA,** **LOI, Inauguration Date, Constitution Type, Dealership Type, Format Category, Dealer** **Score Card Band, and Last Six-Month Sales**. o Pulled dynamically from the Sales & Performance Module. o Reflects the most recent sales cycle, ensuring leadership sees live performance metrics during termination decision-making. o Editable only by DD-Lead or authorized DD-Admin prior to case lock. - **Termination Details (Owner: DD-Lead / DD-ZM / Legal)** Captures case-specific details such as **Termination Category, Reason Description, and** **Attachments**. o Termination Category includes options like _Working Capital Issues, Performance_ _Shortfall, Breach of Agreement, or Unethical Practices_. o Documents uploaded here are visible to all reviewers across the approval chain, maintaining transparency. o Legal team references this section while framing the **Show Cause Notice (SCN)** or final termination letter. - **Workflow Actions (Owner: Workflow Engine / DD-Lead)** Displays **Approve, Withdraw, and Send Back** controls based on role permissions. o Triggers automated workflow transitions and real-time updates in **Progress** **Timeline** and **Audit Trail**. o Any action logs mandatory remarks under “Communication & Notes” with timestamp and user identity. o Permissions vary per role: ``` ▪ ASM, RBM: Can only comment or escalate. ▪ ZBH, DD-Lead, NBH: Can approve or send back. ▪ Legal: Can finalize after NBH approval. ``` - **Document Management Section (Owner: DD-Admin / Legal)** Repository displaying all uploaded evidence or reports associated with the termination. o Documents listed by **name, type, uploader, and date**. o Supports inline viewing (no download needed) for internal confidentiality. o File retention policy aligns with RE’s compliance standards (minimum 7 years). - **Audit Trail (Owner: Workflow Engine / System Log)** Chronologically records every action taken within the termination case — including user, timestamp, and nature of change. **8.2.4 Personas-wise Accessibility & Visibility** ``` Persona / Role Access Level Visibility & Permissions ASM / DD-AM Area Level Can initiate and upload dealer MOMs and commitment records. RBM + DD-ZM Regional / Zonal Level ``` ``` Review dealer details, validate termination rationale, and escalate with remarks. ZBH Zonal Business Head ``` ``` Approves or returns the case with comments; can forward to DD-Lead. DD-Lead / DD- Admin ``` ``` National Coordination ``` ``` Validate details, review documents, assign to Legal, or push for F&F after NBH approval. Legal Legal Level Review dealer information, validate grounds, and issue termination letter. NBH National Head Provides final decision and authorization before case closure. ``` ### 8.3 Termination Approval & Review Process **8.3.1 Functionality Scope** The **Termination Approval module** enables Royal Enfield’s internal stakeholders to manage dealership termination cases in a structured, transparent, and traceable workflow. It ensures that every dealership performance concern — whether due to **working capital shortfall** , **sustained underperformance** , or **unethical practices** — is systematically reviewed, documented, and acted upon through the defined escalation hierarchy. This module supports structured documentation of **dealer meetings** , **uploaded artefacts** , **reviewer remarks** , and **legal correspondence** , ensuring no manual communication dependency. All approvals, send-backs, or withdrawals are centrally logged, supported by **Work Notes** , ensuring collaborative clarity and institutional memory across teams. The **CEO is the final approving authority** for dealer termination cases. The **Legal team prepares and issues the termination letter only after CEO approval** , and **not upon NBH approval**. **CCO and CEO** are included as approval authorities with **Approve, Hold, and Reject options**. The **dealer does not have portal access** for termination workflows. **8.3.2 Width** The process spans across the complete DD and Legal hierarchy, ensuring clear role-based accountability: - **ASM:** Conducts monthly visits, logs Meeting of Minutes (MOM), uploads dealer commitment letter and personal observations. Logging MOM is not the part of this system but when he feel to trigger Termination, he will log as description & associate documents while initiating the flow. - **RBM + DD-ZM:** Escalate after repeated concerns, conduct joint meetings, and document dealer responses on portal. - **ZBH:** Reviews zonal-level non-compliance, escalates unresolved cases to DD-Lead and NBH. - **DD-Lead:** Reviews consolidated reports, validates escalation records, prepares case presentation, and assigns to Legal. - **Legal:** Reviews chronology, evaluates policy or contractual breaches, issues SCN, and prepares final Termination Letter. - **DD-Head:** Reviews with DD-Lead and Legal; presents case to NBH for decision. - **NBH:** Provides final decision – approve, query, or hold. - **DD-Admin:** Uploads dealer’s SCN response and handles F&F coordination post Legal issuance. **8.3.3 Depth** - **Structured Case Creation (Owner: DD-Lead / DD-Admin / ASM)** A Termination case is initiated through the “Create Termination Request” form by DD- Lead, DD-Admin, or ASM. o Each request is tagged with a unique **Termination ID** (e.g., TERM-001). o Dealer and operational data are automatically fetched from the **Dealer** **Master** and **Sales System** for accuracy. - **Case Workflow Management (Owner: Workflow Engine)** Each stage of the termination journey — from ASM initiation to Legal closure — is mapped to approval levels. o **ASM → RBM/DD-ZM → ZBH → DD-Lead → Legal → DD-Head → NBH**. o Actions at every level (Approve, Withdraw, Send Back) are recorded with mandatory remarks. o Each remark auto-updates in **Work Notes** and **Progress Timeline** , triggering instant notifications to the next role. - **Work Note Integration (Owner: All Reviewers)** The **Work Note** acts as the **central communication thread** within each termination case. o Each reviewer (ASM, RBM, ZBH, DD-Lead, Legal, etc.) can post contextual remarks, share discussions, or tag specific users. o Tagged users (e.g., @DD-Lead, @Legal) receive instant notifications via **system** **alerts** and **email**. o Work Notes serve as a real-time collaboration and escalation record — every comment, clarification, or update remains **time-stamped and user-tagged**. o Legal and DD-Head may also use Work Notes to request clarification from lower hierarchies (ASM, RBM, ZBH). o Once a note is submitted, it becomes immutable and part of the **permanent** **record** under **Audit Trail**. - **Meeting & Artefact Uploads (Owner: ASM, RBM, ZBH)** Each level of escalation includes upload of MOMs, dealer commitment letters, and observations while Approving at his level. o Artefacts are uploaded as PDFs (e.g., _Meeting_MOM_June2025.pdf_ ). o Dealer commitments are scanned and attached for cross-reference during Legal and NBH reviews. - **Approval Actions (Owner: Workflow Engine)** Reviewers can take the following actions: o **Approve:** Confirms escalation readiness for next level. o **Send Back:** Pushes case back for clarification with remarks visible in Work Notes. o **Withdraw:** Used when the concern is resolved or no termination action is required. Each action is recorded in both **Audit Trail** and **Work Notes** , ensuring clarity on decision paths. - **Legal Review and Issuance (Owner: Legal Team)** Legal reviews the case chronology and uploaded artefacts. o If clarification is needed, they “Send Back” via Work Notes. o Once validated, Legal create the **Show Cause Notice (SCN)** to the portal and later create the **Termination Letter** post NBH approval. o These Show cause Notice and Termination Letter will be created within the system o All uploaded legal artefacts remain accessible to DD-Lead, DD-Admin, and NBH. - **Dealer Interaction & Closure (Owner: DD-Admin / DD-Lead)** Dealer replies to the SCN via DD-Admin, who uploads the response to the portal. o DD-Lead reviews dealer’s response with inputs from RBM and ZBH, updates closure remarks, and forwards to NBH. o Post-approval, Legal uploads the Termination Letter, visible to DD-Admin and dealer. o DD-Admin initiates **F&F** coordination, ensuring all records are finalized within SLA. - **Immediate Termination (Owner: DD-Lead + Legal)** Cases categorized under “Unethical Practice” trigger direct routing to Legal + DD- Lead, skipping intermediate reviews. o Immediate Legal action and issuance of termination communication occur within the system, ensuring swift compliance. - **Audit Trail (Owner: System Engine)** Each user action — approval, send back, upload, comment — is timestamped and permanently logged. o The trail captures: _User Name, Action Type, Timestamp, Remarks Summary, and_ _Linked Artefact_. o Accessible by DD-Lead, Legal, DD-Head, and NBH for compliance review. **8.3.4 Personas-wise Accessibility & Visibility** ``` Persona Responsibilities & Key Actions Access Rights ASM Creates termination request, uploads MOM & dealer commitments, adds initial remarks and observations. ``` ``` Create, View, Comment RBM / DD- ZM ``` ``` Reviews ASM input, conducts escalation meetings, uploads MOM, provides joint recommendations. ``` ``` View, Approve, Send Back ZBH Reviews regional non-compliance, uploads MOM, forwards unresolved cases to DD-Lead. ``` ``` Approve, Send Back DD-Lead Reviews full chronology, validates artefacts, triggers Legal for input, issues SCN, consolidates for final closure. ``` ``` Full Access, Approve, Withdraw Legal Reviews chronology, uploads SCN, issues Termination Letter, queries if required through Work Notes. ``` ``` Approve, Send Back, Upload DD-Head Reviews consolidated cases, presents them to NBH for final decision. ``` ``` Review, Comment ``` ``` NBH Approves or holds termination case; final authority on go- ahead decisions. ``` ``` Approve / Hold ``` ``` DD-Admin Uploads dealer’s SCN reply, final Termination Letter, and initiates F&F. ``` ``` Upload, Close ``` ``` Dealer (Read-only) ``` ``` Views SCN and final Termination Letter. View Only ``` ### 8.4 Termination Progress Timeline **8.4.1 Functionality Scope** The **Termination Progress Timeline** provides a stage-wise visualization of the entire termination journey — from case initiation to final closure. It ensures that every escalation, document, review, and approval is tracked transparently with timestamped accountability. Each level in the workflow — from **ASM initiation** to **CEO authorization** — is dynamically reflected with role names, document counts, feedback notes, and status indicators. The module promotes structured collaboration by integrating **Work Notes** and **Audit Trail** updates at each milestone, enabling leadership to monitor the decision flow in real time. **8.4.2 Width** The timeline consolidates inputs from multiple roles, creating an end-to-end view of operational, business, and legal evaluations: - **ASM** initiates the request and uploads meeting artefacts. - **RBM / DD-ZM** review and escalate based on repeated violations. - **ZBH** performs zonal validation and comments. - **DD-Lead** consolidates data, reviews chronology, and assigns to Legal. - **Legal** verifies contract breaches and provides legal opinion or Show Cause Notice (SCN). - **NBH** performs business-level evaluation and grants or holds final approval. - **CEO / CCO** complete the executive authorization. - **DD-Admin** coordinates issuance of the final Termination Letter and forwards it to F&F. Each transition (approve, send-back, withdraw) automatically updates the timeline with the reviewer’s remarks and uploaded artefacts. **8.4.3 Depth** The Termination Progress Timeline follows a clearly defined 14-stage lifecycle. Each stage is associated with specific ownership, document uploads, and Work Note actions. ``` 8.4.3.1 Stage-wise Breakdown ``` 1. **Request Initiated** – _ASM / Initiator_ o Case created with details, termination reason, and dealer code. o Supporting documents like MOM and commitment letters attached. o Remarks and feedback logged in Work Notes. 2. **RBM Review** – _RBM + DD-ZM_ o Joint meeting notes uploaded; recommendations shared. o Approve or Send-Back with clarification via Work Note. 3. **ZBH Review** – _Zonal Business Head_ o Evaluates pattern of violations, reviews MOM chain, and adds escalation remarks. 4. **DD Lead Review** – _DD-Lead_ o Consolidates documentation from ASM, RBM, and ZBH. o Prepares case synopsis and assigns to Legal for compliance validation. 5. **Legal Verification** – _Legal Department_ o Reviews breach type (Working Capital, Performance, Unethical Practice). o Queries or approves via Work Notes. o Uploads draft SCN if verified. 6. **NBH Evaluation** – _National Business Head_ ``` o Reviews termination recommendation; may approve, hold, or query. ``` 7. **Show Cause Notice (SCN)** – _Legal + DD-Lead_ o Official SCN issued to dealer. o Dealer reply awaited; all correspondence uploaded. 8. **DD Lead & Legal Review** – _Joint Review_ o Evaluates dealer’s SCN reply. o Records internal discussion outcome in Work Notes. 9. **DD-Head Review** – _Dealer Development Head_ o Prepares presentation and recommendation for NBH. 10. **CCO Approval** – _Chief Commercial Officer_ o Reviews and endorses NBH’s decision. 11. **CEO Final Approval** – _Chief Executive Officer_ o Authorizes final termination execution. 12. **Legal – Termination Letter** – _Legal Team_ o Uploads signed Termination Letter to portal. o Triggers auto-notifications to DD-Lead and DD-Admin. 13. **DD-Admin – Share with Dealer** – _DD-Admin_ o Forwards Termination Letter to dealer. o Initiates F&F process and records completion date. 14. **Dealer Terminated** – _System Generated_ o Marks dealership status as “Terminated.” o Case locked for further edits; all data archived under Audit Trail. ``` 8.4.3.2 Work Note Integration ``` - Each stage allows the reviewer to post contextual **Work Notes** for coordination, clarification, or escalation. - Notes automatically capture **author, timestamp, and linked stage**. - Tagged users receive both **email** and **in-app alerts**. - Work Notes act as the **single source of truth** , capturing every internal discussion and external clarification. - Once the case reaches “Dealer Terminated,” Work Notes are archived as part of the official record visible under **Audit Trail**. **8.4.4 Personas-wise Accessibility & Visibility** ``` Persona Visibility in Timeline Actions Allowed ASM Initiate request, view complete history, comment in Work Notes. ``` ``` Create, Upload Docs, Comment RBM / DD-ZM See all lower-level stages, add remarks, approve or send-back. ``` ``` Approve, Send-Back, Comment ZBH Access RBM & ASM artefacts, escalate to DD-Lead. Approve, Send-Back ``` ``` DD-Lead Full timeline visibility, assign to Legal, manage SCN, approve final closure. ``` ``` Full Access ``` ``` Legal Review termination grounds, issue SCN, upload Termination Letter. ``` ``` Approve, Send-Back, Upload Docs NBH View all previous stages, make go/no-go decision. Approve / Hold CCO / CEO Executive-level read access, approve final termination. ``` ``` Approve Only ``` ``` DD-Admin View complete timeline, upload dealer response & Legal letter, initiate F&F. ``` ``` Upload, Close ``` ``` Dealer (Read- only) ``` ``` View SCN and Termination Letter post-issuance. View Only ``` ## 9 Admin Section ### 9.1 Master Configuration – Organization **9.1.1 1. Functionality Scope** The **Master Configuration** module forms the foundation of the system’s administrative and organizational setup. Within this, the **Regional Hierarchy & Zone Management** section enables the **System Administrator** to define, structure, and maintain Royal Enfield’s official **Dealer** **Development (DD) hierarchy** , ensuring every dealer, outlet, and user is correctly mapped to their respective **Zone, Region, and Area**. This configuration drives workflow routing, approval ownership, SLA tracking, and reporting alignment across all dealer-facing processes such as onboarding, resignation, and F&F closure. **9.1.2 2. Width** - **Regional Hierarchy Overview:** o Displays five zones — **North, South, East, West, and Central** — each summarizing: ▪ Total **Regions** under the zone ▪ Number of **Zonal Managers (ZMs)** , **Regional Business Managers (RBMs),** **Area Sale Manager (ASM) & DD-AM (DD-Area Manager)** ▪ o **Zone Management** grid provides: ▪ **Zone Code** , **Zone Name** , and **Region** ▪ **States and Areas Covered** ▪ **DD / ZM / RBM / ASM / DD-AM Counts** ▪ Action controls — **Edit** , **Delete** ▪ **Add Zone** option for creating new records - **Add/Edit Zone Form:** o Input fields available for setup: ▪ **Zone Code** – e.g., _N-Z1_ ▪ **Zone Name** – e.g., _North Zone_ ▪ **Region** – Select from dropdown ( _UP, Punjab & others_ ) ▪ **States Covered** – Multi-select dropdown populated from the Location Master ▪ **Areas Covered** – Multi-select dropdown (district- or city-level sub- mapping) o **Save Zone:** Validates and commits configuration changes. o **Cancel:** Closes form without saving. **9.1.3 3. Depth** - **Definition of Hierarchy:** o The Royal Enfield network is structured as: **Zone → Region → Area → Dealer / Showroom** o Each level has clear administrative and operational ownership, ensuring traceability and accountability across the dealer ecosystem. o **Example – North Zone Structure:** o North Zone ( 900 Dealers) o ├── UP Region ( 180 Dealers) ``` o │ ├── Lucknow Area ( 8 Dealers) o │ │ ├── Pushp Auto (Alambagh Showroom) o │ │ ├── Rishabh Motors (Gomti Nagar) o │ │ └── 6 More Local Outlets o │ ├── Kanpur Area ( 10 Dealers) o │ └── 13 Other Areas o ├── Punjab Region ( 150 Dealers) o └── 5 Other Regions o This hierarchical configuration ensures that every Dealer , Studio , or Outlet is mapped under a defined Area , which rolls up into a Region , and subsequently into a Zone. ``` - **Data Mapping & Validation Logic:** o Each **Zone** is assigned a unique identifier and linked to its parent **Region** and **Area**. o **Dealer Development (DD)** resources are mapped to their respective areas for process routing. o State–Area relationships are validated to prevent overlapping coverage or duplicate entries. o Automatic recalculation of counts occurs when dealers or managers are reassigned. **9.1.4 Dealer Development Hierarchy & Responsibility Mapping** ``` Hierarch y Level ``` ``` Example from North Zone Structure ``` ``` Approx. Dealer Coverag e ``` ``` Responsible Roles ``` ``` Scope of Oversight / Visibility ``` ``` Operational Responsibilitie s ``` ``` National Level ``` ``` Pan-India – All Zones (North, South, etc) ``` #### ~3,000+ ``` Dealers ``` ``` DD-Lead , DD- Head , NBH , DD ``` **- Admin** ``` End-to-end national governanc e across all Zones, Regions, and Areas ``` - Oversee all onboarding, resignation, and F&F workflows - Monitor SLA adherence and performance metrics - Approve escalated cases or exceptions Zone Level ``` North Zone (e.g., 900 Dealers) ``` #### 700 – #### 1,000 ``` Dealers per Zone ``` ``` DD-ZM , ZBH Zonal oversight covering multiple Regions ``` - Review zonal performance - Coordinate between Regional and ``` and their assigned RBMs ``` ``` National teams ``` - Validate dealer onboarding, closure, and SLA metrics - Escalate financial and compliance matters to DD- Lead Region Level ``` UP Region , Punjab Region , etc. ``` #### 100 – 200 ``` Dealers per Region ``` ``` RBM (Regional Business Manager) ``` ``` Regional oversight covering multiple Areas under one Region ``` - Supervise Area Managers - Approve dealer-level operational activities - Ensure adherence to regional sales, service, and brand standards - Review and forward approvals to DD-ZM or higher Area Level ``` Lucknow Area (8 Dealers), Kanpur Area (10 Dealers) ``` #### 5 – 15 ``` Dealers per Area ``` ``` DD-AM (Area Manager) , ASM (Area Sales Manager) ``` ``` Area-level operations covering dealers and sub- dealers ``` - Manage direct dealer interactions and field audits - Validate dealer data, documents, and site activities - Report progress, feedback, and resignation inputs ``` upstream ``` - First point of verification for dealer submissions Dealer / Outlet Level ``` Pushp Auto (Alambagh) , Rishab h Motors (Gomti Nagar) ``` ``` 1 Dealer (Main / Studio / Service Outlet) ``` ``` DD-AM (Area Manager) , ASM (Area Sales Manager) ``` ``` Dealer operations reporting into Area- level roles ``` - Submit onboarding, resignation, or compliance documentation - Coordinate with DD-AM / ASM for all operational requests ### 9.2 Zone, Region & Area Configuration **9.2.1 Functionality Scope** The **Zone, Region & Area Configuration** module defines the geographical and managerial hierarchy governing Royal Enfield’s entire dealer network. It empowers the **Admin** to configure the structural mapping of **Zones** , **Regions** , and **Areas** , thereby aligning operational responsibilities and approval flows across Dealer Development (DD), Sales, and Business teams. Each **Zone** is led by a **Zonal Business Head (ZBH)** and comprises multiple **Regions** managed by **Regional Business Managers (RBMs)**. Within each region, **Area Sales Managers (ASMs)** and **Dealer Development Area Managers (DD-AMs)** oversee localized dealer operations. Above these field roles, the hierarchy extends to **Dealer Development Zonal Managers (DD-ZM)** , **DD-Lead** , **DD-Head** , and finally the **National Business Head (NBH)** , ensuring visibility and governance across all levels. This structure serves as the foundation for all workflows — including **Onboarding, Resignation, Termination, and F&F Settlements** — ensuring automated routing, escalation, and performance tracking aligned to the correct operational hierarchy. **9.2.2 Width** This module spans the full organizational hierarchy and covers all geographic and managerial relationships that define how workflows are routed and governed: - **Zone Configuration** o Define zone code, name, and description (e.g., North Zone, South Zone). o Assign the **Zonal Business Head (ZBH) & DD-ZM** with name, contact, and email. o Select all **states and union territories** falling under the zone’s jurisdiction. - **Regional Configuration** o Create one or multiple regions (Sates) under each zone. o Assign a **Regional Business Manager (RBM)** and link them with contact details. o Map states and districts under the region. o Specify the total **Regional Officers** and **Area Managers** working under the region. - **Area Configuration (ASM / DD-AM Assignment)** o Configure **Area Sales Managers (ASM)** and **Dealer Development Area Managers** **(DD-AM)** with designated city or district coverage. o Link each ASM/DD-AM to their corresponding Region and Zone. o Set contact details, status, and operational scope (Active/Inactive). - **Hierarchy Linkage Across Levels** o Each region and area automatically link upward to **DD-ZM** , **ZBH** , and **DD-Lead** , ensuring system-level routing alignment. o National roles such as **DD-Head** and **NBH** inherit macro-level visibility across all configured territories. **9.2.3 Depth** - **Organizational Mapping:** Each dealer request or case — whether onboarding, resignation, or termination — inherits its routing chain from this hierarchy (e.g., ASM → RBM → ZBH → DD-Lead → NBH). This ensures consistent reporting and accountability. - **Role Interlinking:** o **ASM & DD-AM** : Manage dealer operations, visit tracking, and initial-level data inputs. o **RBM & DD-ZM** : Conduct mid-level evaluations and provide regional performance oversight. o **ZBH** : Supervises zonal dealer network health and strategic decisions. o **DD-Lead & DD-Head** : Manage pan-India dealer policies, escalations, and workflow resolutions. o **NBH** : Holds final oversight and decision authority for national-level approvals. - **Geographic Traceability:** Every configuration entry — from zone to district — enables traceable linkage of dealer location, responsible officers, and workflow approvals. - **Dynamic Updates & Scalability:** Admins can modify or reassign any role or coverage area without disrupting ongoing workflows. The system auto-updates workflow routing, escalation hierarchy, and reports in real time. - **There can be multiple users mapped at same role.** For example, there can be 2 ZBH or 3 DD-ZM at a same Zone. - **Data Consistency & Integration:** Each change reflects across dependent modules like **Role & Permissions** , **SLA** **Management** , and **Email Notifications** , ensuring all updates remain synchronized. **9.2.4 Personas-wise Accessibility & Visibility** ``` Persona Responsibilities in Module Access Level Admin Creates, edits, and manages the entire hierarchy — zones, regions, and ASMs. Assigns officers and maintains real-time linkage between geographic and managerial structures. ``` ``` Full Access ``` ``` DD-AM (Dealer Development Area Manager) ``` ``` Views assigned area (district/city), local dealers, and reporting managers. ``` ``` View Only ``` ``` ASM (Area Sales Manager) ``` ``` View assigned territory’s dealer operations, monitors requests, and coordinates with RBM. ``` ``` View & Comment RBM (Regional Business Manager) ``` ``` View regional offices, assigns ASMs, and validates dealer-level data. ``` ``` Edit within assigned region DD-ZM (Dealer Development Zonal Manager) ``` ``` Reviews dealer development operations within the zone and collaborates with RBMs. ``` ``` View & Comment ``` ``` ZBH (Zonal Business Head) ``` ``` Monitors zone-level performance and ensures escalation or workflow alignment with DD-Lead. ``` ``` View & Comment DD-Lead Reviews configuration consistency, ensures correct routing for all workflows, and validates escalation logic. ``` ``` View Only ``` ``` DD-Head Reviews national-level structure, oversees zonal and regional performance, and approves any configuration realignment. ``` ``` View Only ``` ``` NBH (National Business Head) ``` ``` Holds complete top-level visibility for all zones, oversees configuration for governance and reporting accuracy. ``` ``` View Only ``` ### 9.3 Roles & permissions **9.3.1 Functionality Scope** The **Roles & Permissions** module governs how users across Royal Enfield’s Dealer Development and allied departments (Finance, Legal, FDD) interact with the system. It ensures each role has controlled access to relevant workflows, reports, and actions within the **Dealer Lifecycle** — from opportunity creation and onboarding, through evaluation and FDD, to resignation and closure. The module supports **multi-level permission granularity** , allowing both **role-based** and **user-specific** privilege configurations. This provides flexibility to assign additional or restricted access based on operational necessity while maintaining organizational compliance and hierarchy alignment. **9.3.2 Width** - **Role Management Dashboard:** o Displays every configured role along with its assigned permissions and mapped users. o Columns include: ▪ **Role Name** ▪ **Permissions** (summary + expandable list) ▪ **User Count** ▪ **Actions** ( _Edit_ , _Delete_ ) - **Add/Edit Role:** o **Role Name** – unique identifier (e.g., _DD-ZM_ , _Finance_ , _Legal_ ). o **Description** – outlines the role’s scope (e.g., _Manages Zonal Operations & Level- 1_ _Evaluation_ ). o **Permission Toggles:** ▪ View / Review / Approve / Reject Applications ▪ Upload Documents ▪ Schedule Interviews ▪ Manage Users ▪ View Reports ▪ Configure SLA ▪ Manage Templates ▪ View / Verify Payments - **Save Role / Cancel** – commits or discards changes. **9.3.3 Depth** ``` 9.3.3.1 Role Responsibilities & Hierarchy Mapping Level / Function Roles Involved Scope of Responsibility Core Permissions Area Level (Field Operations) ``` ``` DD-AM (Dealer Development Executive / Area Manager) ``` ``` Identifies new dealership opportunities on-ground, interacts with prospects, validates field data, and supports documentation readiness. ``` ``` View & upload applications, update opportunity details, add work notes. ``` ``` Level- 1 Evaluation (Zonal / Regional Assessment) ``` ``` DD-ZM + RBM Conducts initial evaluation using KT Matrix , reviewing applicant credentials, financial potential, and local market understanding. ``` ``` View, review, and approve Level- 1 applications; record KT scores; schedule interviews. Level- 2 Evaluation (Strategic Assessment) ``` ``` DD-Lead + ZBH Reviews shortlisted applications for business alignment, operational readiness, and strategic fit. Approves or forwards for final evaluation. ``` ``` Approve/Reject applications, review interview feedback, upload evaluation documents. ``` ``` Level- 3 Evaluation (National Approval) ``` ``` NBH + DD-Head Conducts final decision- making for dealership onboarding or closure, ensuring alignment with brand growth and financial feasibility. ``` ``` Full visibility of all applications, approve or reject at final stage, review all attachments and reports. ``` ``` Financial Due Diligence (FDD) ``` ``` FDD Team Performs external financial due diligence for assigned applications. Limited view of assigned cases only. Can upload FDD reports and raise work notes for queries. ``` ``` Upload FDD report, add comments in work notes, mark completion. ``` ``` Finance Finance Team Manages payment-related verifications, security deposit validations, and refund approvals for resignations. ``` ``` View and verify payments, upload supporting documents, confirm receipts. Legal Legal Department ``` ``` Reviews LOI, LOA, dealership termination letters, and agreement documents for compliance. ``` ``` View legal documents, upload vetted files, provide legal remarks, ``` ``` approve or return for correction. National Governance ``` ``` DD-Lead, DD- Head, NBH, DD- Admin ``` ``` Central oversight for all zones; monitors workflows, SLA compliance, and manages role/user configurations. ``` ``` Full system visibility, manage roles, configure SLA, access reports and audit logs. ``` ``` 9.3.3.2 Customizable Permission Framework ``` - **Role-Level Permissions:** Define the baseline privileges for all users under a given role (e.g., all DD-ZMs can _view_ _applications_ , _review_ , and _approve_ Level-1). - **User-Level Overrides:** Allow case-specific adjustments for individuals. o Example: Two DD-ZMs under different zones — one may have additional permission to _view reports_ , while another may be limited to _review and approve_ _applications_ only. - This layered model ensures consistency in role design while supporting operational adaptability. ``` 9.3.3.3 Audit & Security Controls ``` - Every permission change (at both role and user levels) is logged under **Audit Trail** with timestamp, actor ID, and before-after states. - Ensures traceability of configuration changes for compliance with Royal Enfield’s data- governance framework. - System auto-validates access inheritance to prevent privilege conflicts between dependent modules. **9.3.4 4. Personas-Wise Access Summary** ``` Persona / Role ``` ``` Level Operational Focus Permission Highlights ``` ``` DD-AM Area Ground opportunity identification, field validation ``` ``` Add work notes ``` ``` RBM Regional Regional evaluation & KT Matrix scoring ``` ``` Review documents, add remarks, shortlist DD-ZM Zonal Zonal evaluation & Level- 1 approval ``` ``` Approve Level-1, manage users ``` ``` ZBH Zonal Strategic oversight & Level- 2 evaluation ``` ``` Approve Level-2, upload summary, finalize recommendations DD-Lead National Governance & performance oversight ``` ``` Manage users, approve Level- 2 evaluations DD-Head National Final authorization Full system access, finalize decisions NBH National Strategic business head Joint Level- 3 evaluation, approve/reject final decision FDD External Financial due diligence Upload FDD reports, query via work notes Finance Cross- functional ``` ``` Payment validation & security deposit checks ``` ``` View/verify payments, upload receipts Legal Cross- functional ``` ``` Legal document review Upload & verify legal documents, add remarks DD-Admin National Configuration management Manage roles, SLA, locations, templates, schedule interviews ``` ### 9.4 SLA Configuration & Escalation Management **9.4.1 Functionality Scope** The **SLA Configuration** module enables Admin to define, monitor, and enforce **Turnaround Time (TAT)** for every activity across the dealer lifecycle (onboarding, interviews, FDD, legal, payments, resignation, F&F, LOI/LOA, EOR, etc.). The system supports **three-level escalation** , **pre-TAT reminders** , and **post-TAT breach notifications**. All reminders and escalations are **auto-logged in Work Notes** and **trigger email + in-app notifications** , ensuring traceability, transparency, and timely closure. **9.4.2 Width** - **SLA Templates** o Activity/Stage (e.g., _Level-1 Interview Feedback_ , _FDD Report Upload_ , _Payment_ _Verification_ , _LOI Approval_ , _Resignation Review_ ). ``` o Owner Role (e.g., DD-ZM , RBM , ZBH , DD-Lead , Finance , Legal , FDD ). o TAT Unit & Calendar: hours/days, working days o Pre-TAT Reminders: schedule one or more reminders (e.g., T-48h , T-24h , T-2h ). o Escalation Matrix (3 levels): ▪ L1: After breach +X hours → Escalate to immediate supervisor (e.g., RBM → DD-ZM). ▪ L2: If still open +Y hours → Escalate to zonal authority (e.g., ZBH / DD-Lead). ▪ L3: If still open +Z hours → Escalate to national authority (e.g., DD-Head / NBH ). o Notification Channels: email, in-app notification, optional SMS. o Work Notes Posting: auto-post reminder/escalation entries with timestamp, SLA name, and due metrics. o Repeat Overdue Reminders: configurable cadence (e.g., every 24h until closure). o Pause Rules (optional): pause SLA when status is On Hold / Waiting for Applicant / Awaiting External (e.g., FDD). o Scope Rules: by Zone/Region/Area, by Role, by Activity Type, and by Application Category. ``` - **Dashboards & Views** o **My SLA Queue:** due soon, breached, and escalated items for the logged-in user. o **Aging Buckets:** 0 – 25%, 26–75%, 76–99%, Breached. o **SLA Badges** on list cards and detail pages (green/amber/red) with remaining time. o **Reports:** breach rate, average resolution time, top delayed activities, escalations by level/role/region. **9.4.3 Depth** - **Clock Start/Stop Logic** o SLA starts when the activity is **created/assigned** to the owner role. o SLA **pauses** on configured statuses (e.g., _Waiting for Applicant / FDD /_ _Legal_ ), **resumes** on return to active. o SLA **stops** on closure states (e.g., _Approved/Rejected/Completed_ ). - **Reminder & Escalation Execution** o At each pre-TAT checkpoint the system: ▪ Sends **email + in-app reminder** to the activity owner. ▪ **Posts an automated Work Note** (e.g., “T-24h: Reminder sent to RBM for Level-1 Feedback”). o On TAT breach: ▪ Marks item **Breached (red)** , posts **Work Note** with elapsed time. ▪ Triggers **Escalation L1** to the mapped role; if not resolved within L1 window, cascades to **L2** then **L3**. ▪ Each escalation includes assignee, timestamp, reason, and a link to the record. **9.4.4 Personas-Wise Accessibility & Visibility** ``` Persona Accessibility Visibility System Admin Create/edit/activate/deactivate SLA templates; define calendars, holidays, pause rules; set escalation roles and notification schedules. ``` ``` Global. ``` ``` DD-Admin Map activities to templates; monitor SLA status; initiate corrective routing. ``` ``` National/regional (as allowed). Owners (DD-AM, RBM, DD-ZM, ZBH, DD-Lead, Finance, Legal, FDD) ``` ``` Receive reminders; act on assigned items; view timers, badges, and Work Notes; acknowledge escalations. ``` ``` Assigned records and queues. ``` ``` DD-Head / NBH Receive L3 escalations; view breach dashboards; intervene/realign ownership. ``` ``` Pan-India. ``` ``` System (Automation) Runs timers, posts Work Notes, sends notifications, cascades L1→L2→L3 escalations, updates dashboards. ``` ``` Background. ``` **9.4.5 Example SLA (illustrative)** - **Activity:** _Level-1 Interview Feedback (KT Matrix)_ - **Owner: DD-ZM + RBM** - **TAT:** 2 working days; Business hours 9:00–18:00; weekends excluded. - **Reminders:** T-24h and T-4h to owners. - **Escalations:** o **L1 (T+4h):** to **ZBH** o **L2 (T+12h):** to **DD-Lead** o **L3 (T+24h):** to **DD-Head/NBH** - **System Actions:** badges on record; Work Notes for every reminder/escalation; email + in- app notifications at each step. ### 9.5 Email & Letter Templates Management **9.5.1 Functionality Scope** The **Email & Letter Templates** module enables system administrators to configure and automate communication across all dealer lifecycle workflows — including onboarding, interviews, payments, FDD, approvals, and resignation stages. Each template defines **trigger-based notifications** , ensuring timely and consistent communication between internal users (DD roles, RBM, ZBH, etc.) and external applicants. Templates can dynamically pull context-specific details using **system variables** and can be activated, edited, or versioned at any time. This module ensures communication uniformity across regions and roles while supporting **automation triggers** , **personalized content** , and **multi-channel delivery** (email + in- app notifications). **9.5.2 2. Width** ``` 9.5.2.1 Template Management Dashboard ``` - Displays all active and inactive templates with details such as: o **Template Name** – e.g., _Application Received_ , _Interview Scheduled_ , _SLA Breach_ _Warning_. o **Subject Line** – dynamic subject that appears in email notifications. o **Trigger Event** – specifies when the email is auto-sent (e.g., on approval, rejection, or SLA breach). o **Last Modified Date** – timestamp of latest changes for version control. o **Actions** – _Edit_ , _Duplicate_ , _Delete_. ``` 9.5.2.2 Add / Edit Template ``` Each email template includes configurable fields: - **Template Name:** Internal label for easy identification (e.g., _Application Approved_ ). - **Email Subject:** Subject line used for recipients (e.g., _Congratulations! Your Application_ _Has Been Approved_ ). - **Trigger Event:** Selects the system action that will initiate the email (dropdown includes): o On Application Submission o On Approval o On Rejection o Interview Scheduled o Document Request o Payment Required o SLA Breach Warning o Payment Reminder - **Template Body:** Rich-text editor (HTML support) with system variable placeholders for dynamic insertion. - **Active Template Toggle:** Enables or disables template without deletion. - **Save / Cancel Buttons:** Commit or discard edits. **9.5.3 3. Depth** ``` 9.5.3.1 Trigger Mechanism ``` Each configured template is mapped to an **event listener** within the workflow. When a user or system action matches the trigger condition, an automated email and in-app notification are generated and dispatched to the intended recipients. For example: - When an applicant submits a form → triggers _Application Received_ template. - When DD-ZM schedules an interview → triggers _Interview Scheduled_ template. - When SLA for an activity nears breach → triggers _SLA Breach Warning_ template. ``` 9.5.3.2 Dynamic Data Population ``` Templates leverage **predefined system variables** to automatically populate relevant data, ensuring contextual accuracy. Available variables include: ``` Variable Description ``` {{applicant_name}} (^) Applicant’s full name {{application_id}} (^) Unique application identifier {{application_date}} Submission date {{interview_date}} (^) Scheduled interview date {{interview_time}} (^) Scheduled interview time {{status}} (^) Current application status {{reason}} (^) Reason for rejection or remark {{company_name}} Dealer firm or business entity name {{location}} (^) Preferred / applied dealership location {{reviewer_name}} (^) Approver or interviewer name {{payment_amount}} Amount due or verified {{due_date}} (^) Payment / response deadline {{support_email}} (^) Official support or contact email Variables are replaced dynamically at runtime, ensuring personalized and accurate communications without manual edits. ``` 9.5.3.3 Trigger Linkage & Workflow Integration ``` - The module is fully integrated with system workflows — **Dealer Onboarding, Interview** **Evaluation, FDD, Finance, Legal, and Resignation**. - Templates can be reused across similar workflows and roles, minimizing duplication. - Each workflow can have multiple templates mapped to distinct sub-events (e.g., _Interview_ _Scheduled_ vs _Interview Rescheduled_ ). ``` 9.5.3.4 Escalation & SLA Communication Integration ``` - SLA reminders and escalations leverage the same template framework. - Templates like _SLA Breach Warning_ and _Pending Action Reminder_ automatically pull escalation hierarchy and timestamps. - Escalations are simultaneously logged in **Work Notes** to maintain an auditable communication trail. **9.5.4 4. Personas & Permissions** ``` Role Access Type Description System Admin / DD-Admin Full Access Create, edit, activate, deactivate, or delete templates; map triggers; modify variables. DD-Lead / ZBH / DD-Head Limited View ``` ``` Can preview active templates relevant to their workflow. All Other Roles (RBM, DD- ZM, Finance, FDD, Legal) ``` ``` Execution- Only ``` ``` Receive or trigger templates automatically; no edit rights. ``` **9.5.5 5. Example Template Configuration** ``` Field Value Template Name ``` ``` Interview Scheduled ``` ``` Subject Interview Scheduled – Royal Enfield Dealership Trigger When Interview Scheduled Body Dear {{applicant_name}}, ``` ``` Your interview for the Royal Enfield Dealership has been scheduled on {{interview_date}} at {{interview_time}}. ``` ``` Location: {{location}} Reviewer: {{reviewer_name}} ``` ``` Please ensure timely attendance. ``` ``` Regards, Royal Enfield Dealer Development Team Active Yes ``` ### 9.6 Opportunity Management (Geography & Window Setup) **9.6.1 Functionality Scope** The **Opportunity Management** module allows Admin to define where and when dealership opportunities are open. Admin can create opportunities at **Zone → Region → Area** granularity, specify **From / To dates** , and manage the status ( **Active / Inactive / Closed** ). The module also provides **date-range filters** and reports to view **historical opportunity windows** , ensuring transparency, traceability, and controlled intake of applications. **9.6.2 Width** - **Create / Edit Opportunity** 1. **Geography:** Zone → Region → Area (cascading drop-downs), plus **State / City /** **District**. 2. **Opportunity Details:** Opportunity Type (Main / Studio / Service), **Capacity** (no. of dealer slots), **Priority** , Notes/Justification. 3. **Open Window: From Date** and **To Date** (business calendar), optional **Auto-close** **on end date**. 4. **Ownership:** Responsible Role (e.g., DD-ZM / RBM) for visibility and SLA routing. 5. **Status:** Draft / Active / Inactive / Closed. 6. **Attachments (optional):** Market study, demand assessment, approvals. - **List & Search** 1. Columns: State, City, District, Zone, Region, Area, Opportunity Type, Capacity, Status, Open From, Open To, Last Updated. 2. Quick actions: **Edit** 3. Global search and multi-facet filters (Zone/Region/Area, State/City/District, Type, Status). - **Date-Range & Historical View** 1. **Filter by From–To Date** to see which locations were open within a selected window. 2. Toggle **“Show only open during range”** or **“Show all with overlap”**. 3. Export results (CSV/XLS) for audits and leadership review. **9.6.3 Depth** 1. **Cascading Geography:** Selecting a **Zone** filters **Regions** ; selecting a **Region** filters **Areas** ; **State/City/District** lists are bound to the chosen Area. 2. **Window Logic:** An opportunity is **Active** only within its **From–To** dates; the system auto- marks **Closed** on expiry if _Auto-close_ is enabled. 3. **Status Lifecycle:** o **Draft → Active → Inactive/Closed**. Inactive hides the location from the public form; Closed retains history. 4. **Notifications:** When a window is **activated** or **closed** , notify mapped **DD-ZM/RBM** 5. **Historical Reporting:** o Date filter computes **effective windows** (open or overlapping) within the selected range and shows **who created/edited** , timestamps, and notes. **9.6.4 Personas-wise Accessibility & Visibility** ``` Persona Accessibility Visibility Admin / DD- Admin ``` ``` Create, edit, activate/deactivate, archive opportunities; bulk upload; run exports; manage conflicts and capacity. ``` ``` Nationwide. ``` ``` DD-Lead / DD- Head / NBH ``` ``` View dashboards and historical reports; download exports. Nationwide.^ ZBH / DD-ZM / RBM ``` ``` View opportunities for their Zone/Region ; receive activation/closure notifications; capacity view. ``` ``` Scoped to assigned geographies. ASM / DD-AM Read-only list for assigned Areas to plan ground activities. Area-level. System (Public Apply Form) ``` ``` Shows only Active opportunities within current date and capacity; hides inactive/closed ones. N/A^ ``` **9.6.5 Validation & UX Notes** 1. **Required:** Zone, Region, Area, Opportunity Type, From Date, To Date, Status. 2. **Date Checks:** _From_ must be ≤ _To_ ; warn if window is in the past; prevent zero-length windows unless explicitly allowed. 3. **Timezone & Calendar:** Respect business calendar; holidays can be referenced for SLA tie- ins. 4. **Inline Status Chips: Active (green)** , **Inactive (gray)** , **Closed (blue)** for quick scanning in the list. 5. **Filter Presets:** _Currently Open_ , _Upcoming_ , _Expired_ , _My Zone_ for fast navigation. ## 10 F&F Case The **Full & Final (F&F) Settlement** process enables the Finance team to close all financial obligations with a dealer after resignation or termination. Once triggered by Legal, the system consolidates inputs from all departments to capture dues, recoveries, and clearances. Finance reviews and validates these entries, prepares the final settlement summary, and executes payment or recovery based on the calculated net amount. All actions, remarks, and proofs are recorded in the system for transparency, and the case is marked as **F&F Completed** once the transaction and approvals are finalized. ### 10.1 F&F Settlement Progress Timeline **10.1.1 Functionality Scope** The **F&F Settlement Progress Timeline** provides a sequential, stage-wise overview of the dealer’s Full & Final (F&F) settlement journey — right from initiation to final completion. It acts as a unified visual tracker for Finance, Legal, DD, and Admin teams, enabling transparent monitoring of all financial closure activities, departmental dependencies, dealer discussions, and documentation milestones. Each stage dynamically updates in real-time based on workflow actions performed by responsible stakeholders, showing the exact case status and progress across all involved departments. **10.1.2 Width** The timeline integrates all key phases and users involved in the financial closure ecosystem, including: - **DD-Lead / DD-Admin:** Initiate the F&F process upon Legal approval of Resignation or Termination. - **Finance:** Validate departmental responses, calculate payables/recoverables, initiate discussion with the dealer, and finalize settlement disbursement or recovery. - **Departments (16 Functional Units):** Submit financial clearances or pending dues data through their respective interfaces. - **Legal:** Verify settlement completion for compliance and record-keeping. **10.1.3 Depth** The timeline comprises six structured stages, each with clearly defined ownership, system actions, and dependencies. ``` 10.1.3.1 F&F Initiated ``` - **Owner:** DD-Lead / DD-Admin - **Description:** Marks the creation of the F&F case post-approval of Resignation or Termination. System auto-generates the **Case Number** (e.g., _FNF- 2025 - 001_ ) and pre-populates dealer details such as name, location, and request type. - **System Actions:** o Case record created under Finance module. o Notification sent to Finance and departmental stakeholders. o Status: _Completed_ once initialization is confirmed. ``` 10.1.3.2 Department Responses Received ``` - **Owner:** All Functional Departments - **Description:** Each department submits its NOC or dues-related information through the integrated F&F clearance form. Departments that owe or are owed amounts mark respective payables/receivables with remarks. - **System Actions:** ``` o Progress bar updates with response count (e.g., 12 of 16 Departments Responded ). o SLA-based reminders triggered for pending responses. o Timeline stage remains Pending until all NOCs are received or escalated. ``` ``` 10.1.3.3 Finance Final Summary ``` - **Owner:** Finance - **Description:** The Finance team consolidates all departmental responses, computes total payables, receivables, and deductions, and prepares a comprehensive **Settlement Summary** **Report**. - **System Actions:** o Auto-calculation using predefined formula: Net Settlement = Total Payables – Total Receivables – Deductions. o Finance reviews and verifies supporting documents. o Work Notes used to raise clarifications to departments or DD-Lead. o Status changes to _Pending Dealer Discussion_ after internal approval. ``` 10.1.3.4 Financial Discussion with Dealer ``` - **Owner:** Finance + Legal + DD-Lead - **Description:** The Finance and Legal teams review the computed summary with the dealer to confirm payable or recoverable balances. Dealer may be invited to review supporting documentation and validate accuracy. - **System Actions:** o Discussion details logged under **Work Notes** with date and participants. o Dealer confirmation captured in remarks. o Settlement sheet locked for final processing once dealer agreement is confirmed. ``` 10.1.3.5 Full and Final Settlement ``` - **Owner:** Finance - **Description:** All financial actions — including payments, recoveries, and internal ledger updates — are executed. Proof of payment, transaction IDs, and settlement receipts are uploaded. - **System Actions:** o Transaction details (Mode, Reference, Amount, Date) entered in **Settlement** **Verification**. ``` o Status updated to Processed once Finance approves the settlement. o System triggers automated notifications to DD-Admin, Legal, and DD-Lead. ``` ``` 10.1.3.6 F&F Complete ``` - **Owner:** Finance + DD-Admin + Legal - **Description:** The final stage confirming that the F&F process has been fully completed, all payments or recoveries are reconciled, and all documentation is finalized. - **System Actions:** o Case status updated to _Closed_. o Settlement report archived in **Audit Trail**. o Final closure notification sent to all stakeholders. **10.1.4 Personas-wise Accessibility & Visibility** ``` Persona Timeline Visibility Actions Allowed DD-Lead / DD- Admin ``` ``` Full visibility of all stages from initiation to completion. ``` ``` Initiate F&F, Upload Docs, Add Notes Finance Complete visibility across all stages with actionable control from Stage 3 onwards. ``` ``` Verify, Approve, Reject, Comment Departments (16 Units) ``` ``` Visible until Department Responses stage. Submit NOC, Add Comments Legal Visible from Dealer Discussion to Final Closure. ``` ``` Review, Comment ``` ``` NBH / ZBH / DD- Head ``` ``` View-only summary of financial progress. None ``` ### 10.2 Department Responses **10.2.1 Functionality Scope** The **Department Responses** section serves as a consolidated interface for tracking NOC submissions and financial dues from all departments involved in the dealer’s Full & Final (F&F) settlement. It provides Finance and DD teams with a transparent view of each department’s clearance status, whether the department owes a payment to the dealer ( _Payable_ ) or the dealer owes the department ( _Recovery_ ). This enables complete financial visibility before the final settlement summary is prepared. **10.2.2 Width** This module connects all **functional departments (up to 16 units)** including Sales, Service, Parts, Finance, Warranty, Marketing, HR, IT, Legal, Logistics, and Quality. Each department inputs its clearance data — marking whether any dues exist — and provides supporting remarks or payable/recovery amounts. The respective department person will login and fill his respective amount. **10.2.3 Depth** - **Status Indicators:** Each department’s submission is color-coded and categorized as: o 🔴 _Dues_ – Outstanding amount identified. ``` o 🟢 No Dues – Cleared with no financial impact. o ⚪ Pending – Awaiting departmental response or review. ``` - **Amount Details:** When dues are identified, the department specifies the **Amount Type** (Payable or Recovery) and corresponding **Value** , which directly contributes to the Finance team’s final calculation matrix. - They will login with there respective account and fill the details. - **Remarks Section:** Every response includes contextual remarks for clarity, such as “Outstanding amount identified” or “Cleared,” ensuring traceable communication between departments and Finance. **10.2.4 Personas-wise Accessibility & Visibility** ``` Persona Role in this Section Access Level Finance Reviews all departmental submissions, verifies payable/recovery entries, adds notes. ``` ``` Full Access ``` ``` Departments (16 Units) ``` ``` Submit NOC, mark dues/no-dues, enter remarks, and upload proofs if applicable and add amount (if any) ``` ``` Edit / Submit ``` ``` DD-Lead / DD- Admin ``` ``` Monitors overall progress of departmental responses and follows up on pending inputs. ``` ``` View / Comment Legal / NBH / ZBH Verify final status before case closure. View Only ``` ## 11 Finance Dashboard The **Finance Dashboard** provides a unified workspace for managing all financial activities related to dealer onboarding and offboarding. It gives Finance users complete visibility into **pending verifications, approved transactions, and Full & Final (F&F) settlements** across both Resignation and Termination cases. The dashboard is divided into two key segments — **Onboarding** , which focuses on verifying dealer security deposits and initial payments made via RTGS or NEFT, and **F&F Settlement** , which consolidates all department-wise responses, calculates final payable or recoverable amounts, and facilitates settlement approvals. ### 11.1 Finance Dashboard Page **11.1.1 Functionality Scope** The **Finance Dashboard** serves as the centralized workspace for the Finance team to verify dealer-related financial transactions and settlements — both during onboarding and offboarding processes. It ensures end-to-end visibility of **Security Deposit verifications** for new dealerships and **Final F&F settlements** for dealers resigning or terminated, thereby providing financial traceability across the dealership lifecycle. The dashboard operates in two distinct functional tabs: - **Onboarding:** For validating advance payments (Security Deposit, Initial Fees, etc.) submitted by dealers during application onboarding. - **F&F Settlement:** For managing Final Settlement workflows upon **Resignation** or **Termination** , involving multi-department inputs and Finance validation before closure. The system provides summarized counters for quick insights — _Pending Verification_ , _Verified Payments_ , _Pending F&F Summaries_ , and _Completed F&F_ — enabling Finance to prioritize action items efficiently. **11.1.2 Width** The Finance Dashboard is cross-functional, connecting the following stages and roles: - **During Onboarding:** o Receives dealer payment data (Security Deposit, Bank Details, Transaction ID, Mode of Payment, etc.). o Enables Finance users to verify authenticity of RTGS/NEFT transactions by cross- checking with corporate account statements. o Allows upload of verified transaction proof or remarks in case of mismatch. - **During Offboarding (Resignation / Termination):** o Auto-fetches the list of dealers approved for exit by NBH and Legal. o Tracks the **F&F Summary** preparation status and department responses. o Consolidates financial liabilities, recoverables, or pending clearances. o Generates a unified view of financial closure and triggers completion once all departments respond. The dashboard integrates with **Legal** , **DD-Admin** , and **DD-Lead** modules to ensure that once a dealer exit is approved, the Finance team receives all relevant data automatically for settlement initiation. **11.1.3 Depth** ``` 11.1.3.1 Onboarding – Payment Verification ``` - **Initiation:** Dealer payment details (Security Deposit, Mode of Payment, Transaction ID, and Bank Name) are captured during onboarding. - **Verification Process:** o Finance validates the transaction against company account records. o Uploaded documents like **Payment Receipt** or **Bank Statement** are reviewed. o Finance user confirms verification by entering the verified transaction ID, received date, and remarks. - **System Actions:** o On successful verification, payment status updates to **Verified** , triggering an email + in-app notification to DD-Admin and DD-Lead. o If discrepancies are found, Finance can flag the payment for review with remarks in Work Notes. - **Dashboard Counters:** o **Pending Verification:** Lists all onboarding payments awaiting Finance confirmation. o **Verified:** Displays successfully validated payments along with transaction logs and verifier details. ``` 11.1.3.2 Offboarding – F&F Settlement Summary ``` - **Trigger:** Once Legal uploads the **Resignation Acceptance** or **Termination Letter** , the case automatically appears in the Finance Dashboard under _F&F Settlement._ - **Process Flow:** 1. System collates the **Dealer Exit Case (Resignation/Termination)** details. 2. Pulls financial obligations, pending dues, recoverables, and credit balances from connected departments (e.g., Parts, Apparel, DMS, Marketing). 3. Displays a departmental response tracker (e.g., _16/16 Departments Responded_ ). 4. Finance reviews the consolidated data and creates the **Final Settlement** **Summary**. 5. On approval, status changes from _Pending Finance Summary_ to _Completed_ and the record is archived for reporting. - **Work Note & Communication:** 1. Finance can use the **Work Notes** tab to tag DD-Lead, Legal, or Admin in case clarifications are needed. 2. Each note gets timestamped and appears under **Audit Trail** for traceability. 3. Upon finalization, a system-generated confirmation triggers notification to DD- Admin for closure. - **Automation & Notifications:** 1. SLA reminders alert Finance for pending verifications nearing expiry. 2. Status changes (Pending → Verified / Completed) are reflected across modules instantly. **11.1.4 Personas-wise Accessibility & Visibility** ``` Persona Responsibilities & Actions Access Level ``` ``` Finance (Primary Owner) ``` ``` Verify onboarding payments, review RTGS details, create and approve F&F summaries, add Work Notes. Full Access^ ``` ``` DD-Admin Upload payment proofs during onboarding, upload dealer reply or Legal letters during offboarding, view Finance remarks. ``` ``` Upload / View ``` ``` DD-Lead ``` ``` Review verified payment records, view F&F progress, respond to Finance queries in Work Notes. ``` ``` View / Comment Legal Cross-reference Finance completion before case closure. View Only ``` ``` NBH / ZBH Monitor high-level financial progress for terminated or resigned dealers. ``` ``` View Only ``` ``` Dealer (Read-only) ``` ``` Can view payment verification and F&F closure confirmation in dealer portal. Once a dealer resigns or is terminated , portal access is permanently revoked , preventing any further system interaction. ``` ``` View Only ``` ### 11.2 F&F Settlement Module **11.2.1 Functionality Scope** The **Full & Final (F&F) Settlement module** enables Royal Enfield’s Finance division to execute, validate, and document the final financial closure of any dealer account following **Resignation** or **Termination** approval. It consolidates all monetary data — payables, receivables, deductions, and department-wise clearances — into a unified interface for transparent and compliant settlement processing. The module provides a structured workflow that ensures all dependencies are cleared across departments, settlement calculations are system-validated, and final payouts or recoveries are accurately recorded with bank transaction details. The process is fully integrated with Legal, Dealer Development (DD), and Admin workflows, ensuring that once a dealer exit is approved, the F&F process is automatically triggered within defined SLAs. **11.2.2 Width** The F&F module covers both **Resignation** and **Termination** closure workflows, integrating all stakeholders and systems that influence the final settlement outcome. - **Dealer Development (DD-Lead / DD-Admin):** Triggers F&F process after Legal uploads the acceptance or termination letter. - **Finance:** Leads the overall settlement process, validates departmental inputs, performs reconciliation, and confirms final payment or recovery transactions. - **Departments (16 Functions):** Submit NOC and financial inputs through automated task prompts (e.g., Parts, Service, Apparel, HR, Legal, Quality, Marketing, IT, Logistics, etc.). - **Legal:** Verifies F&F completion before case closure and maintains compliance documentation. - **Admin:** Uploads settlement proof and coordinates with Finance for record finalization. This ensures that no dealer account is financially closed until all clearances, proofs, and validations are in place. **11.2.3 Depth** ``` 11.2.3.1 Case Overview and Summary ``` Each F&F case is system-generated with a unique ID (e.g., _FNF- 2024 - 001_ ). Key case metadata displayed includes: - Dealer name, code, and location - Termination type (Resignation / Termination) - Submitted and due dates - Associated domain and sales/service codes - Case age and current status ( _Pending Finance Review_ , _Completed_ ) A **Net Payable / Receivable Indicator** at the top visually represents whether the company owes payment to the dealer or vice versa. For example: _Payable to Dealer – ₹9,75,000_ indicates a net payout scenario after adjustments. ``` 11.2.3.2 Department-wise Clearance Tracking ``` This section provides a real-time tracker of department responses and clearances. It includes: - **Progress Bar:** Displays total responses received vs. pending (e.g., _12 of 16 departments_ _responded_ ). - **NOC Statuses:** o _NOC Submitted_ – Department confirms zero dues. o _Dues Pending_ – Department flags financial obligations. o _Pending_ – Awaiting department review. - **Response Details Table:** Lists each department with submitted date, clearance remarks, and any recovery or payable amount. - **Response Guidelines Panel:** Summarizes submission protocols and auto-reminder SLAs. Departments with dues or recovery inputs automatically impact the **Receivable / Deduction Summary** under Finance Calculation. ``` 11.2.3.3 Financial Calculation Summary ``` Finance users can view, verify, and edit financial items categorized into **three structured sections:** ``` 11.2.3.4 Payables to Dealer (Editable) ``` Represents refundable amounts due from the company to the dealer, such as: - Security Deposit refund - Inventory valuation - Equipment and fixture reimbursements - Outstanding credit notes Finance users can add new line items with department tags and descriptions. Each editable record auto-calculates into the total payables panel. ``` 11.2.3.5 Receivables from Dealer (Editable) ``` Captures outstanding recoverables and pending dues, including: - Outstanding invoices (Sales / Parts / Service) - Marketing recoveries - HR or Finance advances - Compliance or penalty adjustments Each record can be added, edited, or deleted before final review. ``` 11.2.3.6 Deductions (Editable) ``` Represents contingent deductions such as: - Pending warranty claims - Policy violations - Miscellaneous settlements Each item’s description, department, and value feed into the **Total Deductions** summary. ``` 11.2.3.7 System-Calculated Formula ``` At the bottom, a dynamic calculation displays: ``` Net Settlement = Total Payables – Total Receivables – Total Deductions ``` A positive balance indicates _Payable to Dealer_ ; a negative balance indicates _Recovery from Dealer_. ``` 11.2.3.8 Settlement Verification Panel ``` Located on the right side, this panel captures the **final transaction details** once the Finance review is complete. Fields include: - **Payment Mode:** NEFT / RTGS / Cheque - **Transaction / Reference ID:** Corporate transaction number - **Bank Reference Number:** Optional for verification - **Settlement Amount & Adjustments:** Auto-fetched from calculation summary - **Settlement Date:** Date of transfer or adjustment posting - **Verification Remarks:** For audit or cross-team comments Finance can then take one of three workflow actions: - **Approve Settlement:** Marks case as “Finance Approved.” - **Request Clarification:** Sends query back to DD-Lead or Admin with remarks. - **Reject Settlement:** Moves case to “Returned for Correction” with detailed reason. Each action automatically logs under **Audit Trail** and triggers email + system notifications. ``` 11.2.3.9 Documents Section ``` This tab centralizes all artefacts submitted or generated during the F&F process. It includes: - Dealer documents (e.g., _Resignation Letter_ , _Asset Handover Receipt_ , _Inventory_ _Report_ , _Bank Statement_ ). - Uploaded proofs by Finance (e.g., _Settlement Proof, Payment Receipt_ ). - Legal or DD attachments for traceability. A **drag-and-drop upload zone** allows Finance or Admin to attach additional records (PDF, DOC, XLSX, JPG) up to 10 MB each. Each file is logged with: - File name and type - Upload date and user - Download option for audit access ``` 11.2.3.10 Bank Details Tab ``` Displays dealer bank information to validate payment transfer: - Account holder name - Account number - IFSC and branch name - Bank name A system alert prompts the verifier to validate details before disbursing payment: _“Bank Verification Required – Please confirm bank account before processing settlement.”_ ``` 11.2.3.11 Settlement Checklist ``` A final control checklist ensures financial compliance before marking the case as complete. It includes mandatory checks for: - Verification of all financial calculations - Confirmation of bank account details - Review of all department responses - Upload of settlement proof - Entry of accurate transaction information All checklist points must be validated before the “Approve Settlement” button becomes active. **11.2.4 Work Notes & Communication Flow** - Every clarification, remark, or inter-team discussion is captured through the **Work** **Note** feature integrated into the F&F module. - Finance, DD-Lead, and Legal can tag specific users (e.g., _@Admin_ , _@Legal_ ) to address pending actions. - Notes are timestamped and visible in the case timeline. - Work Notes become part of the permanent **Audit Trail** and ensure transparent communication without relying on emails. **11.2.5 Personas-wise Accessibility & Visibility** ``` Persona Responsibilities Access Rights ``` ``` Finance (Primary Owner) ``` ``` Review, calculate, and approve final settlements; update transaction details; upload settlement proof; communicate via Work Notes. ``` ``` Full Access ``` ``` DD-Admin Upload dealer responses, asset handover, and supporting docs; coordinate with Finance for closure. ``` ``` Upload / View DD-Lead Review and confirm financial summaries; respond to clarifications. ``` ``` Review / Comment Legal Validate compliance and verify settlement proof before closure. ``` ``` View / Comment Departments (16 Units) ``` ``` Submit NOC, recovery, or clearance via linked tasks. Limited Edit Access NBH / ZBH / DD- Head ``` ``` Monitor overall settlement status and amount trends. View Only ``` ``` Dealer (Read- only) ``` ``` View F&F confirmation and settlement proof post-closure. View Only ``` ## 12 Dealer Persona The Dealer Self-Service module empowers **onboarded dealers** with controlled, role-based access to initiate and track key post-onboarding lifecycle requests through a unified portal. Dealers are enabled to **initiate dealership resignation, request relocation to a new location, and submit constitutional change requests** , each governed by structured workflows, mandatory documentation, and defined approval hierarchies. ### 12.1 Dealer Resignation **12.1.1 Functionality Scope** This functionality enables a **dealer to initiate, track, and manage dealership resignation requests** through the portal after successful onboarding. The system provides a **guided resignation submission experience** , outlet-level visibility, and a transparent approval journey supported by **Work Notes–based communication, audit logging, and role-based governance controls**. Dealers are permitted to **withdraw a resignation request only until the case is pending with the National Business Head (NBH)**. **12.1.2 Functional Width** - Displays a **dealer-facing resignation dashboard** with summary indicators: o Total Outlets o Active Outlets ``` o Pending Resignations ``` - Lists all **dealer-owned outlets** with: o Outlet name and code o Address and city o Establishment date o Current operational status - Enables **outlet-level resignation initiation** - Prevents **multiple resignation requests** for the same outlet - Displays **“Resignation in Progress – View Request”** when a request already exists - Provides a **detailed resignation view** with: o Request details o Operational and commercial information o Uploaded documents o Progress timeline o Audit trail - Allows **resignation withdrawal** based on workflow stage eligibility - Displays **informational guidance** related to F&F settlement and departmental clearances **12.1.3 Functional Depth** - The system allows resignation initiation **only for active and eligible outlets**. - On selecting **“Request Resignation”** , the dealer is presented with a structured submission form capturing: o Resignation type o Last Operational Date – Sales o Last Operational Date – Services o Reason for resignation o Optional additional information - Outlet information (code, name, type, city, address) is **auto-populated and non-editable**. - The **Last Working Day (LWD)** entered during submission is stored as the **authoritative** **reference date** for downstream processing. - Upon submission, the resignation request progresses through a **multi-level approval** **workflow** , typically involving: o DD ASM o DD ZM / RBM o ZBH o DD Lead o DD Head o NBH o Legal - Each stage is reflected in a **visual progress timeline** , including: o Stage status ``` o Action date o Uploaded document count ``` - Authorized internal users can **Approve, Send Back, or Revoke** the resignation request. - **Send Back and Revoke actions are communicated exclusively through Work Notes** , with **mandatory remarks** captured by the system. - The **dealer is allowed to withdraw the resignation request only until the case is pending** **with NBH**. - Once the resignation request **moves beyond the NBH stage** , the **withdrawal option is** **disabled** by the system. - Withdrawal actions are: o Time-stamped o Logged in the audit trail o Communicated to relevant internal stakeholders - Upon completion of approvals, the **Legal team issues the official Resignation Acceptance** **Letter**. - The **Full & Final (F&F) settlement process is triggered strictly on the Last Working Day** **(LWD)** and **not based on the approval date**. - After resignation closure: o The outlet is marked as closed o **Dealer portal access is revoked** as per access control policy - All actions, documents, remarks, and transitions are **captured for audit and compliance** **purposes**. **12.1.4 Personas-wise Accessibility & Visibility** ``` Persona Responsibilities Access Rights Dealer Initiates and tracks resignation requests for owned outlets. ``` - View outlet list and resignation status - Initiate resignation request - Submit resignation details and documents - View progress timeline, Work Notes, and audit trail - **Withdraw resignation request only until the case is pending with NBH** - No approval, send back DD ASM Supports coordination and documentation during resignation processing. - View resignation requests - Upload supporting documents - Participate in coordination activities DD ZM Performs zonal-level review and validation. - View resignation requests - Review and provide inputs ``` RBM Performs regional business review. • View resignation requests ``` - Review and recommend ZBH Ensures zonal governance and decision alignment. - Review resignation requests - Send Back or Revoke with mandatory Work Notes - Approve as per hierarchy DD Lead Ensures process adherence and cross- functional alignment. - Review resignation requests - Send Back or Revoke with mandatory Work Notes - Approval visibility DD Head Oversees dealer development governance. - Review resignation requests - Send Back or Revoke with mandatory Work Notes - Approve as per hierarchy NBH Provides senior business oversight. • Review resignation requests - Send Back or Revoke with mandatory Work Notes - Final approval authority Legal Team ``` Issues formal resignation closure documentation. ``` - Issue Resignation Acceptance Letter - View complete resignation details System Enforces workflow rules and compliance. - Control action availability - Trigger notifications - Initiate F&F on LWD - Maintain audit trail ### 12.2 Dealer Constitutional Change Management **12.2.1 Functionality Scope** This functionality enables a **dealer to initiate, track, and manage requests for change in business constitution** through the portal after successful onboarding. The system provides a **structured self-service mechanism** to propose constitution changes, capture legally required information, and submit **constitution-specific mandatory documents** , while routing the request through a **defined internal review and approval workflow**. **12.2.2 Functional Width** - Displays a **dealer-facing constitutional change dashboard** with summary indicators: o Total Requests o Pending Requests ``` o Completed Requests ``` - Lists all **constitution change requests** with: o Request ID o Current constitution o Proposed constitution o Submission date o Current status o Progress percentage - Enables **initiation of a new constitutional change request** - Supports the following **constitution change cases** : o Proprietorship (Single Owner) → Partnership o Proprietorship → LLP (Limited Liability Partnership) o Proprietorship → Private Limited o Partnership → LLP o Partnership → Private Limited o Private Limited → LLP o Private Limited → Partnership - Dynamically determines **mandatory document requirements** based on the **target** **constitution** - Allows **document upload only as per applicable case** - Provides **role-based visibility** into request details, documents, and progress - Prevents duplicate or parallel requests as per policy **12.2.3 Functional Depth** - Constitutional change requests can be initiated **only for active and eligible dealers**. - On selecting **“New Constitutional Change”** , the dealer is presented with a structured submission form capturing: o Dealer Code and Dealer Name (auto-populated, non-editable) o Current constitution (auto-populated) o Proposed constitution (selectable from allowed options) o Reason for change o Details of new partners / members (where applicable) o Proposed shareholding pattern - Based on the **proposed constitution** , the system determines the **mandatory document** **checklist** as follows: **12.2.4 Document Applicability Rules** **A. Any change resulting in Partnership requires:** - GST Registration Certificate - Firm PAN Copy - Self-attested KYC documents - Partnership Agreement (Notarised) - Business Purchase Agreement (BPA) - Firm Registration Certificate (Partnership) - Cancelled Cheque - Declaration / Authorization Letter **B. Any change resulting in LLP requires:** - GST Registration Certificate - Firm PAN Copy - Self-attested KYC documents - Certificate of Incorporation (COI) - Business Purchase Agreement (BPA) - LLP Agreement (Notarised) - Cancelled Cheque - Declaration / Authorization Letter **C. Any change resulting in Private Limited requires:** - GST Registration Certificate - Firm PAN Copy - Self-attested KYC documents - MOA (Memorandum of Association) - AOA (Articles of Association) - Certificate of Incorporation (COI) - Business Purchase Agreement (BPA) - Cancelled Cheque - Declaration / Authorization Letter **D. Any change resulting in Proprietorship requires:** - GST Registration Certificate - Firm PAN Copy - Self-attested KYC documents - Cancelled Cheque - Declaration / Authorization Letter - The system enforces **document completeness validation** before allowing submission or progression. - **No OCR or automated document content extraction** is performed; all validations are **manual and role-driven**. - Upon submission: o The request is routed through a **multi-level internal review workflow** (DD ASM → DD ZM / RBM → ZBH → DD Lead → DD Head → NBH → Legal, as applicable). - Authorized internal roles may **Approve, Send Back, or Revoke** the request. - **Send Back and Revoke actions are communicated through Work Notes** , with mandatory remarks. - The **Legal team validates statutory compliance** and facilitates updates to dealer master records post-approval. - Upon final approval: o Dealer constitution details are updated in the system of record. o All actions, documents, and decisions are **logged for audit and compliance**. **12.2.5 11.2.4 Personas-wise Accessibility & Visibility** ``` Persona Responsibilities Access Rights Dealer Initiates and tracks constitutional change requests. ``` - Initiate new constitutional change request - Provide change details and reasons - Upload mandatory documents as per applicable case - View request status, progress, and Work Notes DD ASM Coordinates document collection and supports validation. - View requests - Upload supporting documents - Assist in coordination DD ZM Performs zonal-level review and validation. - View requests - Review and provide inputs RBM Conducts regional business evaluation. • View requests - Review and recommend ZBH Ensures zonal governance compliance. • Review requests - Send Back or Revoke with mandatory Work Notes - Approve as per hierarchy DD Lead Ensures adherence to dealer development policies. - Review requests - Send Back or Revoke with mandatory Work Notes - Approval visibility ``` DD Head Oversees dealer development governance. ``` - Review requests - Send Back or Revoke with mandatory Work Notes - Approve as per hierarchy NBH Provides senior management approval. • Review requests - Send Back or Revoke with mandatory Work Notes - Final approval authority Legal Team ``` Validates statutory compliance and legal documentation. ``` - Review documents - Validate compliance - Facilitate post-approval updates System Enforces rules and audit compliance. • Determine applicable documents dynamically - Validate completeness (no OCR) - Track progress and status - Maintain audit trail Dealer Relocation Request **12.2.6 Functionality Scope** This functionality enables a **dealer to initiate, track, and manage dealership relocation requests** through the portal after successful onboarding. The system provides a **guided self- service mechanism** to propose a new dealership location, submit **location-specific statutory, property, and infrastructure documents** , and route the request through a **multi-level internal approval workflow**. **12.2.7 Functional Width** - Displays a **dealer-facing relocation dashboard** with summary indicators: o Total Requests o Pending Requests o Completed Requests - Lists all **relocation requests** with: o Request ID o Current location o Proposed location o Distance from current location o Submission date o Current status o Progress percentage - Enables **initiation of a new relocation request** - Allows **manual address entry** or **map-based location selection** for the proposed site - Captures **distance from the existing location** - Provides **request-level detailed view** including: o Relocation overview o Submitted information o Workflow progress ``` o Required and uploaded documents o History & audit trail ``` - Supports **document upload, verification, and status tracking** - Provides **role-based visibility and action controls** - Prevents parallel or duplicate relocation requests for the same outlet **12.2.8 11.3.3 Functional Depth** - Relocation requests can be initiated **only for active and eligible dealerships**. - On selecting **“New Relocation Request”** , the dealer is presented with a structured submission form capturing: o Dealer Code and Dealer Name (auto-populated, non-editable) o Current dealership address (auto-populated) o Proposed new location (manual entry or map selection) o Complete address details (city, state, pincode) o Distance from the current location o Property type o Expected relocation date o Reason for relocation - Upon submission, the request enters a **multi-level approval workflow** , typically progressing through: o DD ASM Review o RBM Review o DD ZM Review o ZBH Review o DD Lead Review o NBH Review o Legal (as applicable) - Each stage is reflected through a **visual workflow progress timeline** , showing: o Responsible role o Stage status (Completed / In Progress / Pending) o Overall progress percentage - The system enforces **mandatory document submission and verification** , categorized as: o Property o Legal o Statutory o Infrastructure - Required documents include, but are not limited to: o Property documents for new location o Lease / Rental agreement for new location o NOC from current landlord o Municipal approvals ``` o Fire safety certificate o Pollution clearance o Layout / Floor plan of new location o Photos of new location o Locality map o Building plan approval o Electricity connection documents o Water supply documents ``` - Document status is tracked as **Pending Verification** , **Verified** , or **Rejected**. - Authorized internal users may **Approve, Send Back, or Revoke** the relocation request. - **Send Back and Revoke actions are communicated through Work Notes** , with mandatory remarks captured by the system. - All uploads, verifications, remarks, and approvals are **logged in the audit trail**. - Upon final approval: o The relocation request is marked as completed. o Dealer master records are updated as per the approved new location. - The system ensures **full traceability and compliance** across all stages of the relocation process. **12.2.9 11.3.4 Personas-wise Accessibility & Visibility** ``` Persona Responsibilities Access Rights Dealer Initiates and tracks dealership relocation requests. ``` - Initiate relocation request - Provide proposed location details - Upload required documents - View request status, workflow progress, and Work Notes DD ASM Coordinates initial review and document readiness. - View relocation requests - Upload and review documents - Support coordination RBM Performs regional feasibility and business review. - View requests - Review and recommend DD ZM Conducts zonal-level evaluation. • View requests - Review and provide inputs ZBH Ensures zonal governance and compliance. - Review requests - Send Back or Revoke with mandatory Work Notes - Approve as per hierarchy DD Lead Ensures policy adherence and cross- functional alignment. - Review requests - Send Back or Revoke with mandatory Work Notes - Approval visibility ``` NBH Provides senior management approval. • Review requests ``` - Send Back or Revoke with mandatory Work Notes - Final approval authority Legal Team ``` Validates statutory and legal compliance. ``` - Review legal documents - Validate approvals and clearances System Enforces workflow and compliance rules. - Control action availability - Track document status and progress - Maintain history and audit trail ## 13 Non-Functional Requirements ``` Category Requirement Performance Average response time < 3 seconds for standard operations. Scalability Should scale horizontally on GCP. Security JWT tokens, encrypted passwords, HTTPS enforced. Usability Intuitive UI, consistent icons, and simple navigation. Reliability 99% uptime target. Backup & Recovery Daily database backup and weekly full snapshot. Compliance Follows RE IT data privacy guidelines. ``` ## 14 Technology Matrix ``` Component Specification Database PGSQL (Managed or local instance) Application Stack Node.js (Backend) + React.js (Frontend) Authentication RE SSO Bridge ``` ## 15 Infra requirements & System Hygiene ``` Component Specification Environment QA / Testing # of Virtual Machines (VMs) 1 CPU Configuration 4 - Core Memory (RAM) 16 GB Disk Size 500 GB Operating System Ubuntu 24.04 LTS ``` ``` Storage Type Cloud ``` Backup and Recovery - Daily incremental and weekly full backups. - Restore process must not exceed 2 hours. ## 16 Not in scope Anything which comes beyond the scope defined above in terms of Width and depth