Halp, Atlassian’s new ITSM solution
What is Halp?
Halp is a lightweight Service Desk client for the Teams and Slack chat-ops applications acquired by Atlassian in 2020. This means that through Halp we will be able to manage support requests created from Teams or Slack messages and resolve, edit and generally support them through these applications.
In this article we will try to explain what Halp is, its basic functionalities, its licensing conditions as well as what it provides within the Atlassian ecosystem of solutions to finish with the impressions gathered after taking the first steps in the configuration and use of the tool.
Functional approach and key functionalities
As mentioned, Halp offers a limited service portal to carry out a very basic management of support requests with the particularity that it natively incorporates an integration robot with two of the most widely used business messaging tools currently in use: Microsoft Teams and Slack.
If we look at how the application is structured for the user, we find two well-defined parts: the module that groups together the management of requests and the configuration of the tool and the messaging tool itself.
As for Halp’s own module, it is an Atlassian SaaS portal such as Jira Software Cloud in which, through the url defined during creation, you can access the list of existing requests, the reports through which you can exploit the information of the requests and the configuration of the tool. We also have available a functionality still in beta phase that allows you to select predefined responses and classify them by tags.
Let’s take a detailed look at each of these sections:
List of tickets
As we have said, this section shows the requests created in the system. Fortunately, Halp incorporates a large number of options for filtering these tickets and also allows us to define the fields that we want to show in the list. We can sift the requests according to the assigned agent, the creator, the status, the creation date and the date when it was last modified, always playing with the fields in a visual way (we are not going to find here the possibility of creating JQL queries). Once we click on a request we can edit it, see its
comments and add a new comment. We also have the option to archive the ticket, add followers, share it and open it in the messaging tool, in this case Slack.
Reports
The reports panel shows the intentional simplicity of the tool at this point, as only 4 predefined reports are shown, two of them related to the two SLAs that the system handles: Resolution time and First response time; and the other two are the old familiar ones for Jira Software users: Tickets created (Halp forgets the solved ones) and Workload by assigned agents. As we can see here the tool has room for improvement and we miss more variety of reports as this functionality is basic to follow up the evolution of the requests and the performance of the agents’ team.
Answers
As mentioned before, through this functionality we will be able to manage predefined responses in a similar way to the “canned responses” of Jira Service Management.
We see a link to synchronise with Confluence but unfortunately in this still beta version it is not yet available.
Later we will see how we can use these responses from Slack and facilitate communication through the messaging tool.
Configuration module
Once we have seen the part of the tool that users will use on a daily basis, let’s see what configuration options we have to customise the application according to our needs. Surprisingly, the options we have at our disposal are many and quite well thought out, ranging from the definition of permissions to create and edit tickets from the chosen chat-ops tool to the possibility of adding integrations with applications such as Jira, Confluence, Zendesk or Zapier, through the management of the workflow status of the requests or the possibility of adding new SLAs and even creating automations to trigger actions depending on certain events.
Let’s take a brief look at the most important options:
Customised fields
Yes, in Halp we have the option of creating custom fields in the image and likeness of Jira… or almost because Halp only allows us to choose between five types of fields and does not allow us to define their obligatory nature. We can also define to which queue of requests the field will be applied and its label.
Recipe Builder
If we translate this striking name as “automator” we will see it more clearly. This module allows us to define actions that will be executed automatically when a certain event occurs.
Obviously we don’t have the possibilities that Jira Service Management Automation gives us, but the collection of triggers is not bad and the most basic actions are included. It is surprising that such a simple tool has a module as useful and in demand as this one.
As a mail handler, we can define an email address so that tickets sent to it are created in the system and even create a “white list” of allowed senders and an automatic response for them when their ticket is generated. No big frills are allowed but it provides us with something as necessary as email integration.
Integrations
Among the possible integrations that we have mentioned above, we have tested the integration with Jira Software Cloud and found it very easy to configure.
We will choose the Cloud instance associated to our Atlassian user and we will define the fields to synchronise and the project to end up creating the rule that will determine when the request will be created in Jira, establishing a bidirectional synchronisation between the requests.
Now that we have seen in detail the possibilities that Halp offers us through its own interface, we are going to go deeper into the creation and management of tickets through Slack as the messaging tool chosen for this analysis.
Ticket creation and management in Slack
The main objective of Halp is to facilitate the management of support tasks from a channel as accessible as Slack or Teams, so it is crucial that the management procedure is clear, agile and effective. Let’s see if this is the case.
Pre-configuration
Before being able to create tickets through Slack, we need to enable a triage channel that will serve as an inbox for agents’ requests. Once created, we must add the Halp bot with the simple instruction /invite @Halp, which will allow us to have the application’s functionalities in our channel. In the same way, we will be able to add several channels used as queues of requests that will serve as entry points for tickets for the requesters. Halp will inform us of these requirements from the tray of the application-bridge installed in Slack.
Ticket creation and management
Once we have configured our triage channel and the channels for requestors, Halp allows us to create applications in two ways: by expressly invoking the application’s bot using the /halp command or, curiously, by using an emoticon accompanying any message added to the channel.
The first way is of course the most traditional and very similar to the use made of the different bots that can be added to this type of application, and through it we can not only create new requests but also search for existing ones.
The second method does stand out for its originality since, by means of an emoticon, we will indicate that a message sent to the channel becomes a ticket.
The first few times it is cumbersome to search for the exact icon to use, but once we have it among our most used icons, the procedure is quick and intuitive.
Once we have indicated that we want to create a request in one way or another, we will be shown the screen that we have defined with the necessary fields for the creation if we really need any field apart from the title of the request.
Once the ticket has been created, we will be able to edit, transition, close or comment on it from our triage queue, being able to choose one of the “canned” responses that we have defined through the Halp interface.
At any time we can review the ticket comment thread both from Slack and from the ITSM client interface.
Product plans and pricing
As is usual in other products of the Atlassian suite, Halp also offers 3 subscription plans depending on which will vary both the functionalities and, obviously, the price of the solution. In this case we have a basic plan called Team, a more complete one called Professional and a last plan called Enterprise that incorporates all the possible functionalities of the product whose price depends on the chosen functionalities.
The Team plan seems quite competent compared to the more basic plans of other applications and, although it lacks multiple incoming email addresses and better integration and support options, it can serve quite well for a regular use of the product.
Product evaluation
We found Halp’s proposal interesting at a functional level: the product is competent in terms of functionalities, hiding possibilities of greater complexity behind a simple façade that it maintains in terms of customisation of the lifecycle of requests and diversification of the types of requests.
However, we believe that the weakest point of the proposal is the very price of the product compared to Atlassian’s “sister” solution for this same need, which consists of using Jira Service Management integrated with Slack or Teams through their respective bots or connectors, free of charge, at least the most basic ones. We found that the cost of Jira Service Management per agent is $20 and that of Halp is $25, offering a base product that is clearly more basic and limited and which is difficult to find a place for on equal terms in terms of licensing costs, unless you are looking for a simple product that leaves fewer options for configuration with a less pronounced learning curve than that required by Jira Service Management project management.
Here comes the million dollar question: When should I be interested in Halp? Well, in our opinion Halp would be an option to consider if you are using Slack or Teams as a communication channel for tasks or support requests in your organisation and you want a tool that is easy to set up and does not require a lot of learning time. On the other hand, if you are looking for workflow customisation options beyond the definition of statuses, different types of requests, elaborate creation screens and, obviously, a service portal in which to display an elaborate service catalogue, the best option for you is probably Jira Service Management and its functionalities to connect with Slack or Teams.
These have been our impressions, it has been interesting to learn about this product that escapes from the usual line offered by Atlassian and we invite you to create a trial, try it yourself, leave us your impressions and above all keep us in mind as your Atlassian partner of reference to guide you on your options if you are considering implementing an ITSM solution. We look forward to your comments!
Once we have configured our triage channel and the channels for requestors, Halp allows us to create applications in two ways: by expressly invoking the application’s bot using the /halp command or, curiously, by using an emoticon accompanying any message added to the channel.
The first way is of course the most traditional and very similar to the use made of the different bots that can be added to this type of application, and through it we can not only create new requests but also search for existing ones.
The second method does stand out for its originality since, by means of an emoticon, we will indicate that a message sent to the channel becomes a ticket.
The first few times it is cumbersome to search for the exact icon to use, but once we have it among our most used icons, the procedure is quick and intuitive.
Once we have indicated that we want to create a request in one way or another, we will be shown the screen that we have defined with the necessary fields for the creation if we really need any field apart from the title of the request.
Once the ticket has been created, we will be able to edit, transition, close or comment on it from our triage queue, being able to choose one of the “canned” responses that we have defined through the Halp interface.
At any time we can review the ticket comment thread both from Slack and from the ITSM client interface.
Product plans and pricing
As is usual in other products of the Atlassian suite, Halp also offers 3 subscription plans depending on which will vary both the functionalities and, obviously, the price of the solution. In this case we have a basic plan called Team, a more complete one called Professional and a last plan called Enterprise that incorporates all the possible functionalities of the product whose price depends on the chosen functionalities.
The Team plan seems quite competent compared to the more basic plans of other applications and, although it lacks multiple incoming email addresses and better integration and support options, it can serve quite well for a regular use of the product.
Product evaluation
We found Halp’s proposal interesting at a functional level: the product is competent in terms of functionalities, hiding possibilities of greater complexity behind a simple façade that it maintains in terms of customisation of the lifecycle of requests and diversification of the types of requests.
However, we believe that the weakest point of the proposal is the very price of the product compared to Atlassian’s “sister” solution for this same need, which consists of using Jira Service Management integrated with Slack or Teams through their respective bots or connectors, free of charge, at least the most basic ones. We found that the cost of Jira Service Management per agent is $20 and that of Halp is $25, offering a base product that is clearly more basic and limited and which is difficult to find a place for on equal terms in terms of licensing costs, unless you are looking for a simple product that leaves fewer options for configuration with a less pronounced learning curve than that required by Jira Service Management project management.
Here comes the million dollar question: When should I be interested in Halp? Well, in our opinion Halp would be an option to consider if you are using Slack or Teams as a communication channel for tasks or support requests in your organisation and you want a tool that is easy to set up and does not require a lot of learning time. On the other hand, if you are looking for workflow customisation options beyond the definition of statuses, different types of requests, elaborate creation screens and, obviously, a service portal in which to display an elaborate service catalogue, the best option for you is probably Jira Service Management and its functionalities to connect with Slack or Teams.
These have been our impressions, it has been interesting to learn about this product that escapes from the usual line offered by Atlassian and we invite you to create a trial, try it yourself, leave us your impressions and above all keep us in mind as your Atlassian partner of reference to guide you on your options if you are considering implementing an ITSM solution. We look forward to your comments!