Maintenance and Support Program: Detailed Overview
Dexco’s maintenance and support program optimizes the firm’s investment in Acumin by including new releases and versions that employ present-day technology to leverage intended use-case and industry best practices expressed as functional and/or reporting Acumin alternatives.
Maintenance is an evolutionary development effort that is applied over the software’s lifetime. This portion of the program is Dexco initiated, and it includes:
-
Corrective maintenance: Reactive product modification efforts performed after initial deployment to correct identified findings throughout the life of the product,
-
Adaptive maintenance: Product modification efforts performed after initial deployment designed to keep Acumin relevant within a changing technological environment.
-
Code-refactoring maintenance: The restructuring of existing code to improve the non-functional attributes of Acumin without changing its external behaviour.
-
Preventive maintenance: Product modification efforts performed after initial deployment designed to detect, correct and/or control latent software product faults before they become effective ones.
-
Optimization maintenance: Product modification efforts performed after initial deployment designed to improve performance and/or product maintainability, as well as optimize existing programmatic procedures and controls including the deletion of obsolete and non-relevant capabilities;
-
Integration of organization-specific out-of-scope functionality.
In addition, the program includes the following client services in a limited capacity:
-
Guidance on the capture of information needed for Dexco to reproduce reported issues to move from investigation to diagnosis;
-
Access to our helpdesk for responses or documentation to product-relevant questions, independent of business processes specific to the firm;
-
Presentation of client-proposed enhancements to product design teams.
Where to Start
To initiate a support request, one of the firm’s elected support representatives will send a well-documented email to support@dexco.com following the requirements below. This limits multiple communication iterations, allowing us to advance the investigation-to-diagnosis or response process, for a most effective and timely outcome for the requestor.
Create one ticket per issue: Each issue or question must be sent separately to ensure that the right SME takes ownership, and the level of prioritization is adhered-to.
Include the firm’s name especially if the billing-process is handled through the firm’s management company or if the support request is initiated by an external IT department.
Provide a brief description of the support request. Having access to this information expedites how we direct the ticket.
Product Malfunction - Unwanted-Outcomes, Findings or Errors
If the support ticket is to report an unwanted outcome, finding or error also include:
The level of severity, as part of the initial email subject line. Please ensure that when specifying an “Issue Severity”, you respect the provided pre-defined “Use-When” context. Mis-identifying severity can result in associated delays in service.
|
Issue Severity |
Use When |
Service Priority |
|
Critical |
It affects all users preventing them from executing their respective responsibilities |
Escalated for action within two (2.0) business hours |
|
High |
A time sensitive task that cannot be completed by any user |
Expected for action within the next business day |
|
Medium |
A non-time sensitive task cannot be completed by any user |
Anticipated communication on next steps within the next three (3) business days |
|
Low |
Trivial incidents with minor impact to functional use-case. |
Projected communication on next steps within the next seven (7) business days |
The objective, or expected outcome upon resolution, to mitigate any potential gaps as we move through the investigation-to-resolution cycle.
Detailed information on how the finding was first discovered, to ensure we can re-create the scenario and outcome. Include a step-by-step account leading up to the finding, with complete screenshots of the steps taken, options selected, messaging received through the process and highlight the unexpected or unwanted outcome. The steps and screenshots will drive how quickly we can identify what went wrong.
Product Use - Request for Information
If the support ticket is to request information on product-use, provide background material so we can be in a better position to offer alternatives and best-practice recommendations where applicable. The goal is to provide as much information as possible to mitigate the potential for incorrect assumptions on our end. Consider including:
A background statement on the scenario or process affected, and/or;
A current position statement describing how users are working or dealing with the scenario or process currently, and/or;
A functional statement that explains what functionality users want to leverage to respond to the scenario or process and/or;
A use-case statement illustrating expectations on typical use-case.
Product Enhancement Requests
Requests for product enhancements, for example functional add-ons, new data points or attributes, additional measures or reports; are assessed in context of gains to the community, therefore it must include information to help build a strong thesis. Include:
The problem or benefit to be addressed. Be specific the pain point or expected gain.
The result. The expected outcome because of the enhancement.
A Description. Describe the enhancement and include the expected result.
An Example. Provide an example that illustrate the benefits of the enhancement.
Process
Initial email response includes the ticket number: The sender will receive an automated first response acknowledging receipt and providing the ticket reference number. It is presented within square brackets following the text “irf.dexco.com #” – for example [irf.dexco.com #85400]. This process ensures that on-going communication on a support request is kept within the same file and prioritized for resolution.
Initial Assessment and Triage: The support request is assessed, triaged, and assigned for next steps - investigation-to-diagnosis, response, or out-of-scope services.
E-mail Trail Requirements: Follow-up and/or on-going communication on the same issue must include the controlled ticket number in the format described at the start of the subject line; else ensuing emails will trigger the automatic creation of new tickets, resulting in associated delays in service.
Additions: Do not add additional issues or questions to the ticket along the way. Create a new one to expedite resolution.
Other Steps in the Process: Once assigned the support desk analyst or SME (Subject Matter Expert) will manage remaining steps in the process following the same e-mail trail requirements as the client’s support representative. These steps may trigger additional communication with the support representative and/or escalation to other SMEs as well as subject-line changes to align with findings and outcomes.
Resolution: Once the support request is responded, it is closed, and no further communication will ensue unless the client communicates using the same support ticket.
Database Access: Dexco personnel will not access databases within the organization’s environment, unless explicitly authorized by the client.
Support and Help Desk Classifications
Out-of-Scope (OOS):
Out-of-scope (OOS) services are the result of firm-specific requirements, and/or findings not covered by the Maintenance and Support program. Where applicable, services initially considered in-scope deemed out-of-scope once cause is established as not Acumin-related; are billed on a retroactive-time-spent basis.
Findings which cannot be replicated are closed as unresolved until more information is provided, and the issue can be reproduced. Firm-requested analysis for non-duplicable issues is a paid-for service, billable on a time and rate basis, unless product failure is identified during the analysis. In this case, the time spent is covered by the program.
Services to resolve findings that are user or environment specific - relating to network (hardware or software), the users’ workstation, and/or set-up – installation requirements etc., are a paid-for service, billable on a time and rate basis, unless product failure is identified during the analysis. In this case, the time spent is covered by the program.
Services for issue resolution in context of third-party product or process use-cases, including those resulting from e-bill submissions which are not directly attributed to product malfunction, are a paid-for service, billable on a time and rate basis.
Service Scope
Client responses will be informative in context of product functionality and intended use-case, however responses beyond this limited scope, are a paid-for service administered through the statement of work (SOW) process and billable on a time and rate basis. The following are examples of responses and activities not included in the program:
-
Resolution to business problems or description of product-use in relation to firm processes,
-
Correction protocols for product-misuse or user-created errors,
-
Process improvement recommendations or re-engineering endorsements, as well as development of firm-specific processes to leverage Acumin functionality,
-
Topical training, job-skills training, and/or analytical requirements of the position,
-
Implementation and set-up services of new or unused options or changes thereof,
-
Third party product or process issue resolution including those resulting from e-bill submissions which are not directly attributed to product malfunction,
-
Error resolution strategies for issues triggered by hardware or network malfunctions and/or operating system problems and/or from the lack of adequate daily back-ups,
-
Hardware decisions, operating environment changes, implementation of new programs, updates and/or modifications to non-Dexco programs,
-
Support ticket management for the firm making the support request.
Database updates to correct data structures, failed stored procedures, and/or to fulfill new release or version requirements are included in the program. Database updates beyond this limited scope are a paid-for service administered through the statement of work (SOW) process, billable on a time and rate basis. Out-of-scope examples:
-
Implementation of requirements imposed by others, such as third-party product vendors, government and/or legislative bodies, professional associations etc.
-
Issue -resolution due to user error or misuse, hardware or network malfunctions, operating system issues, third-party integrations, lack of daily back-ups or similar,
-
Updates due to previously completed organization-specific OOS (custom) work.
The Support Representative Role
The firm is asked to designate a person as the knowledgeable point of contact person, who will be responsible for administering the support requests. Their responsibilities include the screening and management of support requests in context of redundancy, priority, cost-benefit, and compliance with internal policies, as well as the management of the communication trail with Dexco’s support desk, along with any ticket management requirements resulting from the process.
This role must be assigned to one or more key person(s) having a conceptual understanding of product functionality and firm processes, covering all functional areas affecting product use. Depending on the size of the firm, the role may need to be split amongst multiple key players based on function.
The Ticket Number
Support requests are logged and organized in our ticketing system, Jira. Each ticket begins with DCS (Dexco Client Support - yes, that’s what it stands for!), followed by the ticket number and your firm code. For example, the subject line of a support email will look like this:
“[JIRA] (DCS-4931) DEX - Issue with Acumin”
To ensure seamless follow-up, all ongoing communication on the same issue must include the ticket number at the start of the subject line. This keeps all correspondence linked to the same file, managed by the same analyst, and prioritized for resolution.
Without this structure, subsequent emails may trigger new tickets, leading to miscommunication and delays in service.