cura client support process introduction

An Introduction to the

Cura Client Support Process

Internal Process Guide

Cura Solution Implementation Process Guide of 20

CONTENTS

The Cura Solution Implementation Process ........................................................................................ 3

Introduction ............................................................................................................................................. 3

Process 1 – Solution Scoping & Building ............................................................................................. 5

Assignment of the Project Stakeholders ................................................................................................ 10

Preparation & Signing of Contracts & Project Plan ................................................................................ 10

The 1st Cura System Configuration Scoping Session .............................................................................. 11

Solution Initiation Process ..................................................................................................................... 12

Solution Refinement Process ................................................................................................................. 13

Other System Builds ............................................................................................................................... 14

Solution Finalisation Process ................................................................................................................. 15

Process 2 - System Deployment ....................................................................................................... 16

Technical Deployment ........................................................................................................................... 17

User Deployment ................................................................................................................................... 18

Refinements Deployment ...................................................................................................................... 19

Final Deployment/Project Closure ......................................................................................................... 20


THE CURA CLIENT SUPPORT PROCESS

INTRODUCTION

This document aims to familiarize the reader with the internal processes, steps, requirements and general skills that are necessary and mandated by Cura as part of the client software support requirements.

This is an internal document aimed at Cura employees operating in the client support function within Professional Services. It is not to be disseminated externally.

TERMINOLOGY

In order to understand the support process flow diagrams and explanation, it is necessary to be familiar with the relevant terminology. The most important terms to understand are as follows:

Call/Request Any communication from an external Cura user or client representative which requires a

resolution be found by the Cura Client Support function by following the due mandated processes herein.

Client/User Any licensed Cura Software user requesting assistance

Log (Call/Request) The act of initiating a support request or call by capturing its details into the Microsoft®

CRM system, according to the mandated requirements, and issuing the relevant client with a system generated support call number to the client, signifying a support call initiation/log date.

B.O.A. Business Operations Analysis, as a function within the Cura Product Support department,

acting as the liaison between itself and Cura Client Support / Professional Services department for issue/call escalation and resolution activities.

Client Support Support offered to Cura Users, performed by the Cura Client Support function in the

Professional Services department, relating only to Cura user related issues regarding a fully functional product, and not relating to any of the product’s inherent functionality, capabilities, or bugs.

Product Support Support offered to Cura Client Support, performed by the Cura Product Support function in

the BOA/Development department, relating only to Cura product related issues such as enhancements, bugs, system errors and similar product issues, and not relating to any of the product’s user issues.

Communication(s) The act of ensuring valuable and relevant information is passed from the Cura Support

Representative to the Cura user logging the support request, or vice versa, using whatever means necessary.

C.R.M. Microsoft’s® Client Relations Management software, as implemented and configured in

Cura as the support call management system.

C.R.M. 2nd Queue A nominated area of Microsoft® CRM data fields that must be duly completed before any

support call is escalated from Client Support to Product Support. Support calls residing in the C.R.M. 2nd queue remain the resolution and client communication responsibility of the Cura Client Support Representative who originally logged the call, and must act accordingly.


Escalation The act of calling upon other Cura Support or Professional Services resources, or other Cura

department representatives, by the Client Support Representative, to offer assistance or assume responsibility for resolution of a particular support call, performed only through the necessary processes and mechanisms, but still retaining and assuming Client Support and communication functions, unless otherwise agreed.

S.L.A. Service Level Agreement which may be applicable to a particular customer which

contractually dictates the expediency and manner in which support calls are managed and resolved, in return for an agreed remuneration. 3 Levels of standard S.L.A. options are available (Bronze, Silver, Gold). These are further detailed in Chapter X

Resolution A support call is resolved and closed only once the Support Administration Manager has

reviewed the communications and responses between the Cura Support Representative and the Cura user/client, and deems the issue to be suitably resolved. A support call can only be closed once it is directly addressed and resolved to the satisfaction of the client, or in certain cases at the Support Administration Manager’s discretion, but cannot be closed based on reassignment to another person or department within Cura.

Quality Assurance The checking of the content, quality and overall value of any potential call resolutions

submitted by the Cura Client and/or Product Support Representative before being communicated to the Cura Client as a potential resolution.

Cura Global Any Cura representative performing any support function outside of Cura’s South African

headquarters, including interaction with the Microsoft® CRM system and/or Cura’s Product Support/BOA representatives.

Graphical Example of the Cura Client Support Process (attached):


THE CLIENT SUPPORT PROCESS

The overall client call logging and support process is a simple, systematic approach that ensures certain key elements of responsible, professional service is met. The key focus and aim of the process is to:

Ensure the request is logged immediately and that the client receives their request’s reference number as soon as possible;

Ensure the client is communicated regular updates at all stages of their request resolution;

Ensure the request is assessed and assigned to the appropriate personnel and attention levels by the Support Administration manager;

Ensure the request is duly followed up on, recorded and reported on regularly, in a well managed manner, both internally and externally;

Ensure that, where a request cannot be resolved by the Client Support staff, it is investigated further (within Cura Professional Services) or handed over responsibly and correctly (to Cura Product Support) for resolution, while maintaining internal and external communication standards;

Ensure that skills within the Support Team are nurtured, shared, grown and utilised proactively and efficiently within the Team;

Ensure the Cura client request is handled professionally and efficiently to the best of the Team’s ability.


STEP 1: REQUEST RECEIPT, EVALUATION & ASSIGNMENT

Cura users will log calls and requests in one of a few ways, being either telephonically, via the Cura support web portal, or email. Each is to be treated in the same manner.

Graphical Representation of the Client Support Request Evaluation & Assignment Process:

The following actions apply during the first step: 1.1a If the support call is made telephonically, the details of the call must be immediately captured on

the Cura CRM system at the time the client is logging the support call – this will generate a unique CRM log number and request summary. If the client is logging a call telephonically, the Support Team member must immediately perform steps 2 and 3 below at the same time.

1.1b If the client logs the support call via email or the web portal, the request must be reviewed and

captured into the CRM system within a maximum of 4 hours of the call being logged by the client – this will generate a unique CRM log number and request summary.

1.2 The client is to be informed of their unique generated CRM request log number. This is usually

done via email, but if not applicable or the client does not have email access, this must be done telephonically or via SMS. If the log number is given telephonically at the time of logging the request, it must also be substantiated with an email confirmation sent to the client containing the same CRM log number and request details.


1.3 Every client is to have their relevant information captured as a reference point for support and client management purposes to best serve the client, on the CRM system. Therefore, the very first part of any support call process is to recall, review and update the details captured on CRM. This means opening the client information on CRM and asking the client to confirm, as far as possible, the following details:

- Client’s primary Cura point of contact/main user; - Client full contact details; - Client’s Cura Version and Modules.

The above information should be requested as a minimum – out of date or missing client details on the CRM system should also be queried in order to create and maintain a reliable and complete client record on the CRM system.

1.4 If a support request can be resolved immediately i.e. the request is made and resolved

telephonically to the client’s satisfaction, the CRM client data updating, call logging, communication and closure processes and steps must still be followed. However the Support Team member may proceed directly to the Support Request Closure process steps once the request is resolved.

1.5 Once a request is logged, its full details must (if applicable) be passed on to the Client Support

Administration manager in order to undergo an initial diagnosis. This can be done immediately, or can be done during the Open Request Review step (as part of the Request Escalation process), whichever is most appropriate insofar as expediting a request resolution, in order to:

- Determine if any Service Level Agreements exist with the customer (and act accordingly);* - Perform initial review of the request to determine if the request falls within the Client or

Product Support department;** - Assign a Client Support Team member as responsible for the support call resolution.

* If a Service Level Agreement exists with the client, this must be immediately communicated to the client as part of the request communication processes. Thereafter, all contractual obligations of the Service Level Agreement must be adhered to in every respect when dealing with the support request.

** If the request is initially assessed by the Client Support Administration Manager and deemed to be a Product Support request, the call must still be logged in CRM and communication sent to the client, but the

support call process can skip to the Request Escalation process.

1.6 Once the above steps are complete, the support request enters the Request Resolution process.

Call Receipt, Evaluation & Assignment Summary:

The client logs a support call in a particular manner, which is logged and responded to either immediately or within a maximum of 4 hours;

Cura Client Support log the call details on CRM, which creates a unique log reference number which is immediately communicated to the client;

The client’s details are updated on CRM by the person logging the request by asking the client various questions, as necessary, and updating the details on CRM;

The support request is assessed by the Cura Client Support Administration Manager;

The support request is assigned to a suitable Client Support Team Member, and enters the Request Resolution process, or escalated to Cura Product Support via the Request Escalation process.

Maximum/target time period of all Step 1 Process execution: 1 Business Day/8 Hours


STEP 2: REQUEST RESOLUTION PROCESS

Once the support call has been diagnosed by the Client Support Administration Manager and assigned to a Client Support Team Member, it enters the Request Resolution process.

Graphical Representation of the Client Support Request Resolution Process:

The following actions apply during the second step:

The client support call has been evaluated and captured by the Client Support Team member, and the request has been assigned to an appropriate person for resolution. From here, the request can follow different routes of resolution:

2.1a The assigned Cura Client Support Team Member evaluates the request requirements, and is able

to completely assess, understand and resolve the cause of the client’s problem;

2.1b The assigned Cura Client Support Team Member executes the necessary steps to resolve the

client’s problem;


2.2a The assigned Cura Client Support Team Member evaluates the client request requirements, and,

after applying the appropriate internal and external support function steps, processes and

protocols, is unable to effectively resolve the request.

2.3 Request resolution may require data to be sent by the client for analysis and resolution

assistance. This may include the client’s methodology, captured information, database, data

exports or extracts, printouts or other information. In all cases, the Client Support Team Member

must provide the client

Communication must be relayed to the client on a regular basis (at least daily or more frequently

depending on the circumstances of the request, service level contractual obligations or client

demands);


ASSIGNMENT OF THE PROJECT STAKEHOLDERS

The essence of project success depends on the commitment and skills of the people involved. The first part of the project will be identifying these people and assigning them to their individual or team project responsibilities. Typically, the project may require the following stakeholders:

From the Client:

The Project Sponsor; *

The IT Manager/Administrator;

The Risk Management Team; *

Legal Department Representatives;

Management Staff (as required); *

Cura End Users.

From Cura:

Sales Staff (Account Manager);

The Professional Services Manager; *

The Business Analyst; *

System Configuration Consultants;

The Implementation & Technical Installation Team (as required);

Support Team (post implementation).

* These persons or representatives, at various stages and for various portions and durations throughout the project, would normally form the Project Steering Committee

The key stakeholders in most projects would be your elected representatives, the Cura Business Analyst, and the Cura Configuration Consultant assigned to the project. The resources assigned from Cura will become responsible for the

overall creation of the solution according to your needs and expectations, and are supervised in terms of the project progress and quality by their respective managers.

PREPARATION & SIGNING OF CONTRACTS & PROJECT PLAN

The overall aim of the initial phase of the build is to establish, at the outset:

Who the role players are for the duration of the project and their responsibilities;

The contractual obligations between the Client & Cura (EULA, Payment terms, time frames etc.)

Project tasks, milestones, due dates and timelines, all within an agreed Project Plan;

The documented functional specification and configuration of the proposed Cura solution;

The technical environment of the Cura implementation (Server, database, operating systems & other IT related Cura installation issues etc.);

The operating environment of the Cura implementation (Identify system users, assess training needs, set permissions, proposed adjustments to risk processes etc.);

Training requirements for all Cura users and modules;


System ongoing support and final delivery details.

The tangible outputs and events of the above tasks, as part of the Initiation Phase, may include:

A joint meeting between the Project Sponsor and the Cura Project Team (Business Analyst) to openly discuss the various project stages, expectations, critical points and similar broad concerns;

Producing the detailed project plan for approval;

Producing and signoff of all other contractual project obligations.

THE 1ST CURA SYSTEM CONFIGURATION SCOPING SESSION

Graphical Example of the Solution Initiation Process:

Solution Initiation Process

1st Build

Specification1

st Business

Solution Synopsis1

st Build & Spec

Quality Checked1

st Meth

Build

A critical milestone for the start of the project, and overall project delivery, is the very first scoping session or configuration workshop. This session may be held over a number of days whereby the appropriate representatives from both your risk management team and Cura discuss and document the way the solution will be configured to work within your environment. The workshop will touch on issues which will affect the eventual configured solution, such as:

The overall business case and key objectives of the solution;

The building of the Cura methodology, workflow & layout;

The reporting requirements for the solution;

User based permissions structures;

Possible use of additional Cura tools & capabilities (e.g. Convert, Meth Builder, Report Writer, Knowledgebases etc.);

Cura training requirements;

The IT Infrastructure requirements and possible impact of the proposed Cura solution;

Any other issues of concern or questions surrounding the solution.

A well administered and executed project initiation workshop will ensure all expectations are clearly understood, documented and met according to a set plan, which will ultimately define the success of the project.


SOLUTION INITIATION PROCESS

Discussions during the first workshop will be carefully recorded and documented to form the specification document which will define the way the solution is built. It is important to realize 2 key outputs of the 1st scoping session, which will form the foundation of all subsequent configuration and system refinement tasks:

The Business Analyst will prepare a “Project Business Case Synopsis”, which is a short, high level description of your core business requirements, translated into key capabilities that are to be contained in the final Cura solution that is configured and delivered;

The Implementation Consultant / Business Analyst will prepare a technical specification document which defines the detailed configuration of the Cura solution according to your requirements put forward during the scoping session.

These documents will be presented to you at the same time the first build is demonstrated. They will be constantly updated to reflect the outcomes and requirements that are defined during the Solution Refinement Processes, recording the configuration changes that will occur during the solution development life cycle.

The combination of these two documents will evolve into a final product functional specification document which will contain, amongst various other things;

Proposed screenshots of the solution GUI;

Grid presentation of the data input fields;

The agreed domain, assessment, context and risk tree structures;

Lists of Cura users and their proposed permission structures;

Samples of the agreed report requirements, and content listings thereof;

Any and all additional details regarding other solution options and enhancements (add on modules, knowledgebase details, architecture topology etc.)

The initial system configuration phase can vary in length from a few days to many weeks, depending on the size, extent and nature of your specific system configuration. This is done by the implementation consultant, under the supervision of the Business Analyst charged with the project’s success.

Once the configuration is complete, the solution is presented by the Implementation Consultant and the Business Analyst to the Cura Quality Assurance Team. The configuration will be signed off by the team, before being presented back to you for demonstration, discussion and review.

It is important to note that only the solution’s methodology will be developed during this period. It also ensures that the initial design is delivered in as short a time frame as is possible. The remaining components of the solution hinge on the correct methodology being built as their foundation.


Solution Initiation Process

1st Build

Specification1

st Business

Solution Synopsis1

st Build & Spec

Quality Checked1

st Meth

Build

SOLUTION REFINEMENT PROCESS

Once the Cura Business Analyst is satisfied that the understood configuration meets your needs, as well as the initial specification, it is put forward in the form of an interactive demonstration. In some cases the on-screen product highlights further requirements or potential changes to the original solution as contemplated in the original scoping session.

Graphical Example of the Cura System Refinement Process:

Further

Refinements Scoped

1st Build

Demonstrated

Spec Documents

Updated

Refinements

Demonstrated

1st Refinements

Scoped

Build & Spec

Documents

Quality

Checked

Solution Refinement Process

Refinements

Built

These enhancements, tweaks and refinements are all carefully documented by Cura, and appended to the specification documents to track the progress of the system development cycle. Some refinements may be done in a matter of hours, while other changes may require days to configure.

This process of “Build – Demo – Workshop Refinements – Document Refinements – Build Refinements

– Quality Check Refinements – Demo” continues until you are satisfied with the presented system

configuration. However, it is neither recommended nor usual for more than 2 refinement sessions to

be conducted, depending on the scale of your system implementation, and the maturity of your

internal processes.


OTHER SYSTEM BUILDS

It is important to note that while the solution refinements are being documented,

executed and demonstrated, there are various other important stages and

preparations that the final solution must go through in order to be effectively

delivered. These must be discussed and planned around during all scoping sessions

to ensure that once the system framework has been agreed upon and signed off, it

can be successfully implemented into your environment shortly thereafter.

The diagram on the left shows some of the more common project tasks that must

be completed while the system is being configured:

Assess the IT Environment – Cura will require a suitable architecture of

servers, networks, client machines and other IT hardware affected by the project.

Depending on the scale of your implementation, Cura will guide you in terms of a

recommended IT environment, while taking note of your existing setup. The

chosen architecture will be tested to ensure it supports the final product delivered

to you and your Cura users.

Specify the Reporting Requirements – The core output of Cura is the ability to

deliver meaningful and accurate reports from the user front end. Therefore, part of

the client mandate is to suggest the reporting outputs that they desire from the

system. This extends to the desired report layouts, data contained therein, how

many reports are needed, to whom they will be distributed etc.

Gather Client Data – Part of the system delivery may require taking existing

data and migrating it into Cura. Different clients have different methods of

managing their data, so the Business Analyst will obtain this data early in the

project cycle to assess how it may be captured within Cura.

Assess and Define the User Base –The user base needs to be considered i.e. How many users will

there be? What is their geographical profile? What is their level of current involvement or

competency area? Will they require new hardware? How shall we approach training these people?

Other Considerations – There are other considerations which will be addressed, e.g. user manual

customization, Web vs. Rich client user base, future expansion requirements, business process

alignment and change management These are often identified during the workshop sessions, and

suitably managed during the system development and implementation phases of the project.

With all of these project factors considered, we can bring the various stages together to deliver the final

solution. Once the final system configuration is agreed to, there is a minimal time lapse between that

point and the actual delivery of its supporting documentation and architecture/user/data configuration

and necessary data.


SOLUTION FINALISATION PROCESS

Once the client is satisfied with the configuration demonstrated, the final changes are made to the specification documents to support the agreed solution, which is then presented to the customer. This document will be put forward and signed off by both Cura and the client as acceptance of the completed system build and configuration thereof. It will also serve as a formal means from which to develop internal processes, training manuals, and other important outputs.

Thereafter, the project team looks towards the next phase, whereby the correctly configured solution can be installed within the client’s environment and work processes.

Graphical Example of the Final System Configuration Acceptance Process:

Solution Finalisation Process

Refinements

Approved

Final

Demonstration

Spec Documents

Approved

32

1

Reports, Data &

Config Approved

Documentation &

Contracts Signed


PROCESS 2 - SYSTEM DEPLOYMENT

The final stage of the implementation is where the entirely configured solution is transferred to your environment. The deployment process follows 4 key functional steps towards project completion:

Technical Deployment;

User Deployment;

Refinements Deployment (Final Review);

Final Deployment/Project Closure & Handover.

Graphical Example of the Cura System Deployment Process:

Approved &

Specified Solution

Technical

Acceptance TestingServer Environment

Installations

DEPLOYMENT

System

Config

Technical Deployment

Reports &

Feedback

User Deployment

User Acceptance

TestingUser Config

Manual

Compilation

Refinements

Request

Full CURA Training

Project Signoff

DEPLOYED

Client File

Handover

System

Signoff

Pilot Deployment

Hardware

Installation

System &

User Config

Basic

CURA Training

Test

Refinements

Refinements Deployment

Refinements

Assessment

Refinements

Specification

Refinements

Approved

Build

Refinements

Deploy

Refinements

Evaluation

Period

Purchase

Decision

Account Manager,

BA & Client


TECHNICAL DEPLOYMENT

Being an integrated software solution, Cura relies on a reliable network infrastructure, geared to suit the client’s needs. The IT infrastructure on which Cura is to run must be assessed early on in order to ensure its suitability.

As mentioned, the IT requirements are discussed during the product functional specification workshops. The goal therefore is to prepare the technical (IT) deployment environment in such a way that the software is ready to be deployed at the time that the final refinements are completed.

Cura’s software/server infrastructure employs the (possible) use of 3 tiers:

Application Server

Web Server

Database Server

* A 4th Tier could be implemented if a separate report server is to be deployed

Each of these servers can be physically separate pieces of hardware, or combined on the same machines to suit the client. In large, enterprise wide installations, splitting of the servers is encouraged in order to facilitate maintenance and maximum available uptime of the solution, but smaller Cura installations can combine all 3 server functions onto one server device without any problems.

In all cases, when taking the technical deployment into account, it is important to remember certain key areas and targets, in order to ensure:

The hardware is suitable and capable of supporting the developed solution;

The hardware and supporting software is accessible (physically and regarding security measures) to the Cura implementation consultant;

Client technical resources are made available during the installation;

Client software installation protocols, internal processes and control measures are adhered to;

System functionality, logon, upgrading and migration testing is completed successfully;

The hardware and software is regularly maintained and backed up by the client to ensure uptime and disaster recovery of the Cura solution.

The implementation consultant will perform detailed environmental audit is performed prior to installation in order to ensure a successful system installation.

Detailed hardware requirements are annexed to this document for easy reference.


USER DEPLOYMENT

Deployment of the Cura users within the client environment and workspace comprises of 5 core tasks:

Identify the Cura User Base

Setup User Permissions

Development of Training Materials & Method

Training of Users

Cura User Support

Identify the Cura User Base People within your organization who will maintain, manage and draw value from the system should be identified early on in the project planning sessions. It often helps to identify and alert the identified proposed system users early on in the project process, so that they can prepare themselves for the responsibilities of their new role as a Cura user. Often they will be invited by the project team to offer input into the system configuration. During the system scoping phase, the Cura user list be discussed and tabled, so that it is ready at the same time as system deployment. Setup User Permissions Each Cura user will be assigned certain capabilities and user roles within the software setup. Certain users will be allowed unlimited system access and manipulation (System Administrators), while some will only be able to view captured data. The security setups and group permissions allocation within Cura’s built in security allows for a multitude of different user permissions, so that each Cura logon rights is configured appropriately. One must consider the various rights and permissions of each user and/or group they fall into. User rights are often process-driven. Development of Training Manuals & Methods Cura offers customized training to their clients. The training manuals themselves are reviewed and customized by our training department to ensure they are perfectly aligned with the actual system that is being deployed. Cura can accommodate various methods of training - the most popular approach is for Cura to host up to 16 people at one time in our training centre in Houghton. By arrangement, Cura can also conduct training at the customer’s site, provided that the facilities and training setup is suitable. Training of Users Training can take anything from 1 to 5 days, and can be segmented per Cura module or different user category. Specialized training sessions on more intricate Cura capabilities can be administered for those users intended to become “super users” and system administrators. A certain amount of training will have been included in your Cura proposal. This will be reevaluated and amended, should more training become evident as necessary as the project unfolds. Cura User Support The Cura EULA includes extending telephonic and email support to all users post implementation. This support line offers assistance on basic user operations and overall system use. A support contact sheet is included in this pack. During the scoping sessions, a detailed support process customized for your organization will be discussed and documented.


REFINEMENTS DEPLOYMENT

Very often, it is only after the user training sessions that Cura users identify certain product requirements or enhancements, and wish to have these built into the system. While it is not encouraged to undertake large system changes after training (especially since the training manuals and content is largely based on the original specification as has already been developed and installed), small changes can be accommodated.

Large change requests, deemed to be non critical, are usually documented as future change requests to be implemented after the users have come to grips with the system, rather than being immediately put in place, to avoid delays in system rollout and possible user confusion.


FINAL DEPLOYMENT/PROJECT CLOSURE

Once any minor refinements have been configured, they are loaded into the Cura system, and the system migrates to the Client’s “Live” environment, ready to be utilized within the business processes and environment. At this juncture, and leading up to it, various system tests are performed in order to ensure the overall solution is delivering as was required, and as per the now finalized functional specification document(s).

Once the system has passed all tests, the final documentation is signed off by Cura and the Client, and the project is closed. Depending on the nature of the project and implementation approach, the customer is handed copies of the software, all contractual and specification documentation, and other supporting information that detail the entire project experience from start to finish.

Ongoing support and possible system expansion opportunities are also discussed, to ensure the implemented solution continues to meet the needs of every client. In most cases, all stakeholders are invited to the project closeout meeting.

During the Close-Out meeting, the Professional Services team will formally introduce the Cura Support team.

Best Regards

The Cura Professional Services Team

cura client support process introduction

Documents

solution initiation

solution refinement

solution finalisation

cura client support

cura employees

external cura user

support process flow

client representative