Requester

An elaborate and yet user-friendly helpdesk solution

Telephone, e-mail, meeting in person. These are just a few examples of channels by which requests for services or products that you offer flow to you. And such channels aren’t just used by your customers –suppliers or even your own staff use them. So how can you manage the flood from all the various streams? How can you save their history and somehow record them? The solution is a proven and elaborate helpdesk system.

Cleverlance has been developing its Requester solution for some time now. The Requester meets all expectations of a real helpdesk system. It can bring all requests together to a single place and manage them there for their entire life cycle. Access to the requests queue is possible at anytime since it’s a web application.
Users have clear rights set, so everyone sees and works with what they are permitted.  The Requester also features a processed workflow solutions of the individual requests. But the best part? Thanks to Requester you’ll have an excellent overview of things such as how long a task takes or which employee is the best in resolving requests.

Why choose the helpdesk solution from Cleverlance

• Requester was created based on our experiences from Cleverlance’s operation for internal workflow.
• Thanks to our vast practical experience, we provide customers support on a high technical level, since we ourselves created the system.
• The solution is cheaper compared to the competition, since Cleverlance uses it internally and costs for further development are thus shared with other customers.
• Requester is based on ITIL principles.

Some crucial advantages and benefits of the Cleverlance solution

• Despite many properties and functions the solution is user-friendly, intuitive and very clearly arranged – customers often don’t even need a manual.
• You can choose between a solution that Cleverlance itself operates and the customer pays for it only as a service, and a solution that we make to order and implement for the customer.
• It is one of few systems that manages to inform of requests and workflow steps via e-mail as well as text messages to mobile phones.

More on the Requester helpdesk solution

The Requester is an Internet application allowing mutual intra-company and inter-company communication in task assignment and reporting faults in current systems. It consists of a Request Management System (RMS) and Helpdesk system with making, administering, managing and recording requests, suggestions or disputes in development, project or production activities or in the Quality Management System (QMS).  Requester contains support for QMS ISO 9001:2000 and robust support for requests workflow.

Basic characteristics

Requester features flexible planning of projects administration. This includes the recording of tasks and the monitoring of complete documentation for these tasks according to the defined workflow with full support for the user-rights system. The rights system was designed with the utmost flexibility, enabling rights to be assigned to tasks and projects for individual users, user groups and companies.

The user’s relation to a task can be in the role of the creator, i.e. the individual entering the task to the system or the solver – the individual trying to solve the task. The creator and solver can, under certain circumstances, be the same user. One of the system’s properties is that in creating a task its solver cannot be immediately assigned. Only the project manager determines the specific solver for a given project. This is so that the creator cannot directly assign the task to a specific solver, but only to the company. Other roles are owner, guarantor and tester. The role of guarantor is chosen from the project, if the guarantor is defined in the project. The owner is the logged-in user after the task is created. The role of tester is defined within the project. Only the project manager can change it.

Each task is resolved through a workflow that is specific for the given type of task. The various requests differ with the task type according to the stages they can reach as they are resolved. A request to resolve a dispute in QMS will have different stages, and a request for a new functionality in an application with have a different workflow.

A task is passed through a solution process into the defined stages by the creator, solver or other roles specified in the given workflow.    Written comments or attachments such as images or text documents can be added to each stage.

The system provides a graphic tool to model the specific workflow. This enables implementation of enhancements such as approval processes, integrations with other applications, various communication channels, automation, etc.

Solution advantages

• 100% documentation of resolved requests,
• written comments, communication records,
• possibility to attach files as supplementary documentation,
• all temporal relations,
• the end of disputes over facts,
• workflow ensures the observance of prescribed procedures for resolving tasks,
• standardisation of processes within the company,
• elimination of disputes with the creator, creator feels positive,
• the latest stage of completing tasks is known at any time,
• no task is lost,
• clear responsibilities for performing / not performing tasks for creator and solver,
• possibility of linking to invoicing, project planning system, work records, DMS, QMS,
• assessment of resolved tasks (time, price, etc.).

A sample life cycle of one task

The sequence of stages is given by the task type – a new request or error correction, or workflow bound to the task type. The following description is only an example of how a task’s life cycle can appear. The Novako company mentioned in the company is merely fictitious, thought up for illustrative purposes.

The user Karel Testing from the company Novako creates in Requester a new task of the “Error Correction” type to correct an error in the implementation of a portal that Cleverlance is creating and operating for Novako. The task is now in the “New” stage; Mr. Novák is the creator, Cleverlance is the solver. The creator cannot assign the task to a specific worker of the solving company, only to the company as such. This is because the assignment of a specific solver is an internal matter of the solving company.

The project manager on Cleverlance’s side, Martin Project, switches the task to the “Being solved” stage, whereby he lets it be known that Cleverlance has accepted the task and is commencing work on it. He then assigns the task to a specific solver, in this case Michael Coder.

Michael Coder switches the task to the “Solution commenced” stage, thereby letting the creator and the project manager know that he has begun work on the task.

Upon correcting the error, Michael Coder switches the task to the “To be accepted” stage.

Karel Testing from Novako checks whether the error was really corrected and switches the task’s stage to “Accepted”. Martin Project, as the project manager on Cleverlance’s side, then switches the stage to “Completed”, whereby the task is closed and finished.