# 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?”_

---

## 7 Dealer Resignation

The **Dealer Resignation** process enables an existing Royal Enfield dealer to formally

initiate their intent to discontinue the dealership through a structured and transparent
workflow. This process captures the dealer’s resignation details, reasons for exit, and
proposed timeline, ensuring all associated departments — including **DD-Admin, DD-**

**Head, Finance, Legal, and Regional Teams** — are informed and involved in the validation
and clearance stages. Each resignation request undergoes systematic review, covering

asset recovery, financial reconciliation, documentation verification, and contractual
obligations before final approval and closure.


### 7.1 Dealer Resignation Request (Initiation)

**7.1.1 Functionality Scope**

The **Dealer Resignation Request** process begins when a dealer formally communicates their
intent to resign via an **official email** to ASM. Once received, the **DD-ASM** initiates the resignation
process in the system by creating a digital record using the _Create Resignation Request_ form. The
form captures critical dealership, operational, and contextual information — such as business
constitution, sales data, and closure type — ensuring that the request is documented in a
structured, traceable, and standardized manner. This process establishes a single source of truth
for all resignation-related data, facilitating transparent coordination among **DD-Head, Finance,
Legal, and Regional Teams** for subsequent review and action. Dealer can login exclusively and
can only initiate the Resignation request.

The **Dealer Resignation Request is initiated by the dealer through the portal** , providing a
structured mechanism to formally submit the intent to discontinue the dealership. The dealer
captures resignation details, reason for exit, and the proposed effective date. Upon submission,
the request is routed to the internal stakeholders for review, validation, and subsequent
clearance processes. The **dealer logs into the portal and initiates the resignation request** by
submitting the required details and supporting information.


**7.1.2 Width**

- Accessible exclusively to **DD-ASM** through the **“Create Resignation Request”** interface.
- Includes the following mandatory and optional input fields:
    o **Dealer Code** (it will be fed to SAP API to pull details.)
    o **Inauguration** , **LOA** , and **LOI Dates** (Will be fetched from system DB, if available)
    o **Last 6 Months Sales**
    o **Number of Dealerships / Studios**
    o **Constitution** (Proprietorship, Partnership, LLP, Pvt. Ltd., etc.)
    o **Dealership Type** (Main, Satellite, Studio, etc.)
    o **Type of Closure** (Voluntary, Business Transfer, Termination, etc.)
    o **Format Category** (Urban, Rural, etc.)
    o **Dealer Scorecard Band**
    o **Resignation Reason** (brief summary)
    o **Dealer Voice** (detailed justification or remarks from dealer’s email)
    o **Upload Document** (resignation email copy or supporting documents)
- **Buttons:**
    o **Submit Request:** validates data and triggers routing to the next stage of review.
    o **Cancel:** exits without saving.

**7.1.3 Depth**

- Upon submission by **DD-Admin** , the system performs the following
    o Validates the **Dealer Code** against the dealership master from SAP API to be
       provided by RE
    o Generates a unique **Resignation Request ID** and logs submission details
       (timestamp, user, and role).
    o Stores the uploaded resignation email or document in the **Central Document**
       **Repository** for reference.
    o Automatically notifies the **DD-Head** and relevant stakeholders that a new
       resignation has been logged.
    o Marks the case status as **“Resignation Initiated”** in the workflow tracker.
    o He will also upload the resignation PPT which is build off the system.

**7.1.4 Personas-Wise Accessibility & Visibility**

```
Persona Accessibility Visibility Scope
Dealer /
Applicant
```
```
Sends official resignation email to Royal Enfield.
The dealer is provided portal access to upload
resignation-related documents and
responses during the applicable workflow
stages.
```
```
Email communication
only (no direct system
access).
```

```
For termination cases, dealer upload access is
restricted as per defined governance rules.
DD-Admin/DD-
ASM
```
```
Creates resignation request in system, uploads
dealer’s email, validates data, and submits for
approval.
```
```
Full access for initiation.
```
```
DD-Head / ZBH
/ NBH
```
```
Receives system notification upon submission;
can view request details and attached
resignation communication.
```
```
Read-only visibility at
initiation stage.
```
```
System
(Automation)
```
```
Validates dealer code, generates request ID, logs
submission details, and triggers workflow
routing.
```
```
Background operation.
```
### 7.2 Resignation Management Dashboard

**7.2.1 Functionality Scope**

The **Resignation Management Dashboard** serves as the central workspace for monitoring and
managing all dealer resignation requests initiated within the system. It provides a consolidated
view of active, pending, and completed cases, enabling stakeholders such as **DD-Admin, ASM,
DD-Lead, ZBH, NBH, and Legal Teams** to review progress, take required actions, and ensure
compliance with the defined offboarding workflow.

The **ZBH can review resignation requests and perform Send Back or Revoke actions** prior to final
approval. Each action requires **mandatory remarks** and is recorded against the resignation case.


RBM, **ZBH, DD-Lead, DD-Head, and NBH** can review resignation requests and are authorized
to **Send Back or Revoke** requests at their respective stages. All such actions require **mandatory
remarks** and are logged for audit purposes.

**7.2.2 Width**

- Displays a **summary header** with following key counters:
    o **All Requests:** Total number of resignation requests recorded.
    o **Open:** Requests currently under review or action.
    o **Completed:** Finalized resignations where closure is approved.
    o **Requires Your Action:** Highlights cases awaiting action from the logged-in user.
- Shows a **list view** of all resignation requests with the following details:
    o **Request ID (e.g., RES-001)**
    o **Dealer Name, Dealer Code, and Location**
    o **Format Category** (A+, A, B, etc.)
    o **Dealership Type** (Main, Studio, etc.)
    o **Reason for Resignation**
    o **Current Stage** (e.g., ASM Review, DD-Lead Review, NBH Approved, Legal)
    o **Submitted On** (auto-captured timestamp)
- Action options:
    o **View Details:** Opens complete resignation record and attached documents.
    o **Create Resignation Request:** Accessible only to **DD-Admin** for entering new
       requests (from dealer emails).
- Filter tabs:
    o **All Requests** , **Open** , **Completed**

**7.2.3 Depth**

- **Workflow Synchronization:** Each resignation request dynamically updates its stage label
    (e.g., _ASM Review_ , _DD-Lead Review_ , _NBH Approved_ ) based on workflow transitions.
- **Notification Logic:**
    o The assigned reviewer (ASM, DD-Lead, or NBH) receives automated alerts for
       action items.
    o Status changes trigger notifications to the next role in sequence.

**7.2.4 Personas-Wise Accessibility & Visibility**

```
Persona Accessibility Visibility Scope
DD-Admin/DD-ASM Can create new resignation requests, view all
regional cases, and track progress.
```
```
Full access
within Area.
```

```
ASM / DD-Lead Can review, comment, and forward resignation
requests to next approver.
```
```
Assigned
requests only.
ZBH / NBH / Legal /
Finance
```
```
Can view status, add remarks, and take action at
their respective workflow stage.
```
```
Role-based
access by stage.
System
(Automation)
```
```
Updates request stages, triggers notifications, and
logs all workflow events.
```
```
Background
process.
Regional Business
Manager (RBM)
```
```
The RBM reviews and validates dealer lifecycle
requests , and has review, send back, and
escalation authority as per workflow stage.
```
### 7.3 Resignation Details & Review

**7.3.1 Functionality Scope**

The **Resignation Details & Review** module provides a comprehensive view of all dealer
resignation information captured during initiation. It enables authorized reviewers to validate
dealer data, evaluate the reason and context for resignation, and take appropriate workflow


actions such as **Approval, Withdrawal, Send Back, or Push to Full & Final (F&F)**. The screen
consolidates dealer master data, operational metrics, and resignation specifics, ensuring
reviewers have complete visibility before making decisions.

**7.3.2 Width**

- **Header Actions:**
    o **Approve:** Marks resignation as validated and forwards it to the next workflow
       stage (DD-Head / NBH).
    o **Withdrawal:** Used if the dealer retracts the resignation request or if withdrawal
       is approved internally.
    o **Send Back:** Returns the request to DD-Admin for correction or additional details.
    o **Push to F&F:** Moves the case to the **Full & Final Settlement** process after all
       approvals are secured.
    o **Assign User:** Allows reallocation of review responsibility to another internal user.
    o **View Work Notes:** Opens the shared comment thread for internal collaboration
       and tagging.
- **Tabs:**
    o **Details** – Displays complete resignation information and dealer data.
    o **Progress** – Shows stage-wise workflow journey and current reviewer.
    o **Documents** – Lists uploaded resignation documents and correspondence.
    o **Audit Trail** – Records every action, decision, and timestamp for traceability.

**7.3.3 3. Depth**

- **Information Segments:**
    o **Request Information:** Pull dealer master details such as Dealer Code, GST,
       Address, Domain & Service Codes, City Category, and Dealership Name.
    o **Operational Details:** Displays dealership metrics including inauguration and LOA
       dates, number of outlets, last six-month sales, business constitution, format
       category, and dealer scorecard band.
    o **Resignation Details:** Summarizes the **Resignation Reason** and **Dealer Voice**
       **(Customer Description)** derived from the dealer’s email submission.

**7.3.4 4. Personas-Wise Accessibility & Visibility**

```
Persona Accessibility Visibility Scope
DD-Admin Read-only at this stage; may receive “Send
Back” tasks for correction.
```
```
Region-specific
requests.
```

```
ASM / DD-Lead / DD-
Head / ZBH / NBH
```
```
Can review, approve, withdraw, or forward
resignations to next stage; can add remarks
and push to F&F.
```
```
Requests assigned to
their hierarchy.
```
```
System (Automation) Logs workflow actions, timestamps, and user
activity; triggers stage transitions and
notifications.
```
```
Background
operation.
```
### 7.4 Resignation Request Review & Action Management

**7.4.1 Functionality Scope**

The **Resignation Progress Timeline** provides a transparent, stepwise view of the dealer
resignation workflow — from initial submission to the issuance of the final **Acceptance Letter**.
Since the **Dealer does not have portal access** for resignation, the process starts through an **email
submission to the Area Sales Manager (ASM)** , followed by progressive reviews and comments
at multiple organizational levels. Each approver in the chain can perform one of three key actions
— **Approve** , **Send Back for Clarification** , or **Withdraw** — with remarks captured in **Work
Notes** for audit and traceability. Once approved by the **National Business Head (NBH)** , the
request automatically routes to the **Legal Team** for the issuance of the acceptance letter, visible
to both the DD Admin and DD-ASM.

The **dealer is provided portal access** to **upload resignation-related documents and
responses** during the applicable workflow stages. For termination cases, **dealer upload access is
restricted** as per defined governance rules.

**7.4.2 Width**

```
7.4.2.1 Stage-wise Flow
Stage Responsible
Role
```
```
System / Process Description
```

1. Dealer
Resignation
Submission

```
Dealer → via
Email to ASM
```
- Dealer submits resignation via official email and
signed letterhead.
- No direct portal access.
- ASM receives and verifies authenticity.
2. ASM Review DD-ASM • Uploads resignation email and presentation
(e.g., _Sample resignation.pptx_ ) to portal.
- Adds remarks summarizing dealer’s reason and
operational background.
- Forwards case to **RBM + DD-ZM** for evaluation.
3. RBM + DD-ZM
Review

```
RBM & DD-ZM • Conduct joint discussion with dealer to understand
cause and alternatives.
```
- Uploads discussion notes and remarks in **Work Notes**.
- The final output will be submitted as Approve,
Withdrawal or send back.
- Has three action options:
- **Approve:** Forwards case to ZBH for further review.
- **Send Back:** Requests ASM to provide additional
details or clarifications (remark mandatory).
- **Withdraw:** Stops process if dealer withdraws or
case found invalid (remark mandatory).
4. ZBH Review Zonal Business
Head
- Reviews RBM + DD-ZM inputs and validates zonal
implications.
- Adds comments in **Work Notes** and forwards to **DD
Lead**.
- Can perform **Approve** , **Send Back** ,
or **Withdraw** actions.
5. DD Lead
Review

```
DD Lead • Prepares a formal Resignation Presentation
PPT summarizing business rationale, sales history,
dealer feedback, and proposed recommendation.
```
- Uploads the presentation and comments to the
portal.
- Approves and shares with **NBH** for final decision.
6. NBH Approval National
Business Head
- Reviews all inputs and puts **final decision remarks** in
Work Notes.
- On approval, system triggers notification to **DD Lead,
ZBH, Zonal Team, Business Zonal Manager, and F&F**.
- Automatically routes the case to **Legal Team** for
Acceptance Letter issuance.
7. Legal Review &
Acceptance Letter

```
Legal Team • Prepares and uploads Resignation Acceptance
Letter on portal.
```
- Can raise queries in Work Notes if required.
- Uploaded document is visible to **DD-Admin** and **DD-**


#### ASM.

- Legal completion closes workflow for the request.
8. DD Admin &
ASM Notification

```
DD Admin +
DD-ASM
```
- DD Admin reviews the uploaded acceptance letter.
- Shares with respective **ASM (Field Team)** to
communicate official closure to the dealer.

**7.4.3 3. Depth**

- **Action Modes Across Stages:**
    o **Approve:** Advances the resignation request to the next level of the workflow.
       _Example:_ “Reviewed with dealer and validated. Forwarding to ZBH for next stage.”
    o **Send Back:** Returns to the previous user or ASM for clarifications.
       _Example:_ “Incomplete documentation. Dealer statement on financials missing.”
    o **Withdraw:** Ends the process if dealer withdraws voluntarily or management
       disapproves continuation.
       _Example:_ “Dealer requested withdrawal of resignation via email dated 15-Oct.”
- **Audit and Transparency:**
    o All actions (including remarks, uploads, and timestamps) are auto-captured
       in **Work Notes** and the **Audit Trail**.
    o Every document and PPT uploaded (e.g., _Sample resignation.pptx_ ) is linked to its
       stage for version tracking.
- **System Automation:**
    o NBH approval automatically triggers Legal assignment.
    o SLA tracking continues at each step; escalation is logged in Work Notes if delayed.
    o Notifications are sent to all relevant stakeholders upon approval, send-back, or
       withdrawal.

**7.4.4 Worknotes**

The **Work Notes** feature acts as the central communication and collaboration thread
within the resignation workflow. It captures all user interactions, remarks, and system-

triggered updates in a structured, time-stamped format. Each stakeholder — from
ASM to NBH and Legal — uses Work Notes to record discussions, queries,

clarifications, and final decisions related to the resignation case will be submitted from
Approval, Withdrawal or send back action.

**7.4.5 Personas-wise Accessibility & Visibility**

```
Role / Persona Responsibilities System Access & Actions
```

```
Dealer (External) Submits resignation via email on company
letterhead.
```
```
No portal access;
communicates via email
only.
DD-ASM (Area
Sales Manager)
```
```
Initiates workflow by uploading resignation
documents, adding dealer background, and
forwarding case.
```
```
Create, view, and
comment rights.
```
```
RBM + DD-ZM Conduct discussion with dealer, upload
remarks, and validate reasons.
```
```
Approve, Send Back,
Withdraw, upload
documents.
ZBH (Zonal
Business Head)
```
```
Validate business impact; forward decision
to DD Lead.
```
```
Approve, Send Back,
Withdraw rights.
DD Lead Consolidates inputs; prepares final
presentation with recommendations for
NBH.
```
```
Approve, Send Back,
Withdraw, upload
presentation.
NBH (National
Business Head)
```
```
Takes final decision; puts remarks in system;
triggers Legal action.
```
```
Final Approval rights.
```
```
Legal Uploads Resignation Acceptance Letter ;
communicates queries in Work Notes.
```
```
Upload and comment
rights; visible to DD Admin
& ASM.
DD Admin Reviews uploaded acceptance letter; shares
with ASM for final dealer communication.
```
```
Read & Download access.
```
```
System
(Automation)
```
```
Triggers notifications, maintains SLA
counters, logs Work Notes & Audit history.
```
```
Automated access only.
```
### 7.5 Resignation Progress Tracker


**7.5.1 Functionality Scope**

The **Progress** section provides a stage-wise, visual representation of the entire dealer resignation
workflow. It enables authorized users to track each approval checkpoint — from **request
submission** through **multi-level review** to **final legal acceptance**. Every stage dynamically
updates based on workflow actions such as _Approve_ , _Send Back_ , or _Withdraw_ , with complete
traceability of remarks, uploaded documents, and timestamps. This ensures full transparency,
accountability, and operational consistency across all hierarchical levels.

**7.5.2 Width**

- Presents a **chronological timeline** of the resignation process, beginning with _Request
Submitted_ and concluding with _Legal – Resignation Letter_.
- Each stage displays **status indicators** (Pending, In Progress, Approved, or Withdrawn) along
with the **responsible reviewer role**.
- Shows the **number of documents uploaded** at each stage, with direct view/download options.
- Allows reviewers to perform three key actions — _Approve_ , _Send Back_ , and _Withdraw_ — with
remarks made mandatory.
- If a request is **Sent Back** , it automatically reverts to the previous stage, recording remarks
in **Work Notes** and notifying the concerned user.
- On **Withdrawal** , the timeline is locked and marked _Closed – Withdrawn_ for historical reference.
- Once **NBH** provides final approval, the request is automatically assigned to **Legal** for
acceptance letter issuance.
- The **Legal stage** finalizes the process upon letter upload, marking the case _Completed_ and
notifying DD-Admin and field hierarchy.

**7.5.3 Depth**

- Each stage retains all **remarks, approvals, timestamps, and supporting documents** for
complete traceability.
- Integrates seamlessly with **Work Notes** and **Audit Trail** , ensuring real-time visibility of all
communications and escalations.
- Supports SLA-driven reminders and escalations that reflect directly in the timeline view.
- All uploaded documents (emails, resignation PPT, acceptance letter) remain permanently
mapped to their respective stages.
- Once the resignation is finalized, historical data stays accessible for compliance and audit
review.


**7.5.4 Personas-wise Accessibility & Visibility**

```
Persona /
Role
```
```
Access Level Permissions / Actions Visibility
```
```
DD-ASM /
AM
```
```
Area Level Uploads the dealer’s resignation
email and supporting PPT;
initiates forwarding for ASM
review.
```
```
Can view current stage and
all preceding
remarks/documents.
```
```
RBM + DD-
ZM
```
```
Regional / Zonal
Level
```
```
Reviews and discusses
resignation with the dealer;
provides comments and
forwards to ZBH; can send back
or withdraw.
```
```
Can view all area-level
details, remarks, and
uploaded documents.
```
```
ZBH Zonal Business
Head
```
```
Reviews RBM and DD-ZM
inputs; adds zonal remarks and
forwards to DD-Lead for review.
```
```
Can view complete case
details up to current stage.
```
```
DD-Lead National
Coordination
Level
```
```
Consolidates information;
prepares resignation
presentation with
recommendations; forwards to
NBH.
```
```
Can view entire history,
remarks, and document
trail.
```
```
NBH National
Business Head
```
```
Reviews final presentation; adds
decision remarks; approves
resignation for legal processing.
```
```
Can view and comment on
all prior approvals and
documents.
Legal Post-Approval
Level
```
```
Uploads the Resignation
Acceptance Letter and closes
the case; can add queries via
Work Notes.
```
```
Gains access only after NBH
approval; visible to DD-
Admin upon upload.
```
```
DD-Admin Administrative
Level
```
```
Reviews and distributes
acceptance letter internally;
ensures completion record
update.
```
```
Can view full progress
history and all final
documentation.
```
```
All Higher
Roles
(Read-
only)
```
```
Oversight Access for viewing status,
remarks, and uploaded files for
compliance or reporting.
```
```
View-only access for all
resignation-related data.
```

### 7.6 Documents & Audit Trail

**7.6.1 Functionality Scope**

The **Documents** and **Audit Trail** sections collectively ensure complete transparency and
traceability across the resignation workflow. The **Documents** tab serves as a centralized
repository of all artefacts submitted or generated during the process — including resignation
letters, presentations, communications, and acceptance letters. The **Audit Trail** automatically
captures every workflow action, recording who performed it, what was changed, and when,
ensuring full accountability and data integrity.

**7.6.2 Width**

- Allows upload and viewing of all resignation-related documents with type, uploader, and
upload date clearly listed.
- Supports restricted document viewing to authorized personas with download control.
- Provides versioned tracking of uploaded artefacts for compliance.
- The **Audit Trail** logs every stage transition, approval, comment, or document addition with
precise timestamps.
- Automatically records system-triggered events such as SLA reminders or email notifications.


**7.6.3 Depth**

- Each document remains linked to its respective workflow stage and accessible through
the **Progress Timeline**.
- All actions — _Approve_ , _Send Back_ , _Withdraw_ , _Upload_ , and _Assign_ — are recorded for
traceability.
- The system maintains an immutable historical log for governance and audit purposes.
- Entries in the Audit Trail display both user-driven and automated actions to ensure
comprehensive visibility.

**7.6.4 Personas-wise Accessibility & Visibility**

```
Persona /
Role
```
```
Access Level Visibility & Permissions
```
```
DD-ASM /
AM
```
```
Area Level Can upload resignation email and initial supporting
documents which is the resignation PPT
RBM + DD-
ZM
```
```
Regional / Zonal
Level
```
```
Can view all uploaded artefacts and upload discussion or
dealer communication documents.
ZBH Zonal Head Can review attached documents and see all prior uploads
with remarks.
DD-Lead National
Coordination
```
```
Can upload resignation presentation and verify uploaded
PPT files for completeness.
NBH National Business
Head
```
```
Can view all documents and approval history before
finalizing decision.
Legal Post-Approval Level Uploads final Acceptance Letter , visible to DD-Admin and
field teams.
DD-Admin Administrative
Oversight
```
```
Has full view and download access to all documents and
audit logs for closure verification.
```

---

## 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