Submitting and Managing Tickets in Client Portal

Overview

When submitting support tickets in the Client Portal, providing the right information can ensure the problem is resolved as quickly as possible. The more specific the description of the problem, the more likely a TST member or your account manager (AM) will be ablet to solve it. Unless otherwise specified, client tickets are first routed through the Technical Support Team, then passed on to the school’s dedicated account manager when needed. This article provides a summary of helpful information to provide, a more in-depth list of questions to consider when submitting a ticket, and recommendations for prioritizing and closing requests.

Summary of Helpful Information to Provide


It is important to provide specific information when submitting a ticket. Providing some or all of the following information, as appropriate, can speed a resolution:

  • Axiom URL links to the query/report in question or to a particular person, donation, class, course, class enrollment record, etc. These are extremely helpful for our team so that we can find the data as fast as possible. Providing a link—even if you name the person/course/etc.—ensures we are (literally) on the same page.
  • Screenshots (include the whole window) of any error messages. We can often determine quickly whether the issue is a quick fix or something that should be passed directly to your account manager and support engineer to investigate further.
  • Exact username, should we need to log in as a user.
  • Steps taken that produced the issue.
  • Timeframe needed for resolution. While every request is important, it is helpful for us to know whether a request is truly urgent, and if not, whether it needs to be resolved within the day, week, month, etc.

Questions to Consider

What?

What is the problem? Write a concise topic, and a good description of what the issue is when entering a ticket. List the steps we can take to replicate the issue and always include an example URL, even if the question seems general or applies to a number of records.

Example:

Ticket Title: Unable to unlock Admissions Application
Description: Our Admissions Ops manager needs to unlock an application, if you open this application (EXAMPLE: https://axiom.veracross.com/school/#/detail/application/example/3073-general), go to the Other tab, and try to unlock it. After hitting update, the lock flag doesn’t update to be unlocked.

Tip: Do not assume the AM reading the ticket has necessary context. For instance, if relaying an email you received from your Admissions Ops manager, highlight the relevant portion in the ticket rather than pasting the entire message. Writing a concise description rather than an email chain, or putting a numbered list of issues ensures Veracross can interpret the issue(s) accurately.

Always include an example URL. If nothing else, the AM looking at the ticket can click it to be taken immediately to your school’s database and begin troubleshooting. If you are looking at a screen in Axiom/Portals/etc. and have a question about it, include the URL in the ticket.

Who?

For whom does the problem occur? Who is involved? Who is asking? Providing the who gives important context. Veracross is a large system, and knowing the problem was experienced by an Admissions Counselor rather than the System Admin helps focus the problem. Include a link to the person or security admin record of any users experiencing the problem.

Tip: Including the username user@school.org ensures that when Veracross works to replicate an issue, they are using the right user. Supplying a link to the security admin detail accomplishes this just as well. Due to the many different permissions in Veracross, system behavior can be very different from user to user, and simply knowing which user is experiencing an issue can help.

Where?

Where in the system is the problem happening? Where should the change be made? Veracross wants to solve the right problem or make the change in the right place, and in a system as big as Veracross, specifying where goes a long way: a specific query, detail screen, homepage, Portals screen, web form, or any other areas of Veracross. Where could also be specifying whether the problem happens on one record or many. Include the URL. Screenshots can be very helpful (of the whole page, including the URL), but include them in addition to the URL.

Tip: Axiom URLs are often better than videos or screenshots. While videos or screenshots can serve capture a system behavior in the moment, an Axiom URL takes away any ambiguity from the “where?” question, thus ensuring Veracross is working in the right spot.

Why?

Why is this problematic? Why should this be changed or fixed? Writing down an answer for why is often important when a schools is asking Veracross to change something, or the problem described may actually be how Veracross works. Telling Veracross why it is a problem can often help the Veracross employee ask for a system change that will address the real-world issue, or suggest a workaround that makes sense for the school.

When?

When do you need this to be resolved? Giving Veracross an idea of when an issue should be resolved makes it possible to prioritize against other requests, communicate back if the change, project, or patch needed to resolve the issue requires more time than desired, and ensure that Veracross meets the desired timeline whenever possible.

Communicate your timeline in the ticket.

How?

How do you want us to resolve the issue? While not always necessary, sometimes an issue or question has multiple answers or potential resolutions and so telling us how you want the issue resolved can ensure that Veracross delivers a resolution closest to what you (or your end users) expect.

Prioritizing Requests

There is no right number of requests to be managing in Client Portal. Some schools have a few open at any time while others have far more they are managing concurrently. Regardless of the number of tickets you have open, prioritizing requests ensures that work is accomplished in a timely manner.

There are various ways a school and the school’s AM can explicitely communicate priorities. This might be a weekly meeting to prioritize tickets, or it might be emailing a list to the AM once a week with top priorities.

Closing Requests

Closing finished tickets is important to maintaining clarity of priority and pending work. Veracross personnel will work with your team to close out tickets that are complete. When a request is finished by the Technical Support Team, they will send the ticket back to the school’s responsible party. If after a week no movement is seen on the ticket, they will update the ticket to ensure the delivered resolution was seen.

If the school wants to keep the ticket open, a note in the comment box affirming this will notify the TST member to move the ticket to the ‘Later’ category where it can remain open as long as necessary. If no comment exists after the second note from TST, the TST member will close the ticket after an additional week of inaction.

Of course, school client portal users can close tickets at any time they wish.