Reducing VPN Tickets: Setup Guide, Self-Check and Known Issues

Tuesday, 16:40, at Fenwick Surveyors. Nadia runs a desk of three for a firm whose surveyors spend most of the week in fields, vans and client offices. She has the quarter's ticket export open because her manager asked a question at lunch: "Why is the VPN so bad?" It is not bad. Remote access was the third-largest category for the quarter, with seventy-one tickets in the last month alone. When she sorts them by cause the top four are the same four questions, asked by different people in different fields: how do I set it up, is it me or everyone, I got a new phone, and it says connected but. Not one of the seventy-one was the gateway. She has an hour before she goes home, and the answer to her manager's question is going to be a plan rather than a defence.

Reducing VPN tickets means three things done in order. First, remove the cause of the ones that repeat. Then answer the rest before they are asked. Then measure the change so the desk knows which of the two worked. The tools are unglamorous. A setup guide that a surveyor can follow in a van. A self-check users run before raising a ticket, which sorts most tickets into "fixed it myself" or "here is exactly what I tried". A known-issue list so that technicians stop re-diagnosing the same hotel. And a count by category, every month, so that the manager's question gets a number instead of a mood. This article is part of our VPN & Remote Access Tickets series, and it is the last one, because everything in it depends on the five before it.

It covers where VPN tickets come from, then the setup guide and the self-check. Next come the always-connected question in plain words, the known-issue list, and measuring by category. Then come what remote-first design removes and the order to do it in. A short war story and the VPN self-check article to copy finish the article, in that order.

Where VPN Tickets Come From

The honest count comes first, because a reduction plan built on "VPN not working" as a category will reduce nothing. The six categories and the first question that sorts each are in The VPN Ticket Categories and Their First Questions. That sort, applied at close, is the raw material for everything here. Nadia's month, sorted that way and then sorted again by what would have prevented each ticket, looked like the table below. The figures are one desk's month, stated as a worked example; the shape is what to look for in your own.

Read the right-hand column as a shopping list, and notice how short it is: a guide, a self-check, a sheet, a list and a calendar. Four of the five are documents, and the fifth is a one-page register the certificate article already gave you. Nothing in the column is a purchase, and nothing in it is the gateway, which is why the manager's question was the wrong question. The VPN was fine. The organisation had rolled it out to sixty people who were never told how it worked.

The Setup Guide

The setup guide is the document a user follows, alone, in a van, with no technician on the phone. It takes them from a laptop with no VPN to a connected one with a working second factor. It is written from the technician's runbook and not from memory. The method, taking each step of the technician's procedure and rewriting it in the user's words with the user's screen in front of them, is in Writing the User Guide From the Runbook. The VPN guide is its most-read example on most desks, because it is the one document every remote worker opens at least once. It starts with where to get the client and which version the desk currently publishes, then how to install it. Next comes how to sign in, with a line saying the password is the normal one. Then comes how to set up the second factor at the same sitting, not later. Next are the test page, with its full name, and what "connected" looks like when it is real. Then comes what to expect on a full or split tunnel, in one paragraph lifted from the what-works-where sheet. A short "if it does not work" section that points at the self-check comes last.

Two sections earn their keep more than the rest. "Before you change your phone" is the one that removes the Monday-morning authenticator ticket, and it is four lines: enrol the new phone while the old one still works, test a sign-in, then remove the old one, then wipe it. And "what connected looks like" is the one that removes the half-connected ticket. A user who knows the test page should load will check it before they ring. They will say "the icon is green but the test page doesn't load", which is a diagnosis. Both sections are short. Neither is in most organisations' guides, which is why most organisations have both tickets.

Keep the guide current by one rule: when the published client version changes, the guide changes the same day, and the date at the bottom changes with it. A guide that names a version the desk no longer supports will generate tickets from people who followed it exactly, and they will be right to be annoyed. Screenshots help, cropped to the one control that matters. The guidance on which ones help and which do not is in the knowledge base series. A guide with twelve full-screen captures of a wizard is a guide nobody scrolls to the end of.

The Self-Check

The self-check is a short article, visible to everyone without needing the VPN to read it. It walks a user through the first five steps of the can't-connect ladder in their own words and tells them what to do at each one. It is the deflection document for this whole series, and it works for two reasons. The first is that about half of the tickets in Nadia's month were resolved by one of its five questions. The internet is down, the client needs restarting, the password has expired, the phone's authenticator is empty, or the hotel is blocking it. The second is that the half it does not resolve arrive at the desk with five answers already written down. That turns a forty-minute ticket into a fifteen-minute one. The six steps as the technician runs them are in the diagnostic order; the self-check is the same ladder with the sixth step replaced by "tell us what you found".

Put the self-check where the ticket is raised. Add a link in the ticket form's description. Add a line in the auto-reply that says "if this is about the VPN, the five checks here fix most problems in a few minutes". Add a field on the remote-access form that asks which of the five the user has tried. If you run QuerySolv, the self-check is a knowledge base article visible to everyone. A department with its own form for remote-access requests can ask for the five answers as part of the request rather than as the first reply. The article itself is the template at the end of this piece. It is written for a surveyor in a van. It fits on a phone screen, which is where the surveyor will read it.

Resist two temptations in the self-check. Do not make it longer than five questions, because the sixth one is the one nobody reaches. The user who has done five and failed should be talking to a person. And do not put anything in it that the user cannot do safely alone: no reinstalling, no settings, no "contact the gateway team". The self-check is five questions, five actions, and one sentence saying what to send the desk. Users will follow it if it takes five minutes. They will not follow it if it looks like homework.

The Always-Connected Question in Plain Words

An always-on VPN is an arrangement where the laptop connects the tunnel by itself whenever it has an internet connection, without the user clicking anything. Someone in the organisation will raise it as the way to make VPN tickets disappear. It does remove some of them. It removes "I forgot to connect", "did I connect", and most of the connected-but tickets on a full tunnel. The laptop is always in the same state and users stop having to think about it. For a workforce that is remote most of the time and does not travel, that is a real reduction and the desk should say so.

It adds others, and the desk should say those out loud too. The decision will be made by whoever owns security and they deserve the ticket data. An always-on laptop on a full tunnel cannot see the home printer, ever, so the printer ticket becomes a standing complaint rather than an occasional one. An always-on laptop in a hotel cannot reach the captive portal's sign-in page. The laptop is trying to send that traffic down a tunnel that cannot exist until the sign-in is done. The user is stuck in a loop that the self-check must have a line for. And some always-on arrangements are built to block everything when the tunnel is down, which is excellent for security. In a café with no tunnel, a laptop with that arrangement can do nothing at all, including raise a ticket. Each of those is a design choice with a reason behind it. The desk's job is to know which choices were made and write them on the internal page. Put the consequences in the guide and the sheet. Never tell a user "that's odd" about something that is working as designed.

If the question is put to the desk, answer with the month's table. "Always-on would have removed about a third of this month's tickets and added a standing printer complaint from everyone on a full tunnel. The guide and the self-check would remove about half with no change to the gateway, and they cost two afternoons." That is not an argument against always-on. It is an argument for doing the two afternoons first, whatever happens to the gateway afterwards. It is the kind of argument a manager can act on at lunch.

The Known-Issue List

The known-issue list is the desk's internal page of faults it has seen before. Each has the symptom in the requester's words, the cause, the workaround, and whether a permanent fix is coming. It saves the fourth technician to see the hotel chain that blocks tunnels from spending forty minutes discovering what the first one wrote down. The form of an entry, and the discipline of retiring it when the fix lands, is the subject of Known Errors and Workarounds. The VPN entries are the most reused on most desks because the same handful of causes keep returning in new coats.

Nadia's list, after a quarter, had eight entries, and the first five explain most of the category. The hotel chain and the two client sites whose guest networks block tunnels, with the hotspot workaround. The laptop that slept, with the disconnect-and-reconnect step and the test page. The authenticator app that was moved but not its secrets, with the sentence that explains it to the user without blame. The short name in the bookmark, with the full name. And the client version that stops working after a particular kind of operating system update, with the restart that fixes it and the update that prevents it. Each entry is five lines. Each one turns a diagnosis into a lookup, and a technician who reads the list on their first day handles VPN tickets like someone in their third year.

Put the list where technicians already look, which is the queue or the internal knowledge base, not a document in a folder. Put the venue entries on the self-check too, in user words: "if you are at one of these places, use your phone's hotspot; the venue's network blocks the connection and it is not your laptop". A surveyor who reads that line before ringing has not raised a ticket, which is the entire project in one sentence.

Measuring by Category

Measure the category every month, by cause, in counts and in hours, and read the trend over quarters rather than the difference between two months. The method, counting by category over time so that a change in one cause is visible against the others, is in Volume by Category Over Time. The VPN category is one of the easiest to apply it to because the six causes are so distinct. What the desk is looking for is not "fewer VPN tickets". It is "fewer setup tickets after the guide went out", "fewer is-it-me tickets after the self-check", "fewer new-phone tickets after the before-you-change-your-phone section". Each one is a line on the chart that bends at the month its document was published. A line that does not bend is a document that nobody is reading, and the fix is to put it where the ticket is raised, not to write it again.

Nadia's quarter is a worked example, given in ranges. Remote-access tickets went from about seventy a month to somewhere between twenty-five and thirty-five three months after the guide, the self-check and the sheet were published. Over that period, technician hours went from about thirty-five to somewhere between twelve and eighteen. The setup line fell furthest and fastest. The new-phone line took two months to move, because people change phones when they change phones. The one line that did not move was slow-over-the-tunnel, because its cause was video calls on a full tunnel. That was a gateway decision the desk had passed upward with its count attached. Hours are the figure for the monthly report, because a manager can weigh "twenty hours a month back" and cannot weigh "forty fewer tickets". The one-page format is in The Monthly Report They Will Actually Read. The VPN line on it is one sentence with a number and a cause.

Per-technician figures in this category are for coaching and never for ranking. They are not read at all from fewer than forty or so VPN tickets per person, which on a desk of three is most of a quarter. The useful per-person question is not "who closes VPN tickets fastest" but "who is still reinstalling the client at step one", which the can't-connect card answers on its own and a leaderboard never will.

What Remote-First Design Removes

Some VPN tickets are removed not by a better guide but by there being less to tunnel to, and that is a design conversation rather than a desk one. A service that is reachable securely without the tunnel, because it was built or moved to be, generates no VPN tickets at all. Consider an organisation that has moved its mail, its documents and its main applications to places its people can reach from anywhere. Its VPN is used for the file share and the finance system and little else. The thinking behind building support for a workforce that is remote by default, rather than a workforce that is in the office with exceptions, is in Remote-First Support Design. The VPN count is one of its inputs.

The desk's contribution to that conversation is the data and only the data. The data should show which resources the connected-but tickets were about, how many hours the tunnel costs the desk a month, and which groups raise the most. Whether to move a service out from behind the tunnel is a security and architecture decision with reasons the desk may not see. A desk that argues for it as a ticket-reduction measure alone will be, rightly, asked what else it would like to move. Offer the count. Let the people who own the decision make it. The count is persuasive on its own, and the desk is not the only reader of it.

The Order to Do It In

Do the guide first, because every other document points at it and because the setup line is the biggest and the fastest to bend. Do the self-check second, with a link from the ticket form, and watch the is-it-me and the home-internet lines. Publish the what-works-where sheet third, which the split-tunnel article has already given you, and watch the connected-but line. Start the known-issue list the same week with whatever is already in the technicians' heads, and add to it from every ticket that reaches step five. Measure from the first month, before any of it is published, so that there is a line to bend. The whole plan is two afternoons of writing and one hour a month of counting. Nadia's version was finished before her manager asked the question again, which he did not.

A Short War Story: The Word "Enjoy" at Greyfriars Brewery

Tom, the one-person desk at Greyfriars Brewery, rolled the VPN out to sixty sales representatives on a Friday. He e-mailed them the installer, a sign-in name, and a message that ended with the word "enjoy". By the following Friday he had forty-eight tickets. Nineteen were people who could not install it. Eleven were people who had installed it and not set up the second factor. Nine were people in pub car parks asking whether it was them or everyone. The rest were bookmarks with short names in them. He wrote the setup guide over the weekend, from his own runbook, with the test page and the before-you-change-your-phone section in it. He sent it out on Monday with a self-check pinned to the ticket form. The second week produced seven tickets and the third produced four. The cost was a week of Tom's time and a week of a colleague borrowed from the warehouse to answer the phone. It also cost the sales director's opinion of the VPN, which took a quarter of good months to repair. The lesson Tom wrote at the top of the guide was that "enjoy" is not documentation.

The VPN Self-Check Article

The outline below is the self-check as a knowledge base article, written for the user and visible to everyone without the VPN. That is to say visible from the hotel, the van and the phone. Fill in the test page's full name, the desk's contact routes, the published client version and your venue list, and keep every step to one action. It is deliberately five questions long. The last block is what the user sends the desk when none of the five worked. It is the can't-connect card in their words. A ticket that arrives with it filled in is already two thirds done.

THE VPN IS NOT WORKING? FIVE CHECKS BEFORE YOU RAISE A TICKET
Takes about five minutes. Most VPN problems are one of these. Work down the list and stop when it is fixed.

1. IS YOUR INTERNET WORKING WITHOUT THE VPN?
   Turn the VPN off. Open a website you do not normally visit.
   - A hotel or cafe sign-in page appears: accept it, then try the VPN again.
   - Nothing loads: your internet is down, not the VPN. Restart your router or use your phone's hotspot.
   - It loads: go to check 2.

2. IS THE VPN PROGRAM RUNNING, AND IS IT THE RIGHT VERSION?
   Close the VPN program fully and open it again. If nothing changes, restart your laptop.
   The version we currently publish is: __________ (see the setup guide to update).
   Still failing: go to check 3.

3. DOES YOUR PASSWORD WORK ELSEWHERE?
   Sign in to webmail with the same password.
   - It fails there too: your password has expired or your account is locked. Raise a password ticket, not a VPN one.
   - It works there: tell the VPN program to forget the saved password and type it again.
   Still failing: go to check 4.

4. IS YOUR SECOND FACTOR ARRIVING?
   Does the prompt or code appear on your phone, and is it accepted?
   - New phone and the app is empty: raise a ticket; we will need to confirm it is you before we can re-enrol you.
   - Code always refused: check the phone's clock is set to update automatically.
   - You got a prompt you did not ask for: press deny and tell us.
   Still failing: go to check 5.

5. IS IT WHERE YOU ARE?
   Switch your laptop to your phone's hotspot and try again.
   - It works on the hotspot: the venue's network blocks the VPN. It is not your laptop. Stay on the hotspot.
   - Known venues that block it: ______________________________________________
   Still failing: send us the block below.

NONE OF THESE WORKED? SEND US THIS
   Where you are: ________________    What the VPN program says, word for word: ______________________
   Check 1: ____  Check 2: ____  Check 3: ____  Check 4: ____  Check 5: ____   (worked / failed / skipped)
   Does the test page __________ load while connected?  yes / no
   Anyone near you with the same problem?  yes / no
   Raise the ticket at: ______________   or ring: ______________
   Last updated: ______________

Nadia published the self-check on the Wednesday, with the guide the week after and the sheet the week after that. She answered her manager's question at the quarter's end with one line on the monthly report: remote-access tickets down from about seventy a month to about thirty, about twenty technician hours a month returned, no change to the gateway. He asked what the thirty were. She said she would tell him next quarter, when the lines had had time to bend. He found that a reasonable answer, which is the most a desk can hope for from a question asked at lunch.

Frequently Asked Questions