KPBSD Support Portal

Your technology Support Portal is available both inside and outside the District's network, at https://go.kpbsd.org/support, and whether you wind up just picking up the telephone or using one of its "deeper" features, you should always think of it as your first place to go, when you need help with your technology.

Overview

The point of the Support Portal is to put in one place your access to the support team (both the Support Helpdesk and the Ed Tech team), and to support services, both manual and automated. Services might be team-served, or self-served, or either in some cases, which could be handy at those times when you're working after hours (we understand how that goes) and we might not be at the phones. And, as we stand up more service automations, you may also wind up getting what you need faster via automated Service Request, faster even than by picking up the phone. (We're still "moving in" to service automation, but we're getting there!)

Portal home and main components

The Portal is available in limited form without authentication (e.g. to support new student registration), but to see everything your user account is entitled to see, log in with your District user account credentials (E-number for employees; six-digit student number for students). Note that the Support Helpdesk phone number, 99-8878 internally and (907) 714-8878 from outside lines, is right up by the login link (which, upon login, becomes the user-account link).

Along with a front-and-center search function, main Portal components present as "cards" on the main page, and via the menu at upper left. These components are: key "About" links, an article browser for the Knowledge Base, an entry point for logging an Issue, and an entry point for requesting a Service.

What's an "Issue"?

Historically, in our ticket system, KPBSD has not distinguished between the concept of an issue (aka problem), and a true service request. You have simply thought of "submitting a ticket", regardless of what it might be for, and District IT has handled and manipulated each ticket independently. This is obviously very flexible both for you and for us, but one significant limitation is that it limits the things we can automate--and we'd like to change that, to the benefit all of us.

What this means is that we now ask you to think of an Issue as "something that has gone wrong and needs to be fixed". Examples would include:

My user login is failing
My Windows Desktop icons have vanished
A wireless access point is not powering on
Internet service is down at the school
Print jobs are failing on the library printer
Outside calls are not reaching my phone
The unmanaged switch in my room has gone on the fritz
My phone is dark today, but my room's printer still works

For these kinds of needs, you want to submit an Issue, not a Service Request.

What's a "Service"?

By contrast, a Service Request is a need for something that represents a common fulfillment or assignment task, such as:

Assigning software to a Windows computer, or apps to a cohort of iPads
Enabling extensions or apps for installation on Chromebooks
Whitelisting web apps for use with District Google logins
Standing up a new network printer, or changing its location
Assigning a phone to a new user, or updating an existing phone to your name
Updating or transferring your District building keycard
Resetting your multi-factor authentication profile so that you can register a new method for your new phone

Now...those are good examples of at least partially automatable Services, but Services, in the sense of generally being fulfillment requests, can also be things like:

Request for physical repair of a laptop screen, or a battery replacement, etc.
A new custom PowerSchool report
Reconfiguration of a room to become the school's new computer lab
Help with room workstation setup
Adding a new wall drop, in a room that doesn't have one
Deploying a new school-purchased cart of Chromebooks, including wiring the cart

As we go along, and stand up more and better Service Requests, we're hopeful that the distinction will grow increasingly obvious, and more useful to everyone.

Where we were, where we are, and where we want to go

Historically, we have just thought of everything as a Ticket. As mentioned above, this has become limiting, and is not where we want to be, nor to go.

Currently, we (both you, from your end, and District IT, from ours) want to begin distinguishing Issues from Service Requests, as a matter of our practice. In the beginning, and during the maturation process, we recognize that we will have an incomplete set of available Service Requests, and the things that don't yet fit that mold may necessarily get lumped in with Issues. As always, we will try to make that as transparent and self-evident as possible, and whenever we have to make a choice, we will select the choice that is simpler for you.

Eventually, we want to get to the point where most common needs are available as mature Service Requests, and where true Issues are well-defined, and thus separable, from fulfillment requests. The "separable" concept highlights another key reason for going this route: entirely aside from the potential benefits of fulfillment request automation, a significant benefit of such a clear distinction is that we can more effectively prioritize true "problems" for faster attention.

Questions?

Our goal, with this Portal, is to make a resource that you can use as deeply or as lightly as you might need. Please remember that you are always free to contact the Support Helpdesk directly. :-)