--- title: "Bajaj | Account Stage Change Logic and Roving Test Ride" description: "Internal Knowledge Transfer Summary Session Date: 18 Dec 2025 Audience: Support Team Tenant: CamCargo (Tenant ID: 67435) Topics Covered: Account Stage Change Logic (Dormant Handling) Roving Test Ride / Test Ride Anywhere – PB Flow 1. Account Stage ..." url: "https://supportb.kinsta.cloud/docs/bajj/" updated: "2026-01-31" category: Account Details_Master Folder --- # Bajaj | Account Stage Change Logic and Roving Test Ride --- **Internal Knowledge Transfer Summary** **Session Date:** 18 Dec 2025 **Audience:** Support Team **Tenant:** CamCargo (Tenant ID: 67435) **Topics Covered:** 1. **Account Stage Change Logic (Dormant Handling)** 2. **Roving Test Ride / Test Ride Anywhere – PB Flow** --- **1. Account Stage Change Logic – Dormant Handling** **1.1 Background and Issue Identified** In the CamCargo tenant, an automated **daily batch job** monitors account activity. If no activity is recorded on an account for a defined duration, the system automatically updates the **Account Stage** to **Dormant**. Previously: - Accounts were marked **Dormant after 180 days** of inactivity. - Even when users (ASMs) manually changed a Dormant account back to an active stage (e.g., Open, Validated, Engaged), the account reverted to **Dormant again the next day**. - This prevented users from investigating inactive accounts or performing follow-up actions. --- **1.2 Updated Business Requirements** The business shared the following requirements: 1. **Dormancy Threshold Update** - Increase inactivity period from **180 days to 365 days** before an account becomes Dormant. **Prevent Immediate Re-Dormancy** - Once a user reactivates a Dormant account, it should not automatically revert to Dormant the next day. **Stage Traceability for ASMs** - ASMs have permission to change account stages. - They need visibility into what the **original stage was before the account became Dormant**, to avoid incorrect or uninformed updates. --- **1.3 Implemented Solution** **a. Dormancy Threshold Adjustment** - The **batch job logic** was updated so that accounts are now marked Dormant **only after 365 days of inactivity**, instead of 180 days. --- **b. Introduction of “Previous Stage” Field** - A new field, **Previous Stage**, was created. - Every time the account stage changes: - When an account transitions to Dormant: **Benefit:** - ASMs can clearly see the last active stage before dormancy. - Reduces the risk of incorrect manual stage updates. --- **c. Automation to Keep Reactivated Accounts Active** A new automation was implemented with the following logic: **Trigger Conditions:** - Account stage changes from: **Automation Actions:** - Post a **follow-up activity** on the account. - Create a **task** linked to the account. **Outcome:** - The presence of a new activity prevents the batch job from marking the account Dormant again. - Users can actively work on the account and analyze inactivity reasons. --- **1.4 UI Enhancements for User Clarity** - The **Previous Stage** field is now visible on the account record. - Users can immediately see what the account stage was before it became Dormant, ensuring informed decision-making. --- **1.5 Summary of Account Stage Enhancements** - Dormancy threshold increased to **365 days**. - Automatic re-dormancy issue resolved. - Full stage history visibility enabled through **Previous Stage** tracking. - ASMs now have controlled flexibility to reactivate and work on Dormant accounts. --- **2. Roving Test Ride / Test Ride Anywhere (PB)** **2.1 Business Context** Earlier, test rides were restricted to **branch showroom locations**. The business introduced a new capability called **“Test Ride Anywhere”**, allowing test rides at a customer’s preferred location. This enhancement is primarily applicable to **Pro Biking (PB)**. --- **2.2 Master Data (MAVIS) Configuration** A dedicated **MAVIS master** was created to support Test Ride Anywhere operations. **Fields Maintained:** - Business Unit (BU) - City - Test Ride (TR) Marshal Name - Mobile Number - Email ID - Owner ID **Purpose:** - Owner ID ensures that tasks and activities created for Test Ride Anywhere are correctly assigned to the **TR Marshal**. - Leads and opportunities are shared with the TR Marshal for **90 days**, while ownership remains with DAC. --- **2.3 Task and Form Structure** Two task types are used: 1. **Test Ride Task (DSE/DAC)** 2. **Test Ride Anywhere V2 Task (TR Marshal)** --- **2.4 DAC / DSE Flow – Test Ride Creation** When a DSE/DAC marks a Test Ride task as complete: - The Test Ride form opens (existing form with enhancements). - A new field **Test Ride Location** is introduced: If **Test Ride Anywhere** is selected: - Additional fields appear: - Based on selection: Upon submission: - A **Test Ride Anywhere task** is automatically created and assigned to the selected TR Marshal. --- **2.5 TR Marshal Flow – Task Completion** When the TR Marshal opens and completes the task: - Test Ride Status options include: **For “Completed” status:** - Mobile number verification is mandatory. - The mobile number must match the lead’s mobile number. - OTP verification is triggered. - Dedicated LABs handle: If the number does not match, the system displays an error and blocks completion. For other statuses (Cancelled / Rescheduled): - OTP verification is not required. - Existing system logic applies. --- **2.6 Pilot Scope** - Currently live as a **pilot in Hyderabad** only. - Expansion to other cities will depend on business readiness and master data updates. --- **3. Overall Summary** This KT session covered two important enhancements: 1. **Account Stage Management Improvements** - Eliminated repetitive Dormant status issues. - Enabled transparency and control for ASMs. - Improved lifecycle tracking through Previous Stage recording. **Roving Test Ride (Test Ride Anywhere) Enablement** - Extended test rides beyond showroom locations. - Introduced TR Marshal–driven execution with controlled ownership. - Ensured data integrity through OTP and mobile verification. Both changes significantly enhance **operational flexibility**, **data accuracy**, and **user confidence**, while providing the Support Team with clear logic for troubleshooting and user guidance.