Warranty for implemented software solutions
This document contains the policies operated by abac.software for processing the warranty for the implemented software development platforms.
abac.software is operated by RED ABACUS DEVELOPMENT SRL, a Romanian company registered with the nr. J12/2788/2016 in the Registry of Commerce, having the unique business id RO36345302, with headquarters in Romania on no. 27 Gruia street, 400171 CLuj-Napoca, Romania, hereinafter referred to as “abac” or “we” or any other similar term.
Warranty holer → The individual or organisation that has collaborated with abac for building a software solution and that has been granted a post-implementation warranty period.
Warranty period → The period of warranty awarded by abac for the execution of a work-order (usually found in the offer document) in which the warranty holder can find hidden bugs in the developed software solution, which will be remedied by abac without cost
Warranty claim → A claim is practically a notification that a user sends towards abac, letting them know about the bugs that occurred.
Context of warranty
For the software solutions that abac builds internally for external customers, abac usually issues a warranty period that can be found in the commercial offer. The warranty period practically denotes the time slot in which the Warranty holder can report bugs or defects with the developed software goods, that will be remedied by abac free of charge.
As the context is set to developed software solutions and not physical products, we have to define what constitutes repairable under warranty.
The following constitute the main reasons for opening warranty claims:
- An error that is occurring in the developed software solution that is impeding it’s users towards fulfilling a usage scenario
- A data inconsistency error that is happening when users interact with the platform in a specific way
- A visual defect that creates a negative user experience (text overlapping or not viewable, button not clickable etc.)
- A performance or visual issue that violates the agreed upon non-functional requirements
- A functionality issue that violates the agreed upon functional requirements / acceptance criteria
For software solutions that benefit from an exhaustive acceptance criteria that is not (has not been) subject to change during the development of the software solution and that does not leave room for interpretation, Warranty Claims will be thus assessed against existing specification and acceptance criteria in order to establish the validity of the claims, before the actual work in the claim is performed.
For software solutions that do not benefit from an exhaustive acceptance criteria or that have acceptance criteria that has been subject to change throughout the development of the software solution or that leave room for interpretation, Warranty Claims will be assessed against existing specification and against all of the correspondence that took place between abac and the Warranty Holder, before the actual work in claim is performed (this is not an ideal case, and we are doing our best to prevent it).
The following actions will remove a Warranty Holder’s ability to perform warranty claims:
- Using the software solution in different environments than those that were setup by abac
- Using the software solution in different ways than those that were documented out by abac
- Changing configurations in the binaries of the application
- Changing configurations in 3rd party software that the application interacts with or depends on (changing hosting environment settings, changing settings in 3rd party software solutions that the developed software solution is interacting with)
- Adding changes to the code base on top of what abac has admitted warranty for
abac is not able to operate warranty for software solutions that have been delivered by abac, and that are being continuously edited post-delivery by other software development companies.
If you are unsure about how to proceed with the development of your software platform in order to not void your warranty, please contact us at firstname.lastname@example.org
Claims are the means in which the Warranty Holder can report issues with the software solution to abac.
In order to submit a warranty claim, please send an email to email@example.com, stating the issue at hand.
As a rule of thumb, please try to use the DESERT acronym for describing the state of the issue, as this will make our interaction a lot easier, and will allow us to process your claim in the shortest time possible.
(D)escription → What’s happening? (describe the actual issue)
(E)nvironment → On which environment did it occur? (for applications having multiple environment)
(S)everity → How critical is it? Can be Blocker, High, Medium, Low
(E)xpected outcome → How should the functionality behave?
(R)eal outcome → How is the functionality behaving?
(T)echnical details → What technical details can you provide? (screenshots, technical info,etc)
An example of using the DESERT acronym for submitting a claim:
Context → The app is intended to be used in call centers so that users can execute calls to 3rd party agents.
(D) -> When I perform a call from my OnePlus 8 phone having Android 10, I seem to have some weird static
(E) → Production (live)
(S) → Blocker
(E) → The call should go through with crystal clear sound
(R) → The call goes through with static
(T) → Seems that the problem is from Twilio
Warranty claims will be processed as soon as possible.
Estimations for the amount of time needed will be provided per each DESERT formatted claim in part based on their overall complexity.