Phonon Client Onboarding & Change Request Process Document
Stakeholders & Status
| 1 | Document Owner | @Mahesh Bhosale |
|---|---|---|
| 2 | Document Reviewer | @Anand Dubey |
| 3 | Document Status | IN PROGRESS |
1. Technical Feasibility Process
Process Steps
JIRA Submission
The sales team will raise a JIRA ticket detailing the high level client requirement.
Feasibility Assessment
The onboarding team will assess the requirement and provide feasibility confirmation by documenting in Confluence if required.
Effort estimation for deployment will be shared.
Scope of Feasibility Analysis
This process applies to both new client onboarding and new change requests for existing customers.
SLA for Technical Feasibility
Severity Level | Definition (Presales & Delivery) | Response Time | Resolution Time | Escalation |
|---|---|---|---|---|
Severity 1 (Critical) | High-priority project with significant business impact, requiring urgent feasibility analysis and fast-tracked delivery. | Feasibility check within 4 hours | Project delivery within 3-5 business days post-approval | Immediate escalation to L2 if delays occur |
Severity 2 (High) | Key client request with potential revenue impact, requiring accelerated feasibility and implementation. | Feasibility check within 1 business day | Project delivery within 7-10 business days post-approval | Escalation within 2 business days if feasibility is delayed |
Severity 3 (Medium) | Standard project request with no immediate urgency, following regular feasibility and approval workflows. | Feasibility check within 3 business days | Project delivery within 15-20 business days post-approval | Escalation within 5 business days if feasibility is delayed |
Severity 4 (Low) | Minor requests, enhancements, or exploratory feasibility checks with no immediate business impact. | Feasibility check within 5 business days | Project delivery timeline based on priority, typically 20+ business days | No escalation unless business impact changes |
Note: These SLAs serve as indicative timelines and may be subject to change based on project complexity and client-specific requirements. Any deviations will be formally communicated and agreed upon with the client. Also, if there is any specific requirement where onboarding will need confirmation from Product, the timelines will change.We need Sales Team support in marking correct Severity/Priority for each Project and also all Project should not be Critical/High.
2. New Client Onboarding Process
Prerequisites
Before initiating the onboarding process, ensure the following prerequisites are met:
Phonon Central Account with KYC Approved: The client must have an active Phonon Central account with KYC verification completed.
Client Approved SOW and JIRA: A signed Statement of Work (SOW) and corresponding JIRA ticket must be available.
Commercial Approval: Internal commercial approvals must be secured before proceeding.
Commercial for Deliverables & Rate Plan Configuration: Ensure all commercial agreements related to deliverables and rate plan configuration are finalized.
Client SPOC to Coordinate: A designated client Single Point of Contact (SPOC) must be identified for coordination.
Client API document (if applicable): If the onboarding process involves API integrations, the necessary client APIs must be made available.
Process Steps
Agreement & JIRA Initiation
The Phonon Sales team will close the agreement and SOW sign-off with the client.
Post sign-off, they will raise a JIRA ticket for onboarding the new client.
Onboarding Kick-off
Once the commercially approved JIRA is assigned to the onboarding team, they will initiate a first kick-off call with the client.
The call will cover requirement understanding, technical discussions, clarifications on prerequisites, and API discussions if required.
UAT Environment Setup & Testing
The onboarding team will define and share a timeline for delivering the flow in the UAT environment.
Conduct UAT (User Acceptance Testing) with the client and gather feedback.
Production Deployment
Post UAT sign-off from the client, the onboarding team will initiate the production movement process.
The project will be made live.
Post-Go-Live Monitoring & Handover
The onboarding team will monitor the system for 7-10 days post go-live.
A support handover call will be conducted alongside the sales team.
Onboarding Team Tasks for Onboarding
Creating flows as per client requirements.
Scheduling the EOD report to client-designated email IDs.
Configuring the rate plan.
Configuring the dashboard for internal monitoring and any specific client requirements.
Creating a Confluence page for the complete client process flow and technical configurations.
3. New Change Request (CR) Process
Prerequisites
Before processing a change request, ensure the following requirements are met:
JIRA Ticket with High-level Client Requirement: A JIRA ticket documenting the requested changes must be available.
Client ID: The unique identifier for the client account must be provided.
Client SPOC to Coordinate: A designated client SPOC must be available for discussions and clarifications.
Client API document (if applicable): If the change request involves API updates or new integrations, relevant APIs must be shared by the client.
Process Steps
Requirement Analysis & Approval
The sales team will get the effort approval from the client, which the onboarding team has shared as a part of the feasibility ticket.
Post approval, the sales team will raise a JIRA ticket for the change request..
Development & UAT Testing
The onboarding team will create or update the flow as per client requirements in the UAT environment.
The client will conduct UAT and provide sign-off.
Production Deployment & Documentation
Once sign-off is received, the onboarding team will deploy the changes to the production flow.
The Confluence page will be updated with details of the deployed changes or updates in existing flows.
4. Escalation Matrix
Escalation Level | Contact Person |
|---|---|
Level 1 | @Mahesh Bhosale / @Anurag Shrivastva |
Level 2 | @Anand Dubey |
5. Process Flow
This document has been developed by Phonon.io for the sole and exclusive use of the customer / prospective customer with whom this document is being shared. Further, this document has been provided by Phonon.io to the recipient in good faith and based on request from the recipient for the same. This document is a confidential document and contains confidential product technology, workflow and commercial details that are for the sole usage of the intended recipients of this document. Recipients are advised not to share this document with any third party that is not the intended recipient of this document and neither to bring this document in full or parts into the public domain. Any unauthorized access may be brought to Phonon.io’s notice immediately. Phonon.io is free to take any legal action it deems necessary against any person or entity that violates this confidentiality agreement. Phonon.io is bound and governed by the rules of the state of Gujarat in India. In case you are not in agreement with the terms set in this clause or are not an intended recipient of this document, please destroy the document and intimate us of the same at info@phonon.io.