Enable End Users to Submit Their Own Tickets
In order for a user to create a ticket or be assigned as a Requester, they must either:
- Have Halp installed to their personal scope
- Be a member of a Team where Halp is installed
If neither of the above are true, then:
- The user will not be able to see the Halp icon in their message bar and has no way to create a ticket
- If an agent attempts to turn a user's message into a ticket on their behalf, the agent will see a warning like this:
How to roll Halp out to end users
There are a few options for doing this. The ideal route for you depends on your goals.
Option 1 [Recommended]: Install Halp for all users via an App Setup Policy
This is the most efficient, low-friction way to ensure that all users are able to create tickets and get help via Halp.
In this scenario, a Teams Admin can create an App Setup Policy to install Halp by default on all existing and new user accounts. Visit Microsoft's documentation to learn how to create an App Setup Policy.
This method of rollout has proven most successful for Halp customers. Those who use this method suggest distributing clear communications to your employee base explaining what Halp is, how it will benefit them, and how they can best use it. You should do this prior to enabling the App Setup Policy.
Customers found that doing so:
- Minimized user confusion & chances they thought they were being spammed or phished
- Maximized user adoption & success with Halp
- Increased overall Microsoft Teams usage & understanding of it as a collaborative space for work
To make this easy, we've created a Guide for End Users. You can link to this doc in your pre-rollout communication.
Microsoft's App Policies can take some time to fully propagate to all users in your org, up to multiple days in some cases. If users are not able to see or interact with the Halp app, some users have found that quitting and re-opening Microsoft Teams can help to trigger the update for them. Others have found the Teams Web App often updates faster than the desktop app.
Option 2: User's can individually install Halp to their personal scope
This method is best used for testing or a smaller, more controlled roll out.
In this scenario, you would ask a select set of users to install Halp on their own. Only these users will have the Halp icon added to their message bar, be able to create tickets, or have agents create tickets on their behalf.
This method works great while you are still testing help and getting everything configured. Customers have found success by reaching out to a few smaller internal groups and inviting them to be part of a Test Cohort. Not only does this give you a chance to gather feedback from end users, but it also helps Agents get a better feel for using Halp to solve for real world cases with end users.
When inviting end users to install Halp, we recommend providing them with a guide on:
- How to install Halp to your personal scope
- What Halp is and how it will benefit them
- How to open a ticket within Microsoft Teams
To make this easy, we've created a Guide for End Users you can send to any users that want to try out Halp.
Option 3: Add Halp to a public "Request channel"
This method is best for orgs that already utilized cross-functional, public Team channel where anyone can ask for help.
In this scenario, you can add Halp to a public Team. Instead of configuring this Team as a Triage Team, you will configure it as a Request Team. Anyone who enters this channel will have access to the Halp message icon and message action while in this Team's channels. When you add Halp to the team, you also select which queue you want it mapped to. Any time a user creates a ticket from within this Team, it will automatically be sent to that queue.
This method works best when you already have a Team or Channel that people go to when seeking help. For example, you might have a Help IT Team where everyone goes to get IT Support. This would be a perfect place to add Halp and setup a Request Channel.
If you don't already have this type of usage in Microsoft Teams, this might create more confusion in the early days. If your team currently only receives requests for help through email, direct messages, and/or ticket portals, Option 1 above might be better suited to your companies work style.
Learn more about Request Teams here.