Cura Client Support Process Introduction

Page 1

An Introduction to the Cura Client Support Process Internal Process Guide


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

Cura Solution Implementation Process Guide

Page 2 of 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.

Cura Solution Implementation Process Guide

Page 3 of 20


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):

Cura Solution Implementation Process Guide

Page 4 of 20


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.

Cura Solution Implementation Process Guide

Page 5 of 20


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.

Cura Solution Implementation Process Guide

Page 6 of 20


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

Cura Solution Implementation Process Guide

Page 7 of 20


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;

Cura Solution Implementation Process Guide

Page 8 of 20


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);

Cura Solution Implementation Process Guide

Page 9 of 20


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;

Cura Solution Implementation Process Guide

Page 10 of 20


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 1 S T CURA SYSTEM CONFIGURATION SCOPING SESSION

Graphical Example of the Solution Initiation Process: Solution Initiation Process

1st Business Solution Synopsis

1st Build Specification

1st Meth Build

1st Build & Spec Quality Checked

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.

Cura Solution Implementation Process Guide

Page 11 of 20


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.

Cura Solution Implementation Process Guide

Page 12 of 20


Solution Initiation Process

1st Business Solution Synopsis

1st Build Specification

1st Meth Build

1st Build & Spec Quality Checked

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: Solution Refinement Process

Spec Documents Updated 1st Build Demonstrated

Refinements Built

1st Refinements Scoped

Further Refinements Scoped

Build & Spec Documents Quality Checked

Refinements Demonstrated

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.

Cura Solution Implementation Process Guide

Page 13 of 20


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.

Cura Solution Implementation Process Guide

Page 14 of 20


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

3

Final Demonstration

Refinements Approved

Cura Solution Implementation Process Guide

Spec Documents Approved

2

1

Reports, Data & Config Approved

Documentation & Contracts Signed

Page 15 of 20


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: DEPLOYMENT DEPLOYED

Technical Deployment

Approved & Specified Solution

System Config

Server Environment Installations

Technical Acceptance Testing

System Signoff

Project Signoff

Client File Handover

User Deployment

User Config

Manual Compilation

User Acceptance Testing

Refinements Request

Full CURA Training

Reports & Feedback

Account Manager, BA & Client

Refinements Deployment

Refinements Specification

Refinements Assessment

Test Refinements

Build Refinements

Deploy Refinements

Refinements Approved

Pilot Deployment

System & User Config

Hardware Installation

Purchase Decision

Cura Solution Implementation Process Guide

Basic CURA Training

Evaluation Period

Page 16 of 20


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.

Cura Solution Implementation Process Guide

Page 17 of 20


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. Cura Solution Implementation Process Guide

Page 18 of 20


REFINEMENTS

DEPLOYMENT

Very often, it is only training sessions that certain product enhancements, and wish into the system. While it to undertake large after training (especially manuals and content is the original specification been developed and changes can be

after the user Cura users identify requirements or to have these built is not encouraged system changes since the training largely based on as has already installed), small accommodated.

Large change requests, critical, are usually future change requests after the users have the system, rather than put in place, to avoid rollout and possible user

deemed to be non documented as to be implemented come to grips with being immediately delays in system confusion.

Cura Solution Implementation Process Guide

Page 19 of 20


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 Solution Implementation Process Guide

Page 20 of 20


Turn static files into dynamic content formats.

Create a flipbook
Issuu converts static files into: digital portfolios, online yearbooks, online catalogs, digital photo albums and more. Sign up and create your flipbook.