Problem Severity Sample Clauses

Problem Severity. Upon receipt of a properly submitted Problem, Bonitasoft shall prioritize it in accordance with the guidelines below. Problem Severity shall be defined jointly with Customer and supported by business cases where necessary. Problem Severity may be re-evaluated upon submission of a workaround. Blocking Problem — Blocking Problems are major production problems with in the Bonitasoft Software that severely impact the Customer’s production environment, or that result in a loss of production data or interruption of service, or that cause significant impact to portions of the Customer’s business operations and productivity, and no work-around exists. Bonitasoft will use continuous efforts during its normal hours of operation to provide are solution for any Blocking Problem as soon as is commercially reasonable. The Bonitasoft Problem Monitoring tool shall show such issues with a “Block” status. Non-Blocking Problem — A Non-Blocking Problem is any other problem with in the Bonitasoft Software where the Customer’s system is functioning. This includes situations where the Customer’s system is operating but in a reduced capacity, or for which Bonitasoft has provided a reasonably effective work-around. Problems existing in a non-production environment that would otherwise qualify as a Blocking Problem if they were in a production system qualify as Non-Blocking. Bonitasoft will use reasonable efforts during its normal hours of operation to provide are solution for any Non-Blocking problem as soon as is commercially reasonable. The Bonitasoft Problem Monitoring tool shall show such issues with a “Non-Blocking” status. Enhancement Request (ER) — An ER is a recommendation for future product enhancement or modification to add official support and documentation for unsupported or undocumented feature, or features that do not currently exist in the Bonitasoft Software. Bonitasoft will take ERs into consideration in the product management process, but has no obligation to deliver enhancements based on any ER. The Bonitasoft Problem Monitoring tool shall show such issues with a “Feature” status.
Sample 1Sample 2
AutoNDA by SimpleDocs
Problem Severity. All problems are classified by the severity it causes. For the purpose of this agreement there will be three severity levels defined as: Severity 1 - Application cannot run or continued use will cause corruption of data. Severity 2 - Problem is persistent but a workaround is available. Must be addressed, but can afford to follow established procedures to migrate the fix to the production environment. Categorized in Optics as Urgent priority. Severity 3 - Problem is intermittent, may cause minimal impact on operation of application. Work around is available. Can wait for future release to correct the problem. Characterized in Optics as High or lower priority.
Sample 1
Problem Severity. As long as Customer is current in making the payments required by the submission of payment and this Agreement, ZYRL will respond to problems reported by a Customer Representative according to the problem severity levels defined below. ZYRL reserves the right to assign or modify the Severity of a given problem if one is not provided by the Customer or if the submitted severity level does not meet, in ZYRL’s sole discretion, the definition as defined below. Severity Definition Example Critical/Down Loss of service to ZYRL Product ● Inability for Customer to access ZYRL Dashboard ● Inability for customers to use ZYRL product. ● ZYRL apps not loading at all Major Outage or problem affecting specific application or parts of Dashboard ● Inability to customize tagging on ZYRL dashboard ● Inability to customize campaign on ZYRL Dashboard ● Inability to view tagging and campaign statistics on ZYRL dashboard ● ZYRL apps not loading Average Problem results in incorrect, incomplete, or inconsistent results ● Inability to enable/disable secondary features of products or applications in the ZYRL Dashboard ● Inability to enable/disable secondary features of products or applications in the ZYRL Dashboard that do not affect app performance Minor Minor problem or request that is not time sensitive ● Intermittent issues that cannot be replicated consistently ● Minor issues to ZYRL Dashboard or application that do not affect performance ● Product change request ● Product version updates
Sample 1
Problem Severity. 1. The problem severity is defined by its impact on the operational A-VDGS system. There are two types of problems: (I)
Sample 1
Problem Severity. Nortel and Seller will mutually categorize Problems and Seller will provide Technical Support Services according to the definitions in Section 3.1 above and the priority levels set forth in the matrix below and the service level responsibilities set out in Section 3.4.
Sample 1
Problem Severity. The severity of a Problem will be determined by Nortel and Seller based on the criteria in the matrix below.
Sample 1
Problem Severity. For purposes hereof, the levels of severity for providing Support Services are defined as follows: Sev1: Emergency – an issue that prevents Visitors from receiving Content Recommendations. Sev2: Limitation – an issue or problem rendering Content Recommendations inaccurate or partially unavailable AND with significant impact on Customer’s ability to provide services to its Visitors, or ExactTarget’s ability to provide services to Customer. Sev3: Minor Defect – an issue or problem in which Content Recommendations are generally available and functionality is not significantly affected, but in which a correction or modification is required to enable the normal function and operation of the Content Recommendations.
Sample 1
AutoNDA by SimpleDocs
Problem Severity. ANDA defines three problem severity classifications for Reported Problems aligning with TL9000 R3.0 standards. In order to classify a request, ANDA technical support personnel will confirm with Customer the impact of the reported problem to determine an appropriate classification. Where parties disagree on the classification of a particular Reported Problem, Customer and ANDA technical contacts will undertake to discuss the problem with a view to reaching a mutually acceptable classification, where possible.
Sample 1

Related to Problem Severity

  • Downtime Due to the nature of server provision, downtime and lost transmissions may occur as part of routine maintenance. You are advised to maintain a copy of your account status and details of Content purchased.

  • Problems To try to resolve fairly any problems, grievances and difficulties you may have while you volunteer with us. • In the event of an unresolved problem, to offer an opportunity to discuss the issues in accordance with the procedures set out in the Volunteer Involvement Policy.

  • Problem Solving Employees and supervisors are encouraged to attempt to resolve on an informal basis, at the earliest opportunity, a problem that could lead to a grievance. If the matter is not resolved by informal discussion, or a problem-solving meeting does not occur, it may be settled in accordance with the grievance procedure. Unless mutually agreed between the Employer and the Union problem-solving discussions shall not extend the deadlines for filing a grievance. The Union Xxxxxxx or in their absence, the Local Union President, or Area Xxxxxxx, or Chief Xxxxxxx, either with the employee or alone, shall present to the appropriate supervisor a written request for a meeting. If the supervisor agrees to a problem- solving meeting, this meeting shall be held within fourteen (14) calendar days of receipt of the request. The supervisor, employee, Union Xxxxxxx, and up to one (1) other management person shall attempt to resolve the problem through direct and forthright communication. If another member of management is present that person will not be hearing the grievance at Step Two, should it progress to that Step. The employee, the Union Xxxxxxx or in their absence, the Local Union President, or Area Xxxxxxx, or Chief Xxxxxxx, may participate in problem-solving activities on paid time, in accordance with Article 31, Union Rights, Section 1H.

  • Planned Outages Seller shall schedule Planned Outages for the Project in accordance with Good Industry Practices and with the prior written consent of Buyer, which consent may not be unreasonably withheld or conditioned. The Parties acknowledge that in all circumstances, Good Industry Practices shall dictate when Planned Outages should occur. Seller shall notify Buyer of its proposed Planned Outage schedule for the Project for the following calendar year by submitting a written Planned Outage schedule no later than October 1st of each year during the Delivery Term. The Planned Outage schedule is subject to Buyer’s approval, which approval may not be unreasonably withheld or conditioned. Buyer shall promptly respond with its approval or with reasonable modifications to the Planned Outage schedule and Seller shall use its best efforts in accordance with Good Industry Practices to accommodate Xxxxx’s requested modifications. Notwithstanding the submission of the Planned Outage schedule described above, Seller shall also submit a completed Outage Notification Form to Buyer no later than fourteen (14) days prior to each Planned Outage and all appropriate outage information or requests to the CAISO in accordance with the CAISO Tariff. Seller shall contact Buyer with any requested changes to the Planned Outage schedule if Seller believes the Project must be shut down to conduct maintenance that cannot be delayed until the next scheduled Planned Outage consistent with Good Industry Practices. Seller shall not change its Planned Outage schedule without Buyer’s approval, not to be unreasonably withheld or conditioned. Seller shall use its best efforts in accordance with Good Industry Practices not to schedule Planned Outages during the months of July, August, September and October. At Buyer’s request, Seller shall use commercially reasonable efforts to reschedule Planned Outage so that it may deliver Product during CAISO declared or threatened emergency periods. Seller shall not substitute Energy from any other source for the output of the Project during a Planned Outage.

  • CLEC OUTAGE For a problem limited to one CLEC (or a building with multiple CLECs), BellSouth has several options available for restoring service quickly. For those CLECs that have agreements with other CLECs, BellSouth can immediately start directing traffic to a provisional CLEC for completion. This alternative is dependent upon BellSouth having concurrence from the affected CLECs. Whether or not the affected CLECs have requested a traffic transfer to another CLEC will not impact BellSouth's resolve to re-establish traffic to the original destination as quickly as possible.

  • Switching System Hierarchy and Trunking Requirements For purposes of routing iNetworks traffic to Verizon, the subtending arrangements between Verizon Tandems and Verizon End Offices shall be the same as the Tandem/End Office subtending arrangements Verizon maintains for the routing of its own or other carriers’ traffic (i.e., traffic will be routed to the appropriate Verizon Tandem subtended by the terminating End Office serving the Verizon Customer). For purposes of routing Verizon traffic to iNetworks, the subtending arrangements between iNetworks Tandems and iNetworks End Offices shall be the same as the Tandem/End Office subtending arrangements that iNetworks maintains for the routing of its own or other carriers’ traffic.

  • Management Grievance The Employer may initiate a grievance at Step 3 of the grievance procedure by the Employer or designate presenting the grievance to the President of the Union or designate. Time limits and process are identical to a union grievance.

  • Service Level Expectations Without limiting any other requirements of the Agreement, the Service Provider shall meet or exceed the following standards, policies, and guidelines:

  • Service Level In the event that League InfoSight discovers or is notified by you of the existence of Non-Scheduled Downtime, we will use commercially reasonable efforts to determine the source of the problem and attempt to resolve it as quickly as possible.

  • SAVINGS/FORCE MAJEURE A Force Majeure occurrence is an event or effect that cannot be reasonably anticipated or controlled and is not due to the negligence or willful misconduct of the affected party. Force Majeure includes, but is not limited to, acts of God, acts of war, acts of public enemies, terrorism, strikes, fires, explosions, actions of the elements, floods, or other similar causes beyond the control of the Contractor or the Commissioner in the performance of the Contract where non- performance, by exercise of reasonable diligence, cannot be prevented. The affected party shall provide the other party with written notice of any Force Majeure occurrence as soon as the delay is known and provide the other party with a written contingency plan to address the Force Majeure occurrence, including, but not limited to, specificity on quantities of materials, tooling, people, and other resources that will need to be redirected to another facility and the process of redirecting them. Furthermore, the affected party shall use its commercially reasonable efforts to resume proper performance within an appropriate period of time. Notwithstanding the foregoing, if the Force Majeure condition continues beyond thirty (30) days, the Parties shall jointly decide on an appropriate course of action that will permit fulfillment of the Parties’ objectives hereunder. The Contractor agrees that in the event of a delay or failure of performance by the Contractor, under the Contract due to a Force Majeure occurrence:

Time is Money Join Law Insider Premium to draft better contracts faster.