Dealer_Onboarding_Backend/docs/modular_wise/01_Dealer_Onboarding.md

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)
• At this stage, department-claimed amounts are frozen and become read-only for departments.
• Finance does not overwrite department claim values. Instead, Finance validates each row in a dedicated validation layer by recording:
  • Finance decision (Accepted / Partially Accepted / Rejected / Under Clarification)
  • Finance-validated amount
  • Variance amount and mandatory variance reason (if changed)
  • Supporting proof/document
• The system automatically calculates:
  • Net Settlement = Total Payables – Total Receivables – Total Deductions
  • Final totals are computed from finance-validated values only.
• 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.

---

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