APPLICABLE AUDIENCE: PLATO Applications, United Kingdom and Australasia.
Some customers require a Purchase Order (PO) before chargeable work can commence. If your organization requires this, including the required PO with your Support ticket can reduce administrative overhead, delay, and ultimately cost.
Plato does not charge for remedying bugs in current versions of its own software. Other requests for support or services are chargeable.
A general definition of Software Bug is "logic in a software product that does not meet a software requirement (as stated in the requirement specifications) or end-user expectation (which may not be specified but is reasonable)."
Bugs can only be fixed by Plato remedying its logic fault. An issue that can be resolved without Plato having to change its application, is unlikely to be a bug.
Examples of Support Requests (SRs) that are NOT likely to be bugs include:
- Plato systems that worked correctly but now exhibit faults.
- Desirable new features or requests for different application behaviour.
- New issues affecting only one PC or user in an established system.
- Requested assistance to deploy Plato and ancillary software- e.g. newer Plato versions, new infrastructure, Ghostscript, IIS, SQL Server.
- Issues caused by non-Plato system outages or faults.
- Requests to perform databases changes, e.g. to undo/edit previously saved entries.
If your organization requires Purchase Orders and the issue relates to items like the above, you can streamline support and reduce cost by furnishing the required PO with your Support Request. Even if you believe the Support Request is for a bug, include the PO so that Plato can confidently start work on your issue and will not charge if the issue is a bug.
How many hours in the PO?
If your facility requires POs, a good rule of thumb is 2-3 hours that generally is sufficient to identify non-bug issues and offer directed advice.
However:
- If your Support Request includes enough steps or detail for Plato to reproduce the fault or identify the issue immediately, a PO may not be needed.
Example:
A SR is raised "Jocelyn on PC CAM-R112e reports that feature xyz has stopped working."
This new issue in an established system is unlikely to be a bug. The first task for a Plato engineer is to elicit enough information to engage the issue. A PO should be included so the engineer can start on this.
Alternatively: the customer's Information Services rep performs initial investigation, recording events or steps that led to this end point. This may be enough to identify that the issue is not something supported by the software vendor- e.g. a printer, networking, privileges or other setup issue. In addition, when a SR is raised by logging into the Plato support system, the system offers relevant Knowledgebase Articles based on the content of the SR- so a detailed SR may be enough to identify an article with a solution so that the SR is no longer needed.
Otherwise, with these steps included in the SR, a Plato technician is able to reproduce immediately if it is a bug, or often can offer directed advice or point to a relevant KB article with no need for a PO.
Sometimes a quote is requested before a PO can be supplied; however, if supplied information is limited, it can be difficult to define the issue adequately for a realistic quote. In such case if the initial 2-3 hour PO is not long enough to resolve the issue, it should yield sufficient information to allow a realistic quote.