Views:

This document described the policies and procedures governing how customers may request Service(s) and how we (Company) delivers those Service(s). Under our Agreement, Clients are bound to adhere to and be limited by this framework.

Authorization to Work

Company shall not perform any Service(s) unless authorized by Client (and/or End-customer, where applicable). To provide such authorization (hereinafter “Authorization(s) to Work”), Client and/or End-customer shall submit Request(s) to Company, thus initiating delivery of Tasks(s) for any specific need.
Client’s Entitlement(s) to initiate Task(s) of different Service Type(s) or other classifications shall be specified within the attached SOW(s) and/or determined by the SLA(s) for enrolled Service Plan(s).
 
Client Requests

Definition of Requests

As described elsewhere herein, Client Request(s) (herein “Request(s)” or “Req(s).”) are any communicated request from Client that may result in change(s) to Service(s), Authorization(s) to Work, or no action whatsoever. Request(s) begin the process under which Company performs Task(s) for Client. Among other activities, these may include customer, billing, and technical support.

Where used herein, the terms cited above in the preceding paragraph, are not intended to be synonymous with the word “request” when not written in proper case.

This section and its sub-sections shall describe the process which governs Client Request(s).

Service Type(s) / Classification of Request(s) and/or Task(s)

Service Type(s) classification determines the business process used to provide Service(s), rules governing handling and delivery, and means of compensation for all Request(s).

Determination of Service Type(s) for any individual Request(s), including coverage by Client’s Entitlements (or lack thereof) and/or eventual classification or re-classification as another Service Type(s) shall be at the discretion of Company and is further governed by the terms of the attached SLA.

For purposes of classifying performance of Service(s) based on labor (“Labor Service(s)”), such as Professional Service(s) as well as activities performed in support of Service Plan(s) and/or Subscription(s), Parties agree to usage of the following list of classifications (collectively “Service Type(s)”):

  • Request(s) – Client’s generic requests which may evolve into and/or eventually result in Purchase Order(s) or other types of Task(s) listed herein.
  • Support Incident(s) – Handling short-term support needs, for example: a help desk ticket, answering a technical question, or onboard/offboard an employee. Support Incident(s) are Request(s) which result in the completion of a discrete action, such as the resolution of a specific problem or the alteration of a set of related settings.
  • Task Order(s) – Request(s) to complete technical Service(s) occurring over an extended period ranging from several hours to a few weeks. For example: complete a configuration change, migrate a group of users. Task Order(s) are characterized as set(s) of one or more extended assignments, structured in ad-hoc fashion, short-term project, or phase in a larger project.
  • Enhanced Support Incident(s) – Support Incident(s) where the level of effort exceeds the quantity or nature of Client’s Entitlement(s), such as where the Service(s) must be provided outside of normal business hours. Parties agree that Enhanced Support Incidents(s) are functionally equivalent to Priority Service(s) and/or Task Order(s) and thus hourly billing will apply in most cases where they are invoked.

Other Naming Conventions
Other applicable naming conventions herein which neither refer to Service(s) nor Service Type(s) include: 

  • Billing Contract(s) – Not an actual contract per-se, Billing Contracts are a logical construct used to organize recurring billing for Subscription(s) and Service Plan(s) under a single entity attached to Client and their associated Agreement(s) and/or SOW(s). Only Clients purchasing Subscription(s) or Service Plan(s) are assigned a billing contract, which triggers the generation of a recurring invoices and statements.
  • Entitlement(s) – Set(s) of specific privileges granted to Client through the purchase of Subscription(s) and/or Service Plans(s).
  • Case(s) – represents the documentation which follows Request(s) as they proceed from initial communication through their lifetime as Support Task(s) and/or evolution into Task Order(s), Purchase Order(s) or other disposition.

Receipt and Validity of Requests

Request(s) shall be considered delivered to Company when they are sent and received via a valid communication channel.

To be considered valid, Request(s) must be:

  • Issued by an Authorized Representative of Client (and/or End-customer where applicable);
  • Sent via communication channel(s) permitted under Client’s Entitlement(s);
  • Within periodic limits permitted under Client’s Entitlement(s); and
  • Successfully transmitted to and received by Company staff.[TC3] 

Request(s) failing to meet all the above conditions, including for reasons of exceeding Entitlement(s) or receipt by other than permitted communication channels, shall be deemed invalid at Company’s sole discretion.[TC4] 
Client may promote such invalid Request(s) by switching communication to a permitted channel or through the order and/or purchase of Service(s) to extend Entitlement(s). Request(s) may also be granted a validity exception at Company’s sole discretion.

Subject to Client’s Entitlement(s), Company accepts the following communication channels for purposes of submitting Request(s):

  • Telephone call to the Company’s designated customer / technical support number(s).
  • Completion of new Case(s) (or similar request initiation) form as provided on Company’s web site or Ordering System(s).
  • Text communications using chat tools such as Microsoft Teams or Intercom; in such case Request(s) are considered received when a Company representative replies to the individual Req.
  • E-mail to CloudSupport@liquidmercurysolutions.com

Client’s Entitlement(s) to submit Request(s) via above channels shall be as defined by the SOW(s) and further governed by the purchase of Subscription(s) and/or Service Plan(s) as described on Company’s Web Site and SLA.

Invalid Request(s), Duly Authorized, Will Be Handled as Priority Service(s)

Request(s) determined to be outside the scope of Client’s Entitlement(s) shall not be considered valid Request(s). Where the attached SOW(s) and/or SLA(s) do not make Client’s Entitlement(s) clear, Client shall be interpreted as not having Entitlement(s) to issue such Request(s).

In both such cases, Company shall inform Client of the Request(s)’ status; any subsequent Authorization(s) to Work related to such Request(s) shall deem the Request(s) valid and shall be considered synonymous with a request and approval for Priority Service(s) of the appropriate nature. 

Single System of Record for Requests

Company shall provide and maintain its own systems for tracking and reporting of Request(s).
If Client wishes to utilize their own internal tracking system(s), it is the Client’s sole responsibility to ensure that such items tracked are communicated to Company as needed through one of the above methods described herein. Client is free to purchase and/or develop integration solutions using Company’s provided APIs; Company will make a good faith effort to support this. Under no circumstances shall Company take responsibility to work within Client’s internal tracking systems or provide such integration(s) free of charge.

Evolution of Requests to Tasks

All Task(s) as described herein shall originate with a Request(s) without regard to the eventual classification of Service Type(s) and the existence of Task(s) shall assume the pre-existence of corresponding Request(s).
Request(s) need not result in the issuance of a Task(s), as there are other valid results including the issuance and processing of a resultant Purchase Order, other actions, or no action at all.

Service Plans

As described elsewhere, Service Plan(s) are Service(s) for which Client pays a recurring fee in exchange for certain Entitlement(s) during the plan's Commitment Term(s). While Service Plan pricing is often fixed, it may vary based on factors such as changes in the business size, number of covered users or computers, or other factors.

Service Plan(s) generally govern which types of Support Incident(s) or Task Order(s) a Client is permitted to request.

Service Plan Entitlements

As described elsewhere herein as well as within attached SLA, Entitlement(s) consist of one or more privileges bestowed by Company upon Client in consideration for the purchase of Service Plan(s) and/or Subscription(s).
Entitlement(s) shall be defined in the attached SOW(s) and/or SLA(s).

Examples of Entitlement(s) include agreement to:

  • Provide Service(s) for a fixed number of Support Incident(s) over a given time period.
  • Provider a fixed number of hours to provide Service(s) for a given allotment of Support Incident(s) or Task Order(s) over a specified time.
  • Provide a defined set of Service(s) on a complimentary basis.
  • Permit a certain number of escalations from Support Incident(s) to Priority Service(s) without penalties or at reduced costs.
  • Allow some level of access to individuals acting in high level capacity, such as consultants.
  • Provide access to content, information, or tools.

Specific Entitlement(s) applying to Client are determined by purchased Subscription(s) and/or Service Plan(s), further defined and governed by the terms of the attached SOW(s) and/or SLA(s), and further described by information regarding description of Service(s) published on Company’s web site.
 
Support Incidents

Definition of Support Incident

The definition of Support Incident(s) is defined herein (see “Request and Tasks Classifications” section) and governed by Company’s SLA, cited herein and attached to this Agreement. 

Support Incident Scope

Upon the initiation of Support Incident(s), authorized representatives of each Party shall define the Scope of Service(s) for the Support Incident(s). In the absence of such definition, Company shall define the Scope of Service(s) at its sole discretion based on a good faith effort to interpret communications from Client.

Support Incident(s) are intended to fulfill short-term technical requirements. They are not intended as a substitute for mid-to-long-term or project-based work. Such work requires Task Order(s).
The following is a non-exclusive list of examples that would be handled as Support Incident(s):

  • Change the quantity or type of licenses on a subscription plan.
  • Configure a new user login and e-mail mailbox.
  • Change a user’s password and assist in obtaining access to the system.
  • Aid an end-user through Q&A or screen sharing support.
  • Make a configuration change on the customer’s services.

Under certain specific circumstances, Support Incident(s) may proceed into Priority Services(s). See “Support Incident Closure” for details regarding how this process shall proceed.

Support Incident Limitations

At any point where Company’s staff become aware that a given Support Incident(s) is/are unlikely to be completed within the Client’s expected timeframe or level of effort, Company will suspend work on such Support Incident(s), inform the Client within a reasonable time, and await further instructions from the Client before continuing such work.

A single Support Incident shall not under any circumstances exceed either 4 continuous hours or remain open longer than one (1) calendar month, regardless of Client’s preference. Amended or repeating Support Incident(s) shall be permitted solely at Company’s discretion.

Support Incident(s) shall not contain a set of only tangentially related tasks or items (e.g. Bucket List / Gunnysack). All such cases require the creation of multiple Support Incident(s).

Support Incident Closure

Support Incident(s) may be closed when:

  • Resolved or completed,
  • Withdrawn by Client,
  • Client and/or its representatives are unresponsive, OR
  • Company determines that work cannot be completed due to reasons of technical or logistic infeasibility

Performance of work for Support Incident(s) is/are only authorized while such Support Incident(s) remain in an open and active status.

Once closed, Support Incident(s) may be reopened by Request with Company’s acceptance, which may include agreement by the Parties for such Support Incident(s) to be re-classified going forward as Priority Service(s).

Enhanced Support Incident(s) Handled as Priority Service(s)

For the purposes of this Agreement, Priority Services(s) shall be considered synonymous with Task Order(s), and they serve the primary purpose of allowing Support Incident(s) to be handled and compensated equivalently to Task Order(s). Priority Service(s) such as Enhanced Support Incident(s) shall be further defined and governed by Company’s SLA and web site.

As an exception to the above, Enhanced Support Incident(s) shall be tracked and serviced for quality control and reporting purposes alongside ordinary Support Incident(s). All Support Task(s) shall be managed by Company as Case(s).
 
Quality Control Practices

Unless explicitly stated otherwise within the content of attached SOW(s) and/or SLA(s), the following sub-sections shall describe Company’s performance plan with respect to management of Request(s) and/or Support Task(s) as described in this Agreement. Task Order(s) shall not be covered by the terms of these sub-sections.

Desired Outcomes

The desired outcome is expressed by the Client’s staff at the initiation of Req. and varies considerably depending upon the nature of the request and its underlying technical aspects. Company’s goal is to meet the Client staff’s desired outcomes for every Req.; however, both Parties acknowledge this is not always possible.
To improve the rate at which Company meets this goal, Company will record the Client staff’s desired outcomes at the start of each Req.; at the close of the Req., Company staff will ask the Client to report whether their desired outcome was achieved and what suggestions they might make in order to accomplish same. If Company can reasonably make the necessary accommodations to satisfy the Client staff, it will make a best effort to do so.

Performance Standard

General Responsiveness: Company has implemented multiple communication channels to received contact from customers who submit Request(s), including automated calling queues, instructions at Company’s front desk / main telephone number, e-mail distribution systems, and multiple forum / chat applications. All of these are provided as a best effort to promptly respond to incoming requests.
As such, Company will make a best effort to return any e-mails, voicemail, chat, and receptionist messages within 2 to 4 business hours.

Initial Response: Company wishes to promptly answer any inbound requests made by Client, but Client acknowledges that it is not always possible to guarantee an immediate answer for 100% of such requests, especially where cell or Internet based phones are involved.
Company will respond to all Request(s) during normal business hours (as published on Company website). Request(s) initiated outside of business hours will be responded to on the following business day. All Request(s) will receive an initial response within 2 to 4 business hours. (Note that initial responses to Request(s) may include machine automated response messages.) 

Information Gathering: Company staff will reply to Request(s) and work with Client to obtain any necessary information that may be missing from Request(s). The level of urgency and/or severity shall be collected. As part of information gathering, Company staff will research and assess Client’s Entitlement(s). Where there are insufficient Entitlement(s), staff will advise the Client accordingly and wait for instructions before proceeding.

Triage: Once Company staff are satisfied that enough information has been gathered to begin the Request(s), a determination will be made about how to proceed. Note that at this point, it may not be fully possible to determine whether the Request(s) represents Priority Service(s), but attempt will be made to do so as soon as possible. This process shall include whether scheduling or an assessment of the level of effort is required, or alternatively whether support work can begin immediately. Company shall inform the Client as soon as possible once this decision has been reached.

Urgent Requests: An Urgent Request is defined as one where work must be performed outside of regular business hours, there are significant security risks that would be exacerbated by delayed action, or Client’s production equipment is severely impaired in a manner such that normal business operations cannot continue due to circumstances underlying the Request(s).

Company staff will provide their best effort to expedite scheduling and completion of any Urgent Request; however Client acknowledges that such Request(s) are not entitled to prioritization in such a manner as to utilize Company’s staff outside normal business hours or disrupt the normal business operations of Company or its other customers. In such cases, Client shall be given the opportunity to escalate the Urgent Request to an Enhanced Support Incident billable to Client at our standard published rates for urgent/emergency services.

Level of Effort: If a level of effort must be determined by an expert, Company will make a best effort to complete such assessment within 3 business days. Company shall inform the Client as soon as possible once this decision has been reached.

Scope: At this stage, staff shall provide Client with a statement of the Scope of Service(s) for the Request(s).

Scheduling: If work must be scheduled, it will be booked within 1 business day and scheduled to begin no later than 5 business days, as scheduling permits and unless Client has indicated that further timeframes are acceptable or desired.

Updates: Company staff will continue to work on the Request(s) and advise Client of progress regularly. For ongoing work, these updates may be daily or more frequent. However, if work continues at a less rapid pace, Company staff will inform Client about the frequency of updates to expect. (For example, if no work is to be performed for several days staff may advise “I will check in with you next week to let you know the progress.”)

Completion: Request(s) will be closed only when a) Client agrees that they have been completed satisfactorily, b) Client indicates that work on the request is no longer desired, c) the work is deemed to be impossible / infeasible, or d) Client remains unresponsive after persistent repeated contact attempts.

Acceptable Quality Level (AQL)
Company will maintain a 90% overall compliance rate for the above stated standards on Initial Response, Scheduling, and Updates.

Monitoring Method
Company will track the results of all Request(s) using Company’s Ordering System(s) to measure the success rate and duration. Company will track the desired outcomes and whether they were achieved.
In order to aid Client’s understanding of the value of our service, Company may report the above metrics to Client on a periodic basis. These reports will be delivered to the customer at regular intervals that vary depending on system capabilities and the volume of Request(s) over time. On any given month where Client initiates less than 10 Request(s), Company may elect to hold this data over into following month(s) until such time as there are 10 or more Request(s) on which to report, but Company is not required to do so.

Incentives/Disincentives
Company will grant Client a discount and/or credit in exchange for Request(s) that fall outside the above stated performance standards and/or exceed the above stated AQL. Such discounts/credits shall be proportionate to the failure to meet standards, shall not apply to Subscription(s) or other licenses provided by third parties, and shall be at the sole discretion of Company.

Further, Company staff are assumed to be providing a best effort to resolve each Client’s request. Under no circumstances shall the outcome of specific Request(s) be considered justifiable grounds for Client to claim exemption from normal billing practices, and Client is responsible to indemnify Client for all Service(s) performed up to the point where the Client closes given Request(s).

Task Orders

Medium-term and/or structured technical work shall be herein referred to as Task Order(s). A single Task Order may represent as little as a half-day or as much as a few weeks of work.

Where multiple Task Orders put together may constitute the entirely of the authorized amount of a Purchase Order, their entirety is considered a Project and may be completed as such. Where any SOW(s) or other document uses the term “phase” or “Work Order”, it shall be considered the equivalent to Task Order(s) for the purposes of this agreement.

Although SOW(s) may contain language referring to Task Order(s), SOW(s) that do not explicitly define one or more Task Orders shall be considered to have no Task Order(s) defined. In such cases, Task Order(s) may be subsequently attached through the normal processes as described herein.

Definition of Task Order
Task Order(s) shall consist of a communication, duly sent and delivered, which includes all the following items:

  • Brief summary of the desired technical work or list of tasks to be performed
  • Level of urgency
  • Requested Start On and Complete By dates
  • Optionally:
    • Any anticipated deliverables, expected outcomes, or other instructions
    • Not to exceed specified hours
    • If the request regards a problem, a description or of the problem including documentation (e.g. error message or screen captures) or other supporting information
    • Any activities or tasks that should not be performed (e.g. things to be done by Client, already completed, activities out of scope, etc.)

Alternatively, such written communication may indicate:

  • Either, acceptance or confirmation of a prior communication which contained all of the above information, for example a reply to a previous e-mail sent from Company to Client;
  • Or, acceptance or confirmation to continue a previous Task Order with amended expectations, tasks, goals, instructions, etc.

To be considered valid, Task Order(s) must be attached to an existing Service Plan(s)’ Entitlement(s) or Purchase Order(s). Company shall not accept any Task Order(s) which is/are neither assigned to any Purchase Order(s) nor Service Plans(s).

The definition of Task Order(s) is further defined and governed by attached SOW(s) and/or SLA(s), cited herein and attached hereto.

Task Orders for Priority Service(s) escalation of Support Incident(s)

Where Support Incident(s) are not covered by Client’s Entitlement(s), Company offers Priority Service(s) on a pay-as-you-go basis. Such offerings shall be managed and delivered as Task Order(s). Whenever not explicitly covered by Client’s Entitlement(s), hourly billing shall apply in all cases where Priority Service(s) are invoked.
In all such cases, where Authorization to Work has been granted and/or payment collected, this suffices as a Purchase Order as described herein, and a corresponding Task Order shall also be taken as issued.

Task Order Acceptance

Task Order(s) shall be processed in a manner allowing Company to schedule Service(s) and assign resources in a manageable fashion. Thus, each Task Order must be submitted by Client and accepted by Company on an individual basis.

Upon Company acceptance, Task Order(s) are attached and incorporated into the SOW(s) and this Agreement as mutually agreed by both Parties. Such incorporation may be completed through other communications or Company’s Ordering System(s).

Unless explicitly stated in writing and agreed by all Parties, it shall not be assumed under any circumstances that any part this Agreement or attached SOW(s) indicates that Client or End-customer may unilaterally issue Task Order(s) with acceptance presumed.

Project Management

Unless otherwise stated in writing, Company shall be responsible for managing its own staff and resources to complete the provided Service(s).

Reporting of Service Time

For all Services(s) invoiced on a Time and Materials basis, Company shall report on the use of hours against specific Task(s) on a regular basis in order to provide for the effective management of the project timelines and budget associated with Service(s). Unless otherwise agreed in writing, the frequency of such reports shall be once per Milestone but may be provided more frequently at Company’s discretion.

Said plainly, unless we say otherwise, we report time for billing on our Invoices. We may report it more often or by other means if necessary.

Unless otherwise stated, when delivering Task Order(s) or other Priority Service(s) all time spent collecting and processing data for billing purposes (timekeeping) shall be considered billable time.

Setting Priorities

Company shall rely heavily upon input from Client and/or Customer(s) to determine the priorities of tasks to be performed and completed within budgeted time and funding. In the absence of specific instructions from Client, the priority shall be assumed to be that, “Given fixed Desired Functionality, we will adjust the Timeline and/or the Budget and Resources as necessary.”
 
In the past, we assumed Client's did not want to spend more money than already agreed, as long as taking longer to get done or lowering the goal posts were alternatives.
 
Starting in 2022, unless we hear different, Clients should assume we think they want any Request(s) made to be delivered as communicated, even if it will take longer or cost more money than planned.
 
This is a major change from past policy which indicated that budget was the defined goal. Our experience is that under the current framework for delivery of services, this lead to too many problems with customer satisfaction. Client is responsible to inform us If additional spending controls are required.

Meetings

Company staff shall participate in any meetings, discussions, or test sessions as required to complete the SOW(s) and Service(s) within the following parameters:

  • Company shall have the right to make staffing assignments for meeting attendance to their own discretion.
  • All time spent in meetings pertaining to Service(s) shall be considered billable time. Meetings pertaining to administrative matters (e.g., contracts, billing, opportunities for future business) shall not be considered billable.
  • Reasonable accommodations for workload and scheduling.
  • Wherever feasible, meetings shell be scheduled at in advance. Attendance for last minute meetings shall be considered optional. 1 weeks’ notice is required for in person meetings, and 48 hours’ notice is required for remote meetings.
  • Company reserves the right to bill as if attended any meetings cancelled by Client with less than 24 hours’ prior notice.
  • Daily meetings, if required, shall be no longer than ten minutes and weekly meetings shall be no longer than an hour.
  • All meetings shall be assume to be attended remotely. Special arrangements must be made for in-person meetings and are at our discretion.

Restated, for customer meetings:
a) We send whom we choose
b) Meeting time is billable, per individual
c) If we can’t make it, we should agree to reschedule
d) 2 day’s notice for remote and a week for in person
e) We can bill for cancelled meetings
f) Keep daily and weekly check-ins short
g) Assume remote meetings unless otherwise agreed.

Exceptions and Changes

Any requested change to SOW(s) and/or attached Task Order(s) must be completed and executed within 72 hours. Otherwise, Company shall continue as if such request had not been made.

Please request, negotiate, and agree to any material changes in 72 hours, or we agree to drop the matter entirely.