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 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:
- 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:
- The existing stage is captured and stored in Previous Stage.
- When an account transitions to Dormant:
- The stage immediately prior to Dormant (e.g., Engaged, Validated) is preserved.
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:
- Dormant → Open
- Dormant → Validated
- Dormant → Engaged
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:
- Test Ride Task (DSE/DAC)
- 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:
- Branch Showroom (default)
- Test Ride Anywhere
If Test Ride Anywhere is selected:
- Additional fields appear:
- City
- Business Unit
- TR Marshal Name (dropdown)
- Based on selection:
- TR Marshal’s mobile number, email, and user ID auto-populate.
- These fields are non-editable.
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:
- Planned
- Completed
- Cancelled by Dealer
- Rescheduled
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:
- OTP validation
- Mobile number mismatch checks
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:
- 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.
