General terms and conditions of BTC service agreements

Maintenance services

  1. The purpose of Software Maintenance Services is to ensure Software updates (technical assistance) and uninterrupted operation of the Software (SLA services), as well as to ensure the provision of other services to support the use of the Software.
  2. The standard duration of the SLA service is 12 months from the date of purchase.
  3. Software Maintenance Services include:
    1. technical assistance,
    2. Provision of SLA services, under which it is implemented:
      1. handling requests for:
        1. responding to bug reports within a specified response time;
        2. making an analysis of the causes of errors;
        3. providing workarounds for errors that occur due to third-party software causes;
        4. providing workarounds for errors occurring due to the contracting authority’s infrastructure;
        5. debugging during repair;
        6. fixing errors occurring due to third-party software – once the appropriate update is made available by the manufacturer of this software and obtained – at the time of repair;
      2. ensure the availability of the Software.

Technical assistance

Technical Assistance includes:

  1. Continuous improvement and innovation of software:
    1. Providing new versions of the software (within the edition version) and tools and procedures for upgrades,
    2. providing software patches,
    3. correction packages to adapt the existing range of software functions to revised legal and regulatory requirements,
    4. technology upgrades to support new versions of operating systems and databases,
    5. software change management, including reconfiguration, reinstallation (e.g., moving the system to another hardware platform),
    6. software updates are performed fully automatically using an update platform (update server),
    7. content, tools and process descriptions of the Software documented in the relevant documentation.
  2. Other support services:
    1. Access to documentation and description of software changes on the Contractor’s website. The content includes the following:
      1. one-stop solution support: help optimize end-to-end software support,
      2. assistance in software management, business process support and administration,
    2. participation in a community of business partners and customers, providing information on best business practices, offers, services, etc.

SLA services

  1. The channel for the provision of the service is email, through which an error report can be made at any time.
  2. In the event that the Contractor launches an infrastructure dedicated to handling requests, the channel for providing the service will be this infrastructure. All those involved in the bug resolution process will be able to access the status of the bug at any time.
  3. In exceptional situations, the Ordering Party has the right to contact the Contractor’s specialists by telephone.
  4. SLAs for service levels in relation to response times:

Error Category / Priority Response time* Time to repair or bypass the error*
critical error/ very high – preventing the use of the software or blocking the execution of the customer’s key business processes (immobilization or suspension of the system, significant disruption of work for at least 10% of the users of the Software) and requiring the fastest possible repair or workaround 4 working hours 12 hours
standard / high error – affecting the functionality and convenience of the software, but not blocking the basic tasks of users (reduced work efficiency, lack of availability of some data) 16 working hours 7 working hours
incident / residual – malfunction of the system, but in a form that completely does not affect the work of users 1 working hours 14 working hours
consultation – the software provider’s time devoted to communication with the User, support, advice, instructions 5 working hours –
development – any work not related to fixing bugs, but, for example, modifying the software 20 working hours –

* Business hours: weekdays 8:00 am – 4:00 pm. Implementation of service work: working days 8.00-16.00. * Response time and repair time are calculated on business days during service hours, with the proviso that requests after hrs. 4 p.m. pass to the next working day

Error Category / Priority Response time* on working days 8.00 am – 11.00 pm Repair time* on working days 8.00-23.00
critical / very high error – preventing the use of the software or blocking the implementation of key business processes of the customer (immobilization or suspension of the system, significant disruption of work for at least 10% of users of the Software) and requiring the fastest possible repair or workaround 4 working hours 8 hours
standard / high error – affecting the functionality and convenience of the software, but not blocking the basic tasks of users (reduced work efficiency, lack of availability of some data) 16 working hours 7 working hours
incident / residual – malfunction of the system, but in a form that completely does not affect the work of users 1 working hours 14 working hours
consultation – the software provider’s time devoted to communication with the User, support, advice, instructions 5 working hours –
development – any work not related to fixing bugs, but, for example, modifying the software 20 working hours –

* Business hours: weekdays 8:00 am – 4:00 pm. implementation of service work: working days 8.00-23.00. * Response time and repair time are calculated in service hours, with the proviso that the turnaround time for a request made after hrs. 11 p.m. on business days begins at 8 a.m. on the next business day.

Error Category / Priority Response time* 8.00-23.00 Repair time* on working days 8.00-23.00 Repair time* on non-working days 8 a.m. to 11 p.m.
critical error/ very high – preventing the use of the software or blocking the execution of the customer’s key business processes (immobilization or suspension of the system, significant disruption of work for at least 10% of the users of the Software) and requiring the fastest possible repair or workaround 4 working hours 8 hours 8 hours
standard / high error – affecting the functionality and convenience of the software, but not blocking the basic tasks of users (reduced work efficiency, lack of availability of some data) 16 working hours 7 working hours 7 working hours
incident / residual – malfunction of the system, but in a form that completely does not affect the work of users 1 working hours 14 working hours 14 working hours
consultation – the software provider’s time devoted to communication with the User, support, advice, instructions 5 working hours – –
development – any work not related to fixing bugs, but, for example, modifying the software 20 working hours – –

* Business hours: weekdays 8:00 am – 4:00 pm. Implementation of service work: weekdays and holidays 8:00-23:00. * Response time and repair time are calculated in service hours, with the proviso that the turnaround time for a request made after hrs. 11 p.m. begins at 8 a.m. the following day.

Definitions:

Response time – the time elapsed from the time the error was reported until corrective action was taken.

Repair time – the time elapsed from the time the error was reported until the repair was made.

Working days – statutory working days.

Hours of operation – business hours – 8:00 am – 4:00 pm.

Repair – restoration of full functionality of the software.

Error resolution – the effect of the ongoing maintenance work, which removes the cause of the error and restores the full functionality of the software as specified in the documentation.

Error workaround – temporary restoration of software functionality, not completely eliminating the cause of the error but allowing the software to function.

Bug report

  1. Compliance with the terms and conditions of this procedure is required for applications to be effective.
  2. The following channels for making notifications are made available:
    1. email address:support(at)btc.com.pl,
    2. telephone numbers open on business days (optional),
    3. call phone numbers open during the reception hours (optional).
  3. When making an application, it is mandatory to provide:
    1. contact information for the party’s designated contact person for the application,
    2. as accurate a description of the problem as possible, along with the steps already taken to solve the problem, if any,
    3. the name of the affected application,
    4. determine the category of notification and/or business impact,
    5. the date and time of the problem.
  4. In order to improve service and reduce response time, it is suggested that:
    1. notifications of the critical error category were additionally made by telephone (taking into account the reception time).
  5. A notification sent to the monitored inbox “support(at)btc.com.co.pl” is acknowledged back with the acceptance of this notification. Lack of return confirmation means that the application did not reach the Contractor.

Application processing

  1. Verification of the request: the request is verified for type and is assigned to the appropriate consultant.
  2. If verification or processing of the request will require remote or direct access to the Software, the requestor shall provide such capability.
  3. If configuration files, logs or other additional information will be needed to properly handle the request, the requestor should provide access to them.
  4. The consultant dedicated to handling the request shall proceed to complete the work as soon as possible, in accordance with the priority of requests and within the service hours.

Status of requests – requests can take the following statuses:

Applications can take the following statuses:

  1. “OPEN” – application registered in the system,
  2. “IN PROGRESS” – an application on which work is in progress,
  3. “LOOKING FORWARD” – completed submissions, not verified by the Submitter,
  4. “CLOSED/RESOLVED” – application completed, verified by the Submitter and confirmed,
  5. “OPEN RECEIVED” – a closed application in which the same bug (undisclosed during testing) was detected at a later date.

Receipt of applications

  1. The applicant is informed of the work performed and the status of the application by the consultant via e-mail.
  2. The consultant marks the request as “closed / resolved”.
  3. If the Submitter subsequently discovers previously undisclosed defects regarding this submission, he shall immediately report this fact and the submission shall be reopened and verified.
  4. If there is no response to the information on the executed acceptance request for 7 days, the request acquires the status of resolved.