printIQ have established SLAs to help support customers by defining the scope, quality, and responsiveness of technical support services. These SLAs outline the specific expectations and guidelines regarding issue resolution times, response times, availability of support channels, and overall service performance. By printIQ setting clear benchmarks, SLAs ensure that printIQ customers receive consistent and reliable technical assistance in accordance with their needs and priorities. These agreements help manage expectations, enhance accountability, and establish a framework for effective communication between printIQ and its customers. Technical Support SLAs provide customers with the assurance that their technical issues will be responded to promptly and professionally, fostering a productive and satisfactory relationship between both parties.
Priority | Definition |
Estimated time to resolve |
P1 - Critical | A defect that causes the complete system to stop functioning or that will result in unrecoverable data-loss. The bug has no workaround. Example: Site is returning error 500 on all pages. |
1 Day |
P2 - High | The defect causes a critical part of the system to be inaccessible or to stop functioning. The bug has no workaround or it has a workaround that will not be easily found by users. Example: All products are suddenly failing to price. |
3 – 4 Days |
P3 - Medium | The defect causes a non-critical failure on the system but it will allow users to continue working. The bug has a workaround that is relatively easy to find and will be acceptable by most users. Example: Updated product details don't show until the page is refreshed. |
4 – 6 Weeks |
P4 - Low |
The defect causes minimal in core system functionality. The bug has an easy workaround or may not require a workaround. Example: A display issue. |
Quarterly |
Our patch release cycle is every 4 weeks for p3/p4 impairments. The primary objective of a four-week patch release cycle is to maintain and enhance the stability, security, and functionality of software systems through regular and predictable updates. This approach aims to strike a balance between addressing critical issues and introducing new features while minimising disruption to users. By adhering to a consistent four-week timeframe, software development teams can efficiently identify, address, and deploy necessary bug fixes, security patches, and improvements. This regular cadence not only ensures that vulnerabilities are promptly addressed, reducing the risk of security breaches, but also allows users to benefit from incremental feature updates in a manageable and controlled manner. The four-week patch release cycle fosters a predictable rhythm for both development teams, customers and end-users, promoting a sustainable and iterative approach to software maintenance and enhancement.
p1/p2 impairment fixes are applied out of our cycle and are patch released as soon as the fix has passed testing.
Priority | Classification | Estimated Initial First Response Time | Estimated Resolution Time |
Impaired | Low | 1 Day | 60 Days |
Impaired | High | 1 Day | 5 Days |
Impaired | Site down | 5 Hours | 2 Days |
Set Up/Training | 1 Day | 14 Days |