RE_Documents/Royal Enfield- Proposal Workflow Portal-WITH BPM Platform approach-1.06.txt

Revision History
Project
Workflow Management and dealer onboarding
Deliverable
Proposal document 

Executive Summary 
Royal Enfield is an Indian multinational motorcycle manufacturing company headquartered in Chennai, Tamil Nadu, India. The Royal Enfield brand, The oldest motorcycle brand in continuous production, Royal Enfield made its first motorcycle in 1901. A division of Eicher Motors Limited, Royal Enfield has created the mid-size motorcycle segment in India with its unique and distinctive modern classic motorcycles. The company operates manufacturing plants in Chennai in India.
Softude is a global IT consulting and services company established in 2005, specializing in digital transformation and software product engineering. With over 4000 successful projects delivered, our innovative software solutions are used in 32+ countries, connecting audiences across various industries. Our highly skilled team delivers exceptional digital solutions that accelerate our clients' digital-first journey.
Our team has extensive expertise in the development and implementation of customised solutions specifically designed for the automotive industry. We have a deep understanding of the unique challenges and requirements faced by automotive operation teams, allowing us to provide highly specialized and effective solutions.
In developing our response, we have considered our experiences associated with:
With 30years + experience in automotive industry and having good expertise encompasses various aspects of the industry.
Scope 
Approach:  Custom Platform development through BPM Platforms
1. Camunda Zeebe (Opensource) or
2. Newgen (Saas)
The scope of this project includes the design, development, testing, and deployment of a workflow platform using BPM Platforms (Saas), Customizable with the following key features:
* Front-end Development: Build a user-friendly interface using Next.js
* Back-end Development: Implement robust back-end services using technologies compatible with MongoDB.
* Database Management: Utilize MongoDB for data storage and retrieval.
* Enterprise Integration: Develop integration capabilities with SAP and DMS systems.
* User Management: Implement secure user authentication and authorization with Single Sign-On (SSO).
* Workflow Automation: Create tools for designing, automating, and adding new workflows.
* Access Control: Implement role-based access control to manage user permissions.
Reporting and Analytics: Provide reporting dashboards to monitor workflow performance.
Note: Considering 5 reports and one Dashboard with 
Develop a workflow platform for below mentioned services. The platform will use Next.js for the front-end, MongoDB for data storage, and provide back-end interfacing capabilities with enterprise applications like SAP and DMS. 
Current Scope:
The initial scope of this project includes the development of the following workflows:
* Dealer Onboarding/Offboarding Process
* Field Visit Report & Action Plan
* Dealer Claim Management


Project 1: Dealer Onboarding and Offboarding 
Below is the feature listing we have considered based on our discussion on the requirements
1. Master Module: This module includes the master data that is used in various stages of the process. It includes data such as prospect details, evaluation criteria, town list, dealer codes, etc. The role of this module is to maintain and update the master data as required. 
2. Workflow Module: This module defines the workflow of the entire process, including the sequence of activities, approvals, and notifications. It ensures that the process flows smoothly from one stage to another. The role of this module is to automate and manage the workflow of the process. Implementation based on the proposed document
3. Onboarding Process Module: This module focuses on the onboarding process of the selected candidates. It includes activities such as LOI issuance, document submission, evaluation, final interview presentation, etc. this module is to facilitate and track the onboarding process of the selected candidates. 
* Sending opportunity link emails to applicants in vacant locations. (manual)
* Create the application form and collecting dealer application responses through a form and calculating scores based on predefined criteria.
* Providing alerts for non-respondents to the dealer application form at different stages based on the defined TAT
* Sharing top candidate lists for further evaluation
* Sending reminder emails to non-respondents of the dealer application form.
* Data Collection: Creating forms or input fields to collect data from users
* Data Storage: Storing collected data in a database or file system, Document Management: Uploading, organizing, and hold documents within the software. 
* Retrieving and displaying stored data based on user queries or filters. And roles and access.
* Enforcing data validation rules to ensure data integrity and accuracy.
* Task Assignment and Tracking: Assigning tasks to users and tracking their progress. 
* Feedback and marks: Allowing users to provide feedback or reviews(marks) on certain stages from respective role. 
* Plan and conducting face-to-face interviews and evaluations with prospects. And provide option to input marks
* Manual process: Conducting ASM first interactions, RBM and ZM-DD interviews, DD Lead and ZBH interviews.

4. Role Module: This module defines the roles and access rights of different users involved in the process, list of role is defined are Admin ID, DD Lead, IT Team, ZM DD, RBM, ZBH, NBH. It ensures that each user has the appropriate access and permissions to perform their tasks. 
The role of this module is to manage and assign roles to the users. Please note that the specific details and functionalities of each module may vary based on the actual implementation and system requirements.
Access Control: Implementing different levels of access for users based on their roles and permissions.
Role-based Dashboards: Creating customized dashboards for different user roles to display relevant information.

5. Reporting module
Reporting and Analytics: Generating reports and conducting data analysis on the collected data. We will create list of 5 reports which will provide the data in defined format with filer and excel export.
#
Module
Task
Subtask
1
Database design
Create database tables
1) Database and tables creation
2
Inquiry capture and initial response
Automate "Become a Dealer" Form Capture.
1) Integrate with RE official website to fetch form data in real-time or on an hourly basis.



2) Store data in the system for record-keeping and show the listing on the system along with the filers


Automated Acknowledgement Email
1)Configure an email template with placeholders for applicant details.



2) Send an automated email to acknowledge the enquiry.


Automated Non-Opportunity Email
1) Identify locations with no vacancy and send a rejection email.



2) Configure email templates with dynamic placeholders


Opportunity Email with Questionnaire
1) Create a web link for the questionnaire with:
Objective questions.
- Fill-in-the-blank responses.
- File upload options.
- Free text boxes.



2) Configure and send email containing the web link 
3
Questionnaire Processing
Assign Weightage to Questionnaire Responses
1) Develop logic to calculate rank based on weighted responses


Automate Notifications for Incomplete Responses
1) Configure email reminders at D+2 and D+5 days for pending responses


Close Questionnaire on Expiry
1) Allow configurable expiration date for the web link (default: 20 days).



2) Disable further responses after expiry.
4
Enquiry Shortlisting and Assignment
Shortlisting by DD Team
1) Enable manual assignment of top 10 prospects to Zonal Manager (ZM-DD) based on rank.



2) Capture reasons for shortlisting during assignment


KT Evaluation by ZM-DD
1) Allow ZM-DD to evaluate and mark prospects as shortlisted or rejected.


Assign to Regional Business Manager (RBM)
1) After evaluation leads comes to RBMs post-evaluation automatically. Allow RBM for evalution



2) Capture reasons for the assignment and store in the database


Assign to DDL team
1) Lead automatically assign to DDL team after approval of RBM.



2) Capture reason for the assignment and store in the database
5
Financial and Legal Approvals
Upload Financial Due Diligence Reports
1) Provide an upload option for third-party financial reports through link, link will be OTP protected over email and that will be expire after getting the response.
2) FDD auditor for L1 and L2 , email for external agencies will be configured


Submit Approval to NBH
1) Allow DD Team to submit financial due diligence reports to NBH for approval



2) Store NBH approvals in the system
6
Dealer Onboarding
Issue LOI (Letter of Intent)
1) Automate LOI generation and email to prospects with CC to relevant teams



2) Enable file upload for LOI storage


Issue LOA (Letter of Agreement)
1) Automate LOA generation and email to prospects with CC to relevant teams



2) Enable file upload for LOA storage.


Schedule EOR Audit
1) Allow Regional DD Team to schedule and complete the audit.



2) Provide format and upload option for audit reports.


EOR Approval
1) Capture NBH approval for EOR audit with a file upload option


Update Dealer Information
1) Capture and store inauguration date, dealer codes for sales, service, GMA, and Gear.
7
Dealer Resignation Handling
Resignation Submission
1) Dealer will send email to ZBH and ZBH will take it forward and record in the system. we will manage the tracking of each activity.


Approval Workflow
 1) Approval work flow work same as we are doing during onboarding, below are the level where we need to manage the approval/rejection flow.
- Zonal Business Head (ZBH). 
- Dealer Development Lead (DD Lead).
- National Business Head (NBH).
 
2) If request rejected at any level , the request will go back to its previous level automatically and there will be a mail notification for the same to the responsible person.


Generate Resignation Acceptance Letter
1) Automate legal format generation for resignation acceptance after final NBH approval



2) Enable NBH to approve and share the letter with predefined format with the dealer.
8
Dealer Termination Process
Identify Termination Reasons
1) Create categories: Business, CX Issues, Ethical Issues, and Unforeseen Circumstances
2) Types of termination - a) Immediate termination b) Termination by convenience


Collect and Upload Documentation
1) Allow ASM to collect and upload all communication documents


Prepare Termination Notes
1) Automate generation of termination notes in pdf format


Approval Workflow
1) Approval work flow work same as we are doing during onboarding, below are the level where we need to manage the approval/rejection flow.  
  - Zonal Business Head (ZBH).
  - Dealer Development Lead (DD Lead).
  - Dealer Development Lead (NBH).
  - Chief Commercial Officer (CCO).
  - Chief Executive Officer (CEO).

2) If request rejected at any level , the request will go back to its previous level automatically and there will be a mail notification for the same to the responsible person.


Issue Termination Notice
1) Automate show cause notice generation with legal concurrence.



2) Notify dealers with 15-day response deadlines


Upload Signed Termination Letter
1) Allow DD Lead to upload signed termination documents to the portal
9
Notifications and Reminders
Automated Email Reminders
1) Configure reminders for pending tasks (KT evaluations, approvals, Termination request pending, resignation request pending).
2) Mail need to be configured for the same.
3) Cron jobs need to be configured
#
Dashboard
Dashboard for Process Monitoring
1) Real-time dashboard showing the status of enquiries, approvals, and onboarding
2) Displays a high-level overview of all ongoing processes and key metrics such as total inquiries, pending approvals, and current statuses
#
User Login Module
Develop Login Interface
1) Design a secure login page, which allow user to redirect to AD, System user login thorugh AD
#
System user management/registration
Develop Registration Interface
1) Design a user-friendly registration form



2) Collect user details:
  - Name.
  - Email.
  - Contact number.
  - Role (dropdown: Admin, Dealer Development, Regional Manager, etc.).
Password (with complexity rules)
3) Basic validation will be there.
#
Role Management Module
 
1) Role creation form along with the permission



2) Role Active/Inactive and listing with the filters
#
User Profile Management
Design user profile page
1) Need to create page for user profile , where user can see the information associated with him
#
Super admin access managment
Master management and configurations
1) Dealership vacancy management, Link expire configuration, All access by default, User listing, Role listing with filters.


Multilevel actions
1) Super admin can see all the activities and take any action of any role at any stage
2) Masters management


Approval flow configuration
1) Provision to configure the approval flow for the below three activities
 - Onboarding approval flow
 - Resignation approval flow
 - Termination approval flow

Ex. in case of termination, process usually start with ZBH than DD Lead than NBH and so on, but it can be change later, RE can introduce new role in future or shuffle the approval flow and that can be configurable from the system only.

2) System will have an option to add stakeholders or roles for the F&F process from the system only and that can be configurable.
#
Reports
Report listing with filters and download option
1) We will provide below 4 report with filters

  - Dealer wise report

  -MIS report 

  -Pending request report dealer wise

  - F&F tracking report stakeholder wise. 


2) Provide download option in excel.
#
F&F
Notification of Resignation/Termination and start the F&F process
1) Design mail template and circulate resignation/termination notification to all the stakeholders along with last working day of the dealer.
2)  Need to create cron job for the same
3) DD team circulate the email to all the respective stakeholders for getting the F&F process concluded as per the defined TAT

Auto email notification for the same through system


F&F request tracking
1) Need to implement web page for the tracking the F&F process


 
2) need to manage stakeholder along with their task


 
3) set reminder mails if someone not doing their job in defined TAT


 
4) Provide an option for each role to update the status of their task
5) When the respective stakeholder logs into the system, they can see their pending request. These requests will be segregated based on respective roles.
6) Each role have their own forms and field which they will update from the system. Ex. finance team will see settlement related form, legal team will see clearance related forms etc.
Note: couple of points are open ended


Block dealer from the system
1) Provide option to block the dealer from the system (This action will taken place after all the stakeholder status)


 
2) Email notification to all the stakeholders

Project 2:   Field Visit Report & Action Plan
Feature Listing
Application Module
Description
FJC Planning
- Document preparation

- Review and approval flow

- Dealer coordination
Visit Execution
- Field visit as per plan

- Re-plan if changes occur

- Dealer discussion
Discussion Management
- Capture actionable insights

- Record feedback and performance metrics
MOM Creation
- Structured documentation

- Action item tracking and delegation
Closure & Sharing
- Document submission and archiving

- Stakeholder communication
Approval Workflow
- Manage approval workflow as per managed hierarchy





Project 3: Dealer Claim settlement:
Feature Listing
Process Step
Scope Details
1. Request Initiation
Requestor (Marketing / Service / CNR) submits an activity request with: 
Activity type, dealer info, date/location, details, and period
2. Proposal Submission
Dealer submits a proposal with:
Cost breakup
Timeline for closure
Supporting documents
3. Request Evaluation
Requestor reviews the proposal, adds comments, and either: 
Requests clarification or
Confirms to proceed
4. Dept. Lead Approval
Department lead reviews the confirmed request and either:
Approves it or
Requests clarification
5. Budgeting
Upon approval, budget is blocked under respective IO (Internal Order)
6. Activity Creation
System creates the activity and sends auto-confirmation email to requestor, dealer, and lead
7. Activity Execution
Dealer executes the activity and submits required documents
8. Claim Approval
Requestor reviews documents and either
 Approves the claim (fully or partially)
Requests more info
9. E-Invoicing
Upon approval: 
E-invoice is generated
Credit note is issued

Roles involved managed and maintained in the masters 
Role & Persona: 
Requestors: Raise activity request, evaluate proposals, approve claims
Dealers:  Submit proposal and post-activity documents
Dept. Lead: Approve activity requests
Automation	Handle system-level triggers (e.g., activity creation, Email Notofication)
Out of scope:  
* Integrating with third-party systems or APIs to exchange data or functionality. 
* Dealer Offboarding process
* Data collection form external system for old existing dealer
* Any functionality which is not a part of shared PPT document can be consider as a new requirement or change request and not a part of current proposal and commercials.
* Interface Layer (MSD/SAP)	Interface with external systems for budgeting, invoicing, and credit note
* Dealer Persona 

Note: we considered the scope based on the shared BRD document attached (PPT)and the detailed discussion.
Project Assumptions
1. Royal Enfield will align and limit its requirements to adopt the Out of Box practice processes and features as delivered by the solution. No changes are expected to be made to the existing or dependent product.
2. Royal Enfield will provide a team of business experts who will work with the Softude team and will respond to the queries, conduct the reviews, and give necessary signoffs within agreed timelines.
3. Royal Enfield will take the responsibility of business readiness to achieve the proposed go-live milestone for the modules in scope of this statement of work.
4. Royal Enfield will ensure availability of its project documentation, Subject Matter Experts (SMEs) and Process Owners for workshops, discussions, and clarifications for the Softude project team as per calendar (inclusive of any local holidays) published by Softude at project start.
5. Project plan will be reviewed after the end of finalized Design (Modelling) phase with due consideration of any scope changes/ deviations. Any change that might have an impact on the scope, timeline, resources plan and any changes in the assumptions will be handled through a scope change management process (Change Order process).
6. Change Management is a shared responsibility as per the Roles and Responsibility section and the success of this track will depend on both the parties delivering as per expectations.
7. All interfaces for the new product have been identified in the scope. If any additional interfaces apart from identified needs to be developed, then additional effort would be considered and will be handled through a scope change management process (Change Order process).
8. Any timeline delays not directly attributable to Softude (such as product procurement, any business constraints, delay from source or target systems providing required details, connectivity issues, firewall issues) potentially could have an impact on the overall schedule resulting in Change Order process.
9. Any third-party access & authorizations will be made available to the Softude team within the first two weeks of project start.
10. Any scope changes are assumed to follow the defined Change Order processes including approvals.
11. The solution outlined in this document is based on current features or details shared by client in their scope document. Configuration of future enhancements, or enhancements released during the duration of the project, are not included. Any features which are going to be part of any new releases during the life cycle of the project will not be considered for implementation unless agreed upon as direction from product vendor/roadmap.
12. Negotiations and Procuring the Software Licenses for any third party (if required), and any other applicable Systems and third-party Tools is the responsibility of Royal Enfield.
Security Measures
Most secure app infrastructure in the market where security extends from the mobile app to the API's.
1. All APIs are secured with a wildcard SSL certificate.
2. As a Best Practices we should use of JWT and JWE for securing all API's. 
3. Rate limit API and controller access to minimize the harm from automated attack tooling.
4. App secured from any DB injection.
5. App protected from clickjacking protection, XSS, MIME-Sniffing, HSTS, HPKP or set the CORS settings. 
6. Security headers are enabled.
7. Code is not deployed with default credentials, particularly for admin users and even for mobile users.
8. As a best practices, uses a server-side, secure, built-in session manager that generates a new random session ID with high entropy after login. Session IDs should not be in the URL. Ids should also be securely stored and invalidated after logout, idle, and absolute timeouts.
9. As a best practices, JWT tokens are invalidated on the server after logout.
Testing
We put everything we make through rigorous user, compatibility, and functional testing to ensure it's bug-free on Day 1 and will continue to perform for you into the future.
As standard, we implement the following tests in a controlled environment before the web application is launched:
* Functionality Testing
* Usability testing
* Compatibility testing
* Interface Testing
* Performance Testing (Basic)
* Security testing (Basic)
* UAT Support
We also continue testing and monitoring the application over the 2 weeks to ensure it's working as promised.
Communication Plan
Regular Update
<EFBFBD> Softude will provide the regular update to the client bi-weekly as well as on the completion of the milestone, which will be mapped with the milestone plan.
<EFBFBD> Softude will test the system before the delivery of every milestone delivery and then would provide the update to the client. 
Regular Meeting
<EFBFBD> Softude would be available for the regular meeting to provide the demo at the completion of every milestone and to give a walkthrough.
<EFBFBD> If needed, we can also plan a regular meeting as and when required. 
<EFBFBD> If required, the client can also visit our Indore (India) based headquarter for a personal meeting with the team.
Communication Medium
<EFBFBD> Updates will be provided via email.
<EFBFBD> Meetings can be done using MS Teams/Zoom/Hangout or any of the preferred medium.
<EFBFBD> Softude will use Zoho as a project management tool, if needed we also add the client to our system where they can also track regular progress.
Technology stake and version
Technology Usage
Technology
Licensed / Open Source
User Experience (UX Design)
Adobe XD
Licensed
User Interface (UI)
React, View JS
MIT License
 
HTML5/CSS/JS
Standard
 


API Gateway
Node Js
Open Source
Databases (RDBMS & NoSQL)
MYSQL / postgresql
VM setup
Containers / App Servers
Webserver
Apache License 2.0
Project Management / Collaboration Tool
ZOHO PMS
Licensed
 
Microsoft Teams
Licensed
Code Repo
Gitlab
Code Repository and Version Control

Assumptions
* Customer will provide SAP APIs for integration. 
* Inputs provided from the customer in any terms will be assumed to be accurate.
* Necessary approvals and timely review of submissions.
* Customer will complete testing & UAT before handover. 
* Softude's timely and adequate performance of the services and provision of the deliverables shall depend upon full access to appropriate customer personal and to customer information and documentation. 
* Softude is not responsible for inaccurate or incomplete information that is obtained from customer. 
* Customer would provide needed documentation and information that would be crucial for execution of the task provided as applicable from time to time. 
* All the organizational or technical changes which may affect any services will be communicated in writing to Softude at least 1 week prior to changes. 
* Support of services that are outside scope, all such activities would be identified and discussed with Customer and will be owned with invoking required changed/configuration orders. 
* We assume for business-critical applications necessary HA architecture in place to meet the requirements. 
Out of Scope
We include those items which are not considered in the budget that is defined in this proposal. Items like purchasing of third-party APIs, hosting, domain name, etc. Also, the list of items may vary depending on the communication you have with the client. Below are some references which you can use.
1. Implementation of any module other than the modules mentioned in scope section.
2. Implementation of any third party other than mentioned in the scope section.
3. Any configuration and development work in existing on-premises systems or any interface development from On premise to On premise/third party vendors are not considered in scope
4. Data cleansing, Data Quality related validation activities
5. Purchase of any 3rd party controls/software licenses, if required during development
6. Data creation is not in the scope.
7. Data migration to the proposed application
8. Any requirement which is not mentioned in the scope of work spreadsheet.
Client Responsibilities
We believe that successful partnerships are built on mutual trust and collaboration. As such, we would like to outline the responsibilities that we expect from our clients to ensure that we can deliver the best possible service. By fulfilling these responsibilities, our clients can help us to achieve our shared goals and ensure a successful outcome for all parties involved.
Below are the client's responsibilities:
1. Designate a project coordinator(s) at your end. This person should be helping us to understand the exact requirement in detail so that we can draft specifications and later on coordinating points for application support. (It may be one or multiple persons based on expertise in their function)
2. Logic and business rules for all functionality
3. Timely responses/feedback (within 3 days from submission) for 
a. Queries
b. Document (like SRS/Screen design etc.)
c. Demo
d. UAT
e. Implementation
4. Change Control approval (within 7 days from submission)
5. Provide hosting server (Deployment server)
6. Licenses software, external components, or any tool. (If any)
7. Make the server available with the required environment.
8. Support required for coordination with third parties such as payment gateway, or other application developers involved for getting APIs.
Proposed Methodology
Waterfall Development Approach
The Waterfall methodology-also known as the Waterfall model-is a sequential development process that flows like a waterfall through all phases of a project (analysis, design, development, and testing, for example), with each phase completely wrapping up before the next phase begins.
The project is broken down into a sequence of tasks, with the highest level grouping referred to as phases. A true waterfall approach requires phases that are completed in sequence and have formal exit criteria, typically a sign-off by the project stakeholders. A typical list of waterfall tasks would include:
* Scope and plan project
* Gather and document requirements.
* Design application
* Develop application and perform unit tests.
* Conduct system testing.
* Perform UAT
* Fix application as appropriate
* Deploy application.


Requirement 
The Waterfall methodology depends on the belief that all project requirements can be gathered and understood upfront. The Business Analyst does their best to get a detailed understanding of the project sponsor's requirements. Written requirements, usually contained in a single document, are used to describe each stage of the project, including the costs, assumptions, risks, dependencies, success metrics, and timelines for completion. 
Design
Here, software developers design a technical solution to the problems set out by the product requirements, including scenarios, layouts, and data models. First, a higher-level or logical design is created that describes the purpose and scope of the project, the general traffic flow of each component, and the integration points. Once this is complete, it is transformed into a physical design using specific hardware and software technologies. 
Implementation
Once the design is complete, technical implementation starts. This might be the shortest phase of the Waterfall process, because painstaking research and design have already been done. In this phase, programmers code applications based on project requirements and specifications, with some testing and implementation taking place as well. If significant changes are required during this stage, this may mean going back to the design phase.  
Verification or testing
Before a product can be released to customers, testing needs to be done to ensure the product has no errors and all of the requirements have been completed, ensuring a good user experience with the software. The testing team will turn to the design documents, personas, and user case scenarios supplied by the product manager to create their test cases. 


Deployment and maintenance
Once the software has been deployed in the market or released to customers, the maintenance phase begins. As defects are found and change requests come in from users, a team will be assigned to take care of updates and release new versions of the software.
Governance Setup
Sr. 
Name
Description
Attendees
Duration(mins)
1.
Daily Scrum Call

10 minutes call where we discuss what we did in the previous day and what is today's plan and challenges (if any).
Development Team, Team Heads, Project Manager

10
2.
Weekly Review Meeting
A 30 minute meeting to share the current project status vis-a-viz as per the defined project plan and discuss dependencies, hurdles and resolutions.
Team Heads, Project Manager, Client's coordinator
30
3.
Monthly Governance Meeting
A 60 minute meeting to share the progress as per the define milestone.  Any anticipated hurdles in the future deliverables, challenges faced in the previous month and ensuing these are not repeated in the future.?
Project Manager, Client's coordinator, Project Owner, Solution Consultant, Client IT and Business SPOC
60


Part 3: Agreement for Support and Maintenance Services
Annual Maintenance and Support Services
Support during AMS would be offsite services. This will be decided mutually depending on the nature of the issue reported by ROYAL ENFIELD  
Maintenance and support will be provided on working weekdays between 10:00 A.M. and 6:00 P.M. IST, excluding Public Holidays. For support requests received beyond the stipulated hours above, SOFTUDE INFOTECH PVT LTD will make reasonable efforts to ensure that these requests are attended to, promptly. ROYAL ENFIELD   can contact SOFTUDE INFOTECH PVT LTD for maintenance and support at the phone number(s) and email addresses provided to them.
Annual Maintenance and Support includes:

Type of support
Support Description
#1
Bug Fixing
* Any error, flaw, fault occurred in a developed software, an incorrect or unexpected result, or behave in unintended ways. should be considered in bug fixing. This process does not include any logical or process change in system (Code change).
* Softude is not responsible in mal function of platform (Zoho Creator) or any error on the platform.
* SOFTUDE is not responsible for any Third-Party API Issue, backend API issue, and efforts related to that we will not consider in support (Log hours billed as per actual).
* If issue arises due to application and it is creating issue in backend, then it will fall under bugs/errors.
* If the issue is related to third party platform and impacting the application/backend or vice versa than the solution efforts do not consider in support.
#2
Support Request or Query
Any query or request shared by ROYAL ENFIELD   business or IT that may not require any development efforts but may require devoting time such as any request for review and validation of the current functionality or any requirement analysis and Investigation will be considered as Support Request or Query. 
#3
CR Request in existing system under Support contract
Any change or upgrade in the software, that is required by the business or process to improve the quality or capabilities beyond original specifications will be considered as change request. 
* In case of any new module or new functionality development request where it requires major change or entirely new development then it is considered as change request.
#4
MIS Data from backend
At any point of time if business or IT function need any information updates or data sheet from the backend system, which can be created by the developer and directly generated from the simple SQL query is considered in MIS data or simple query report request.