Fly By Night CSD Guide

CSD Guide for Fly By Night Pty Ltd

Client Policies & ProceduresVersion 1.0

Yardi Systems IncCSD Guide for Fly By Night Pty Ltd Client Policies & Procedures

Version Control

Version Date Author Comments1.0 2/10/2014 Chris David Handoff Copy

Page | 2 of 13

Yardi Systems IncCSD Guide for Fly By Night Pty Ltd Client Policies & Procedures

Table of ContentsIntroduction..................................................................................................4

A. Account Management Structure.............................................................4

B. Escalation Points...................................................................................4

C. Case Severities......................................................................................5

D. Key Yardi CSD Workflows.......................................................................6

E. Differentiation between CSD and PSG.....................................................9

F. Use of CSD Support Units.....................................................................10

G. CSD Support Framework......................................................................11

H. Monthly Deliverables...........................................................................12

I. Overview of Yardi CSD Global Presence.................................................13

Page | 3 of 13

Yardi Systems IncCSD Guide for FLY BY NIGHT PTY LTD Client Policies & Procedures

IntroductionFor CSD requests and issues the Client’s Single Point of Contact (SPOC) should email their Account Manager, detailing the request, and if it is an issue with Voyager, the steps to replicate the issue if applicable. The Client can raise a Case through My Yardi and pass on the case to the Account Manager. The Account Manager can also raise a Case on behalf of the Client and try to resolve the issue or escalate the Case as required until the issue is resolved. When complete the Account Manager will email the SPOC with the results/closure notification. Urgent issues should be escalated via a phone call and then followed up via an email if appropriate.

A. Account Management StructureYour Account Manager is your first point of contact. The CSD Account Manager has ultimate responsibility for all Client related Cases, and their timely resolution. The CSD Account Manager effectively owns the relationship with the Client. Contact with CSD can be either by email or phone. For all sales enquiries, please contact Terry Gowan.

CSD Contact Details:Primary Account Manager: Ethan NeoEmail: [email protected]: +61 (2) 8227 2245

Australia/Global Escalation: Chris DavidEmail: [email protected]: +61 (2) 8227 2217Mobile: +61 (4)24 138 832

Overall Escalation: Jigar ShahEmail: [email protected]: +91 (20) 67237305Mobile: +91 9819813138

SalesContact: Terry GowanEmail: [email protected]: +61 (2) 8227 2202

B.Escalation PointsAll CSD issues should be escalated to Chris David (Team leader, Client Services) using his contact details above. The second level of escalation is to Jigar Shah (Director, Global Solutions) using his contact details above. The third level of escalation is to Neal Gemassmer (VP) Work: +852 2851 6638 and Mobile: +852 6108 8052. All Sales related escalations should be to Neal Gemassmer.

C.Case SeveritiesAll Cases that are logged into the Yardi Customer Relationship System (referred to within Yardi as “yCRM” [“why.....CRM”]) are classified with a “Case Priority” of Critical, High, Medium or Low.

Page | 4 of 13

mailto:[email protected]




The severity of the Case is assigned by the Yardi staff member logging the Case, which is normally the CSD Account Manager, as provided for per the executed Contract with the Client, but the severity accorded the issue by the Client is taken into account when the CSD Account Manager assigns on the Yardi severity. The guidelines used to prioritise Cases are as per the executed Contract between Yardi and the Client, however, in general terms, the definitions below are used:

Severity of Case

Definition per Contract

Description Preferred Method of Contact

Yardi Response

Critical Priority 1 Business halted (total inability to perform normal operation)

Client will submit support requests by telephone to Yardi’s application support number.

Response as rapid as reasonably feasible – generally within 2 business hours.

High Priority 2 Business impacted (severe restriction of Client’s Use of the Licensed Programs – a potentially critical problem)

Client will submit support requests by email or Client Central portal.

Prompt response subject only to delays for priority 1 issues, generally within 4 business hours.

Medium Priority 3 Non-critical service requests (any issue that is not a Priority 1 or Priority 2 issue)


Response subject to delays for priority 1 and 2 issues, generally within 1 business day.

Low Priority 3 Non-critical service requests (any issue that is not a Priority 1 or Priority 2 issue)


These items are typically “nice to have”. Response subject to delays for priority 1 and 2 issues, generally within 1 business day.

Note that the “Yardi Response” column indicates the time that the CSD Account Manager is expected to take to acknowledge the issue from the Client, and to log the Case. This time does not represent the time that it will actually take to resolve the issue. Resolution times are dependent on the nature of the issue and may take from minutes (e.g. a simple data fix) to months (e.g. a new controlled plugin).

Yardi would endeavour to provide the Client with daily updates for all “Critical” Cases and weekly/monthly updates for all Non-Critical Cases.

It would be normal practice for the Client and his/her respective CSD Account Manager to keep an open line of communication about open all Cases, and their severity/priority. The Client is always in a position to motivate why a particular Case should be accorded a higher (or lower) severity/priority. Evidence prepared by the Client of the time taken to perform various tasks and workarounds should be used as supporting evidence to request changes to severity/priority. Severity/priority changes for Cases is a process that is well established within the Yardi organisation itself and the Director of Client Services, Jigar Shah, has a weekly call every Thursday with development in Santa Barbara with a primary focus being to escalating Asia-Pacific Cases if necessary.

Page | 5 of 13


D.Key Yardi CSD WorkflowsThere are four key processes in place to manage issues that arise at a Client, namely:

Cases: Every material communication with a Client is logged as a Case. Time spend on Cases by the CSD Account Manager are billed against the Client’s annual allocation of Support Units in 15 minute increments. Cases are equivalent to a “ticket number” in a typical helpdesk system. Note that communication with a Client that may not be logged as a Case would be, for example, a quick inquiry to ask how a particular procedure can be performed or whether Yardi has a certain bit of functionality. Generally speaking, however, all communications with the Client should be logged as Cases. A critical component of Cases is whether or not the time is Billable against the Client’s allocation of Support Units or not. In this regard the overriding consideration is the nature of the issue discussed. If the issue discussed related to a program bug then time will be booked against a Case, but the time will be classified as Non-Billable and will not count against the Client’s annual Support Unit allocation. All other time spent on a Client’s Cases is Billable. The turnaround time for Cases will vary significantly, and will depend on the Severity/Priority accorded the Case. Refer to the “Case Severities” section above. As with TRs, it is not possible to generalise about how long cases take to be resolved.

If it is a program issue or bug in the system then the first thing we do is create a TR (More on “TRs” in the next section) out of the case. Then we do one of two things:

1. If the issue is found to be non-critical i.e. a viable workaround is currently available and we have fixed this in a future plugin

We will request FLY BY NIGHT PTY LTD to upgrade or wait for the issue to be fixed till your next scheduled upgrade. Until that point in time we will ask you to use the workaround. TR is scheduled for a future plugin.

Case will be closed as TR is created . 2. If the issue is a critical issue then we will provide a hotfix. (More on

“Hotfixes” in the section below “TRs” ) A critical issue means “Business has halted” without this issue being fixed

In that case we will create a hotfix related to the case and TR The TR will also be scheduled for a future plugins so that it makes into

the next release of our software Hotfix will be coded for; tested; and then provided to FLY BY NIGHT PTY

LTD for testing Upon confirmation from FLY BY NIGHT PTY LTD we will deploy this in

your live environment – this confirmation has to come in a reasonable time frame i.e. 30 days. The case will be CLOSED if

The hotfix is deployed and confirmed by client If we don’t receive any confirmation on client testing within 30

daysIf it is a data issue – then we will provide appropriate packages for data fix . We

will request confirmation from the client and once confirmed we will close the case. If we don’t receive any confirmation within 30 days then the case will be closed as well.

Page | 6 of 13


TRs: Certain Cases require a change to the application itself. Broadly speaking, these changes can be divided up into bugs or enhancements. If investigation into the underlying cause of the Case reveals that the nature of the Case is such that a TR is required, then this TR should be created on the same day as this conclusion has been reached, or, at the latest, within two days after this conclusion has been reached. TRs are raised with a “CSD Severity” of Hot Sheet, Short List, Critical, High, Medium, Low. All TRs require code changes, whether they are for bug fixes or enhancements, accordingly, all TRs have an inherent element of risk, which is mitigated by testing/Quality Assurance (QA). “Hot Sheet” TRs represent major bugs in the system that have to be fixed immediately. “Short List” TRs represent major enhancements that require serious programming effort and are to be discussed by the relevant TR committee during its weekly/bi-weekly/monthly meetings. Critical issues, which may represent both bugs and\or enhancements are also discussed by the relevant TR committee. High, medium and low issues are raised in Committee as relevant. One also needs to be aware that TRs may be rejected by the relevant Committee and may not be delivered. In these situations, Custom Programming Requests (CPRs) can sometimes provide relief (see below). All TRs are viewed from a cost/benefit perspective by the Committee, and sometimes the risk outweighs the potential benefit. Accordingly, it is not possible to stipulate how long TRs take to resolve, or, indeed, if the TR will be worked on at all.

Hotfixes: Occasionally, a bug or enhancement is deemed so important for the efficient operations of the Client that it is delivered as a Hotfix. A Hotfix normally contains a few updated Pages and/or DLLs that are built on the current version of the Client’s software. As such, Hotfixes deliver fixes and/or enhanced software without the Client having to go through an upgrade. A Hotfix should be created by the CSD Account Manager on the day that it is determined that a Hotfix is appropriate, or, at the latest, within one day of this determination. Hotfixes then require CSD approval (for Asia-Pacific, this is typically provided by Jigar Shah, Director of Client Services) and DEV approval (this is provided by the relevant development lead in Santa Barbara for the module affected). DEV approval often takes an extra day to be obtained. Once approved, a Hotfix should not take more than two working days to deliver. One should note that Hotfixes require a change to core code and need to be thoroughly tested, accordingly, once a Hotfix has been built in Santa Barbara it needs to be deployed to a development server by the CSD Account Manager and thoroughly tested before delivery to the Client. Deployment and testing of a Hotfix, once built by development, should not take more than two or three working days. End-to-end, a Hotfix should be entered, approved, deployed and tested within two to three weeks.

Custom Programming Requests (CPRs): Yardi delivers Client specific reports, interfaces and functionality via CPRs. All CPR work is billable including preparation of the CPR, development of the CPR, testing/QA of the CPR and deployment of the CPR. CPRs are used when Clients cannot wait for a new plugin to deliver new functionality or when Yardi does not agree that it would be beneficial to all Clients to incorporate new functionality into the base/core product. Not all functionality changes will be considered as being appropriate for

Page | 7 of 13


a CPR by Yardi. In summary, most changes that affect the base/core system (e.g. transaction processing or the bank reconciliation) and core processes (e.g. rent roll process or pay cycle process) will not be considered as being subject to change via a CPR. The correct route for changes to the base/core of Yardi is via the TR process described above. The vast majority of CPRs are for Client specific reports that may be generated as scripted, SSRS, YSR or Analytic reports and for interfaces to other systems. Scripted, SSRS and YSR reports are fairly simple to create/maintain and have the lowest cost to the Client, in contrast, Analytic reports are more difficult to create/maintain and have a higher cost to the Client. Complexity and, thereby, cost for Interfaces vary greatly. Once it has been determined that a CPR is required for a specific report/interface or functionality, the CSD Account Manager should create this CPR and provide the CPR to the Client for review within five working days. A quote is generated by development for all CPRs, and one should allow for another five working days for the generation of the quote. The CPR with the quote should then be provided to the Client for signoff. No work takes place on any CPRs before signoff has been obtained from the Client. Delivery of a CPR depends on its complexity, but one should allow for six weeks of including development, testing/QA and deployment. One should allow for whole CPR cycle to complete in the time specified in the Specifications sheet – typically 6 to 8 weeks.

E. Differentiation between CSD and PSGThe key differentiation between CSD and PSG is that the majority of CSD’s work is performed offsite and the majority of PSG’s time is performed onsite. In summary:

Client Services Division’s (CSD) Role:

1. Primary contact for the Client after Client goes live;2. Yardi Office based;3. Predominantly telephone support with extensive use of email for

communication as well with most communication with the SPOC;4. Issue management, which may extend to Issue List management;5. Raises Cases, TR, Hotfixes and CPRs on behalf of the Client and manages

the full lifecycle of each of the above;6. Generates little to no documentation other than when new functionality is

delivered to the Client via Hotfix or CPR;7. Bills time against Client Support Units;

Professional Services Group’s (PSG) Role:

1. Primary contact for the Client during the implementation or special project;2. Project Management including all project related tasks encompassing

project kick off, project management, business requirements review interviews, pilot co-ordination, user acceptance testing (UAT) co-ordination, data conversion, super-user training, end-user training and various documentation tasks;

3. During the implementation will have sole responsibility for raising all relevant CPRs on behalf of the Client and managing the full delivery lifecycle of the CPRs. Will sometimes get involved in Cases and TRs for

Page | 8 of 13


bugs/enhancements that surface from Pilot and UAT. Will normally only be involved with enhancement TRs if specific contract deliverables;

4. Generates extensive leave-behind documentation as part of the implementation/special project that may include business requirements “as is” review, business requirements “to be” review, configuration workbook, UAT test scripts, client policies & procedures documentation and end-user training guides;

5. Bills time against PSG Projects [normally more than 150 hours] or Client Service Agreements (CSAs);

Procedures have been developed within Yardi whereby the account is migrated from PSG to CSD after go live. As part of this procedure, the following steps are followed:

If the Client is hosted by Yardi ASP then the CSD Account Manager is responsible for the installation of the relevant software version (both service pack and plugins) within the ASP environment including running the schema updates;

If the Client is self-hosted then the CSD Account Manager is responsible for assisting with the initial installation of the relevant software version within the Client’s environment, and the training of the Client’s staff on this installation process. This work may be performed onsite or remotely via GoToMeeting sessions. It is the Client’s responsibility to run any schema updates that may be necessary;

During the implementation/special project the CSD Account Manager is responsible for any service pack and/or plugin upgrades for all ASP Clients (for all self-host Clients, this task is the Client’s responsibility);

The PSG consultant is responsible for introducing the CSD Account Manager to the Client during the implementation, normally during the month before go live;

The PSG consultant is responsible for managing all Cases, TRs and CPRs that are raised during the implementation/special project including ones that may be open immediately after go live. Ideally, the PSG Consultant will manage these Cases, TRs and CPRs through to closure;

Any new Cases, TRs, Hotfixes and CPRs that arise after go live are the responsibility of the CSD Account Manager;

The PSG consultant is responsible for working with the Client (either onsite or offsite) to help the Client through their first two month end closes;

After two successful month end closes, total responsibility for the Client, including any open Cases, TRs and CPRs that may have been raised by the PSG Consultant, shift to the CSD Account Manager;

F. Use of CSD Support UnitsEvery year a Client is provided with an Allocation of Support Units. Unused Support Units expire at the end of each year. Unused Support Units cannot be carried forward to the next year. These Support Units can be used as follows:

What can a Client’s Support Units be used for?:

Page | 9 of 13


1. Day-to-day Case administration including time spend communicating with the Client (phone calls and typing up emails);

2. Management of TRs and Hotfixes on behalf of the Client;3. Testing/QA of TRs and Hotfixes produced by Yardi development for the

Client;4. Creation of CPRs including testing of reports/interface/functionality once

delivered by development;5. Production of Policies & Procedure guides on new Yardi functionality

delivered via a Hotfix or a CPR;6. Issue List maintenance and communications to the Client;7. Monthly Issue List meetings including preparation; 8. Generation of simple scripted reports that do not take more than 4 hours

to generate;9. Creation, testing and deployment of data fix scripts;

What can a Client’s Support Units not be used for?:

1. Yardi Account Managers or case management team cannot charge support units to clients to fix Yardi system bugs;

2. Time worked by PSG staff members;3. Onsite training;4. Onsite implementation support;5. Generation of Policies & Procedure guides for a Client other than those

created for the delivery of Hotfixes and CPRs;6. Generation of end-user training guides for Clients;7. Report writing when a report takes more than 4 hours to generate or needs

to be created in Crystal or Analytics;8. Unused Support Units cannot be converted into cash or an account credit

at the end of the year;9. Typical Client end-user tasks, such as entry or maintenance of

Properties/Leases/Vendors or deletion of Un-posted Batches;

Note: Items 2 through 9 or items not on the list will be scoped as required and charged separately.

G.CSD Support FrameworkHours of operation

Support office is open from 9am to 5pm Sydney time for your Sydney Office. For critical issues outside of these hours, the FLY BY NIGHT PTY LTD SPOC should contact the people mentioned in Section A above.

Method to log a case

Cases are logged either by the Client through Client Central Portal or by the Account Manager directly into yCRM. YCRM allows the Account Manager to keep track of all Client cases and follow up as required.

Client Central Portal is accessed through the Yardi Client Central portal where Clients can also find a Client Central Portal quick-start guide. Client Central Portal allows the Client to

Page | 10 of 13


monitor their Case progress and search for solutions through the Yardi knowledge base. Client TRs with their respective status can also be tracked through Client Central Portal. Yardi requests that all Clients provide as much detail as possible when logging a Case as this helps Yardi provide a timely resolution. FLY BY NIGHT PTY LTD must email their Account Manager for any Cases logged directly through Client Central Portal.

How to Raise a Case

When FLY BY NIGHT PTY LTD users have Voyager related issues they will raise the issue by logging a ticket with FLY BY NIGHT PTY LTD’s service desk. The FLY BY NIGHT PTY LTD team will attempt to triage and resolve the issues. If FLY BY NIGHT PTY LTD is unable to resolve the issues, then they will escalate the issues to the FLY BY NIGHT PTY LTD Yardi CSD Account Manager by either logging the case through My Yardi and informing the account manager of the case created or emailing details about the issue directly to FLY BY NIGHT PTY LTD Yardi CSD Account Manager. The Yardi CSD Account Manager will issue to the FLY BY NIGHT PTY LTD SPOC with a reference Case number, for tracking purposes, for all issues logged.

The current FLY BY NIGHT PTY LTD Yardi SPOC is:

Primary

FLY BY NIGHT PTY LTD: John SmithEmail: [email protected]: (02) 9450 1234

ASP Support Access for International Clients

Yardi ASP support is 24x7x365, and is primarily performed by ASP teams of Yardi employees in two primary locations, namely, Santa Barbara and Pune. This phone number must be used when an ASP issue is experienced.

FLY BY NIGHT PTY LTD SPOC or member of the support team can contact Yardi ASP services directly on +1 (800) 866 1124 Ext 3 or +1 (805) 699 2040 Ext 3 which is main ASP Yardi switchboard phone number in Santa Barbara. Alternatively ASP can be reached at +61 (2) 8227 2200 ext. 3

The above number is not for questions about the program (i.e. Voyager Application) which should go to Client Services during normal business hours.

Page | 11 of 13


H.Monthly DeliverablesMonthly Case Log Review

FLY BY NIGHT PTY LTD keeps a log of all cases logged (issue list) with Yardi. A monthly meeting between the LOCAL office CSD Account Manager and FLY BY NIGHT PTY LTD LOCAL office SPOC is held to review all open cases. CSD will review and update the issue list with relevant CASE#, TR# and hotfix# for the respective cases. The updated issue list will be sent to FLY BY NIGHT PTY LTD Local Office SPOC a day before the meeting. Cases that Yardi has provided solutions for or acceptable workarounds for but have seen no activity from the client for longer than 30 days will be closed by Yardi.

Monthly Support Hour StatementUpon request, a support activity report can be sent to FLY BY NIGHT PTY LTD on the 25th of each month for the previous month’s support activities. The report lists all Cases and activities logged against FLY BY NIGHT PTY LTD for the month. It also documents the number of support hours is used for the month and support hour balance.

Monthly Account reviewA monthly account review is held with FLY BY NIGHT PTY LTD; includes Account Manager from the Yardi side and client SPOC from FLY BY NIGHT PTY LTD to review/discuss any open items and overall feedback of support process.

Page | 12 of 13


I. Overview of Yardi CSD Global PresenceYardi has full support services centers in the following cities around the world:

Asia Pacific Sydney, Australia Hong Kong, China Pune, India

Europe London, UK Amsterdam, Holland Cluj, Romania

North America Santa Barbara, California Durham, North Carolina Dallas, Texas Toronto, Canada New York City, New York

FLY BY NIGHT PTY LTD’s current support contract only provides for local office support out of the Yardi office in Sydney for FLY BY NIGHT PTY LTD Sydney operations.

Yardi Global Office Locations

Page | 13 of 13