Technical assistance and repairs software that manages, technical interventions, contracts, expiration dates, customers, agents, and several technical offices organized according to location an competences. All involved actors interact directly with the software and receive notifications.
The application is conceived for any kind of repair/help business. Repair areas that might benefit of our application include, but are not linited to, cars, industrial vehicles, industrial equipments, computers & software, mobile phones, domestic appliances, and any kind of buildings and house repairs.
The application is available with an SaaS model (annual fee) and can be configured with the customer logos, and adapted to the customer organization. Available advanced features such as sales agents management, and several repair shops, that can be disabled for customers that don't need them.
companies and users, customers contracts, requests services requests creation, requests processing, requests documentation
Companies and users
The application manages customers, several repair shops, and sales agents. Each company may have have several users with different roles and permissions. Also possible to group several roles or all roles in a single user to simplify all application operations in case of small companies.
The application handles the whole interaction between central management, repair shops, sales agents and customers. Each actor has access to all needed information and operations in its home page. Namely:
- Customers can submit and track their assistance/repair tickets and are notified of relevant events.
- Repair shops are notified of new requests assigned to them. Then, they process, track, and document them.
- Sales agents can manage their customers and track their requests.
- Central management supervises requests, assign them to repair shops according to their competences and geographic area, tracks and accounts all requests, manages contracts, companies and users.
Repair shops cover competences and are assigned to geographical areas. Agents and cusomers are assigned to geographical areas, and all companies can have electronic documents associated to them. Below how to handle customers electronic documents:
During system configuration it is possible to add custom field to customers. Thus, for instance, a car repair company can add a car license plate field to all customers. Customers can be filtered and searched according to the values of all their custom fields. The image below shows how to add a custom field:
Customers may have some of their requests covered by assistance contracts that ensure that some or all their requests be processed for free, or for lower prices. Each contract may cover several service types, that are defined when the contract is added to the customer. Then, discounted prices are automatically applied when customers submit requests that fall in those service types. Below the contact definition page:
Customers have access to all their contracts while central management
can search and filter them in several ways. Available a customizable
page of expiring contracts, and contract expirations can be optionally notified
via e-mail to both central management and involved customers.
Contracts can be renewed with a single click.
The applcation has a list of all services needed to serve the incoming requests. Usually, several services, are needed to serve each single request. The list of services is inserted during the system configuration, but futher services can be added at any time, and existing services can be modified. Below the service definition page:
Each service has both a normal price and a price for customers
covered by assistance contracts. Prices can be discountable or not,
they can be fixed or they may depend by some quantity (time, liters, number, etc,).
Moreover, each service can have an expiration time, that can be automatically notified or not. Depending on the service at expiration date some kind of verification or part change may be needed.
Together with services, requests can contain also custom information fields, such as, for instance, the exact date a part was changed. As for the services, these information fields are defined during the application configuration, but new information fields can be added at any time.
Requests can be opened either remotely by a customer or by an operator that somehow communicated with the customer. The "open request" page contains just basic information: the customer (only if the request is inserted by an opertaor, otherwise it is autodetected), a short description of the issue, priority, and an attempt to classify both area of competence, and service type. All service types covered by an assistance contract appear in a different color. The image below shows a request started by an operator:
If the request is opened by an operator with enough permissions the page shows also an button to pre-process immediately the request and to assign it to an operator of repair shop. Otherwise the request is added to a queue of requests to pre-pocess. In both cases, during the pre-processing stage the initial classification is confirmed, the request is assigned to a repair shop according to geographical area of customer and needed competences. Futher information can be added, such as notes for the repair shop operators.
After preprocessing, the request can be paused waiting that an operator of the chosen repair shop takes it in charge, or its processing modality can be chosen immediately (remote processing, appointment with the customer, etc.). Possible also to arrange an appointment with the customer in this stage. Below a typical pre-processing screen:
Appointments are automatically notified to customers and to interested operators, and reminders are sent when the appointment day/time is coming. Also request assignements are notified to interested operators. Both operator assigned requests and appointments are available through the notification icon on the top right of his/her application pages. Below a typical list of assigned requests and appointments.
Request processing can be entered either through the page notification icon, or through the "my appointments / requests" pages, or through the request-in-progress page. Once there, the operator has access to all request information, that might include also past request processing, as shown below:
He/her can change the processing modality, arrange appointments and finally he/her can record all services applied to the request. Below, a fragment of a services record page:
In this page the operator defines service expiration dates, if required, and fills all needed information fields.
At end of the whole processing and after having officially documented its job, as explained in the next section, the operator can decide if to close the request or if to start a new processing stage. New processing stages can be started either if the customer is unsatified with the result or if the request need to be passed to another repair shop with different competences.
New pre-processing stages can be started in the requests-in-progress page that shows all stages of each request with their completion status. Once entered in this page users can see just some of the requests, according to their permissions. For instance, all operators of a repair shop can see just the requests assigned to their repair shop. Also customers and agents, can access this page but with read-only permissions, and they are limited just to the requests involving them. Below a fragment of a typical requests-in-progress page:
Once an operatore finishes a stage it is required to sign electronically all services it recorded in the request. If he/her took an appointment with the customer, also the cusomer is required to sign the same document. Signature can be written with any touch screen device. Below a typical signature page for both operator and customer:
Requests and their associated signed documents can be searched through a request registry. The image below shows a fragment of the registry page:
The image below shows a typical signed document:
Finally, a request detail page:
Several completed requests belonging to the same customer can be assigned to the same invoice, as shown in the image below:
Once this is done, since most of data needed for the invoice are contained in the application configuration, and in the customers database, it is enough to provide invoice number, date, and payments, as shown below:
Once the invoice is ready, it can be exported in xml, passed to an invoicing software for further modifications, or printed, as shown below: