The Change Management Process is designed to handle non-standard requests that require in-depth analysis and planning, as they involve tasks beyond everyday operations.

These changes often include, but are not limited to:

• Custom configurations requiring API calls, event-based automation, or external scripting.
• Connect to an unknown external voice provider using their SIP trunk.
• Integrations with third-party solutions to ensure seamless interoperability.
• Complex system modifications that need structured implementation and validation by product owner or custom development team.

As these requests often require professional services and may impact system stability and performance, a structured approach to feasibility assessment, risk evaluation, and resource allocation is essential to ensure service quality while minimising operational disruptions.

1. Customer Contact (Level 1 – Partner Support Team) – Raise a Request

The customer raises a Change Request via the designated Level 1 – Partner Support channels (e.g., phone, email, chat, or portal).

The request must include the following details to enable further incident analysis.

Information required from the customer:

• Email Subject / Title: “Customer Company Name” – Brief request description
• Customer Instance: URL of the instance
• Scope:
  • Where in the system is the change requested?
• Current state with business justification and impact:
  • Current state of the feature (if updating an existing feature) and the required state of the feature.
  • Why is this change needed or what issue does it resolve? Use detailed description of the business process that the feature should support using several sentences. Add examples or visualisation aids if applicable.
  • What happens if this change is not implemented?
• Proposed solution:
  • Proposed technical solution suggested by the customer or any integrators.
• Timeline & Priority:
  • Expected delivery date.
  • Urgency classification (High/Medium/Low) as set by the customer.
  • The L1 – Partner Support Team does not determine urgency but ensures that the customer’s priority is passed along accurately.

2. Log and Categorize

• (Optional) The L1 – Partner Support Engineer has a time-tracking mechanism enabled while working on the ticket.
• Determines if the request qualifies as an Change Request and assigns it accordingly (either to themselves or another team member).
• (Optional) Logs the request into a ticket, and adjusts the priority based on urgency (High/Medium/Low) and assigns an appropriate status (e.g.):
  • RFC

3. Analyze and prepare RFC

• The assigned engineer will review the request and determine if they have enough information to proceed with RFC preparation to be albe to raise the request further.
• If additional details are required, the engineer may ask the customer the following questions:

Scope & Business Justification:

• What specific feature, module, or service does this change affect?
• Is this a modification of an existing feature or a new request?
• What business process or operational need does this change support?
• How does this change align with your workflow or customer interactions?

Current & Expected Behaviour

• How does the system currently behave in this scenario?
• What specific problem or limitation are you experiencing?
• What is the expected behaviour after the change?
• Can you provide a step-by-step use case or example?

Technical & Implementation Details

• Do you have a proposed solution or technical requirements in mind?
• Will this change require external integrations (API, third-party platforms)?
• If this involves a SIP trunk or external voice provider, do you have configuration details?
• Are there any technical constraints or requirements we should be aware of?

Risk, Dependencies & Impact

• Will this change affect other users, services, or system components?
• Are there any related settings, workflows, or dependencies to consider?
• Is there any ongoing development or system update that might interfere with this change?
• Have you already tested or attempted any workaround for this?

Priority & Timeline

• What is your expected delivery timeframe for this change?
• Is this request time-sensitive or linked to a business event?
• If this change takes longer than expected, how would it impact your operations?

Documentation & Supporting Materials

• Can you provide screenshots, logs, or example transactions to illustrate the request?
• If this involves an external provider, do you have their documentation or contact details?
• Do you have any test accounts or sandbox environments for validation?

Cost Consideration (if applicable)

• Are you aware that this change may require professional service fees?

Once you have all the details, prepare a structured RFC focusing on all areas of information requested by the customer.

4. Raise the RFC to Level 2 – Daktela Support Team

• When all details have been collected and the RFC has been written, the L1 – Partner Support Engineer must send an email to the designated L2 – Daktela Support Team contact for their country.

Structure:

• Email Subject: “Customer Company Name” – Brief request description
• Email Body:
  • Summarized RFC taken based on previous interaction with the customer. With required:
    • Scope.
    • Current state with business justification and impact.
    • Proposed solution.
    • Timeline & Priority.

Remain in contact with the L2 – Daktela Support Team for any further information or cooperation required until the L2 – Daktela Support team has assessed the Change Request and given L1 – Partner Support Team further instructions.

The L2 – Daktela Support Team has up to 5 business days to evaluate the RFC and report back to the L1 – Partner Support Team. This is due to fact of L2 – Daktela Support Team internal processes.

5. Regular Customer Updates

• The L1 – Partner Support Engineer is responsible for providing regular updates to the customer throughout the Change Request lifecycle.
• Any new circumstances, customer feedback, or additional information received will be passed on to L2 – Daktela Support Team) for further processing.
• If necessary, the L1 – Partner Support Team will organise a meeting between the customer and the L2 – Daktela Support Team to clarify requirements or address technical concerns. Updates should include:
• Current status of the request.
• Actions taken so far and next steps, if any**.**
• All updates must be documented in the ticket system for reference. Include the internal notes for teammates.

6. Request Validation by Level 2 – Daktela Team

Once all tasks have been completed by L2 – Daktela Support, L1 – Partner Support will receive the following options of the result:

1. Approved – Ready for implementation:

   • The Change Request from the L2 – Daktela Support Team has been returned with a proposed solution, an estimated effort in MH/MD of Professional Services, and a delivery timeframe for implementation. This timeframe outlines when the solution will be prepared, tested, and deployed.
   • The L1 – Partner Support Team will process the request, potentially involving the Partner Sales Team for cost considerations, and present it to the customer. Customer or Partner approval of the cost is required before implementation can proceed.
   • Once the costs are approved, an official order for professional services must be submitted to Daktela. Implementation will only begin after Daktela has received and accepted the order.
   • During the implementation phase, consultations with the customer may take place, and the customer may need to collaborate with the L2 – Daktela Support Team. If necessary, meetings may be arranged to clarify requirements or demonstrate progress.
   • The process concludes with the handover and acceptance by the customer.

2. Refused to implement – Product change:

   • The Change Request from the L2 – Daktela Support Team has been refused as a custom solution, with a detailed explanation of the reasons.
   • Internally, the Daktela Product Team has evaluated the request and decided to add it to the Productboard for further assessment. It will be considered as a potential feature for future core product development in upcoming major versions.
   • This decision does not have a definitive evaluation timeframe and may still be rejected in the future. For future updates, partners should refer to the Daktela Roadmap: https://roadmap.daktela.com/tabs/1-under-consideration
   • The L1 – Partner Support Team will process the response from L2 – Daktela Support Team and present it to the customer.

3. Refused to implement:

• • The Change Request from the L2 – Daktela Support Team has been refused, with an explanation detailing why it is not feasible as a custom solution and why it has not been considered as a potential product change.
  • The L1 – Partner Support Team will process the response from the L2 – Daktela Support Team, involve the Partner Sales Team if needed, and present it to the customer with a clear explanation of the reasons for refusal.