1. Next Steps - Inputs to Processes
1.1. Remove these items
1.1.1. unnecessary quick picks
1.1.1.1. Test side first for validation. Plan is to meet with each MTS and go over the quick picks specific to their systems.
1.1.2. unnecessary issue entry fields
1.1.2.1. class
1.1.2.1.1. can pull stats based on organization, not needed
1.1.2.2. nws severity
1.1.2.2.1. not updated enough
1.1.2.3. nws status
1.1.2.3.1. covered by subcategory
1.1.2.4. location
1.1.2.4.1. we don't pull stats on this
1.1.2.5. required by date
1.1.2.5.1. not used
1.1.2.6. asset info
1.1.2.6.1. not used or reported on
1.1.2.7. causes
1.1.2.7.1. not used
1.1.3. unnecessary substatuses
1.1.3.1. Will cause some issues to no longer have a substatus, so MTS's will need to update their open tickets.
1.1.4. unnecessary tasks
1.1.4.1. Live side
1.1.5. unnecessary issue entry windows
1.1.5.1. Would like to go down to just 1 screen for all entries if it makes sense to do so. Need to investigate this further.
1.1.6. unnecessary reports and queries
1.1.6.1. Live side done
1.2. Adjust these items
1.2.1. remaining quick picks
1.2.1.1. Focus on critical info required, less text and less confusion.
1.2.2. remaining tasks
1.2.2.1. To ensure they are going to the correct recipient and are still valid for the quick pick.
1.2.3. remaining substatuses
1.2.3.1. will also remove a number of them from the "pause the clock" list, which will impact the "Adjusted time open" which is the primary SLA stat being looked at.
1.2.3.1.1. Techs will need to be on the ball with their substatuses.
1.2.4. issue trees
1.2.4.1. Goal is to remove all redundancies so reporting is much cleaner.
1.2.4.1.1. Easy to say but very hard to do as end users may expect an item to be somewhere different from where we'd expect it to be.
1.2.4.2. will end up moving things around some, MTS's will need to re-locate them
1.3. Add these items
1.3.1. "Notes" section
1.3.1.1. Required to be able to keep Project Fault Summaries entirely in NOTIS
1.3.2. "Vendor Notes" section
1.3.2.1. Required to be able to keep Project Fault Summaries entirely in NOTIS
1.3.3. Release version
1.3.3.1. Required to be able to keep Project Fault Summaries entirely in NOTIS
1.3.4. Issuetrak SLA Module
1.3.4.1. Will require "Severity", which will take the place of Priority.
1.3.5. SLA category field
1.3.5.1. A dropdown with the values of the SLA categories so that back end reporting is much quicker rather than having to manually look at each ticket in a spreadsheet to track the stats.
1.3.5.1.1. This will require YAF (Yet another field) however the time savings on the back end is worth the minimal effort per ticket to implement the change.
2. Find out
2.1. What is required for end of year reporting?
2.1.1. Sent Jerry an email
2.2. Try to get elaboration on this comment:
2.2.1. Searching for common phrases ends up resulting in a lot of tickets. I'd like to see ways of narrowing down the searches. I would like a better way of keeping track of Operational issues entered by other people. We might already have something in place, but I don't think anyone trusts what issues get e-mailed to everyone and what doesn't. Maybe we just need to put some procedures in place...or maybe we can make NOTIS do notification better.
3. Goals - Inputs to Next Steps
3.1. Survey results:
3.1.1. 65% of users use NOTIS multiple times per month
3.1.2. Almost 50% of users say it takes them longer than 5 minutes to enter a ticket.
3.1.2.1. Goal: Cut this number down by reducing the amount of options, which lessens confusion and is also in-line with survey comments.
3.1.3. 88% of NOTIS users are somewhat unsatisfied to very unsatisfied.
3.1.3.1. Goal: Take measures to increase our service level and customer satisfaction.
3.1.3.1.1. The plan is to roll out some changes, then do another survey in a few months.
3.1.4. Likes:
3.1.4.1. Ability to track tickets online
3.1.4.2. Quick picks do some of the work for us
3.1.4.3. Good visibility of existing tickets.
3.1.4.4. Lots of reporting options.
3.1.4.5. Being able to reply to Email updates is handy and saves time
3.1.5. Dislikes - Sorted by frequency:
3.1.5.1. Issuetype and Subtype trees are confusing, it's hard to find the correct option, the trees are needlessly specific and not intuitive, categories rarely match what I need.
3.1.5.1.1. Goal: Reduce confusion, reorganize trees
3.1.5.1.2. Just use the "Choose for Me" option and the technicians will select the best matches for you.
3.1.5.2. Too many steps involved to enter a request
3.1.5.2.1. Goal: Reduce the number of fields on the Issue entry form, as well as reduce the number of options in most drop downs in an effort to increase clarity.
3.1.5.2.2. If that's not enough, Submitters can just use the "Choose for Me" quick pick and be done in 2 steps: Logging in and submitting.
3.1.5.2.3. If that's not enough, existing Submitters can just send their issue to NOTIS@ and be done in one step.
3.1.5.3. Too many quickpicks to sort through
3.1.5.3.1. Goal: Remove redundant or unnecessary QP's.
3.1.5.4. Too many emails
3.1.5.4.1. Done: In the past there were several events which would trigger an email, however recently email notifications have been reduced to only the following: On submission, when a note is entered, when the issue is closed.
3.1.5.5. Quickpicks are not specific enough to cover my need
3.1.5.5.1. This Dislike is hard to mitigate, as the majority of survey respondents want less Quick Picks, but to fix this issue we'd have to add more very specific Quick Picks. More analysis is required to fix this.
3.1.5.6. Sometimes there is long delay waiting for a new user request because a personnel jacket does not exist yet.
3.1.5.6.1. Because most of the systems we use keep users forever if they're ever used once, we require specific people at specific agencies to Approve the addition of new personnel, units, call signs and the like.
3.1.5.6.2. If Submitters find they are having to wait too long because a specific person is not available, we have the ability to create a group and assign multiple people to it, then assign the task to the group instead of an individual. In this way, anyone from the group can keep the ticket moving forward.
3.1.5.7. Want one login for all programs
3.1.5.7.1. Unable to meet this request as most systems don't talk to each other, but we can adjust most systems if someone wants to change their current login name.
3.2. End Users
3.2.1. Reduce the number of quick picks
3.2.2. Reduce the amount of time it takes to submit a ticket
3.2.3. Reduce the confusion
3.3. Techs - Same as End Users but also:
3.3.1. Make NOTIS more relevant, don't want to waste time filling out fields that aren't used.
3.3.2. Edit tasks, substatuses and other items
3.4. Reporting:
3.4.1. Remove duplicates
3.4.2. Add fields that enable easier report creation
3.5. Overall:
3.5.1. For a change to be made, there must be a net increase in end user satisfaction.
3.5.1.1. For example if changing something makes End Users and Reporting much happier, but causes a small amount of additional work for the Techs, the change should be made.
4. Processes - Need group input
4.1. Normal issue intake process
4.1.1. Tickets should be opened immediately upon being notified of the issue/request so the clock is accurate.
4.1.2. Helpdesk personnel checks all fields of the ticket to ensure they're set correctly and makes changes if necessary
4.1.3. Initial triage begins
4.1.4. If more information is needed, start with a phone call to the user instead of an email.
4.1.4.1. If the call goes to voicemail, leave a message but also ask the question in the ticket and set the substatus to "Feedback Requested"
4.1.4.2. Technicians should never use Feedback Requested as a method of stalling or putting off the ticket.
4.1.5. If necessary submit the issue to the appropriate vendor, change the substatus to reflect the change and update the vendor reference to the correct issue/salesforce #.
4.1.6. A ticket may only be placed "On Hold" if agreed to by the end user. They should understand the reasoning and estimated timeline for completion.
4.1.7. All tickets must be touched at least every 3 business days.
4.1.7.1. All substatuses should be verified daily as this is the primary method of tracking the Adjusted time open, which is the primary reporting point of the SLA.
4.1.8. All substatuses must be checked daily to ensure the clock is accurately started or stopped.
4.2. Issues abandoned by the submitter:
4.2.1. If you've left a voicemail and a note in the Issue for the submitter but they still have not responded to your question within 3 business days (keeping in mind Officers and FireFighters may have extended time off between shifts) you should do the following:
4.2.1.1. Leave another voicemail
4.2.1.2. Leave another request for information in the ticket (Which should email the user)
4.2.1.3. Send a normal email to the submitter AND an appropriate second party such as their supervisor or someone else who may have the info explaining you need some outstanding information.
4.2.2. If after 7 business days you are still waiting for the information, send a note to the NOTIS Admin (Currently Mike) with the ticket #.
4.2.2.1. The NOTIS Admin will attempt contact with relevant parties to try to get the requested information.
4.2.3. If after 10 business days the submitter still has not provided the information, the ticket can be closed with a note stating "Unable to obtain required information from Submitter after repeated attempts."
4.3. Escalation or migration to another user:
4.3.1. If the Helpdesk personnel does not have the access or expertise to move the ticket forward, they should escalate the task or even the whole ticket to the appropriate MTS.
4.3.1.1. The secondary user should acknowledge receipt of the task / issue. A simple "Got it" will suffice.
4.4. Automatic escalation:
4.4.1. Tickets which have automatically escalated means they have not been touched in over 24 hours since submission.
4.4.1.1. The NOTIS admin (Currently Mike) gets an email when this occurs and will assign the issue immediately to the most appropriate MTS.
4.4.1.1.1. Unless the escalation occurred because of the weekend or a holiday.
4.5. People on Leave?
4.5.1. New tickets
4.5.2. Existing tickets
4.6. Definitive tracking guide for toggl vs notis
4.7. Need to make Ticket enforcement strategy
4.7.1. Checking all facets of tickets for errors to be corrected
4.8. Billing, rework, etc processes
4.9. Reference sheet for users for common problems
4.9.1. Who do they call first, us or agency?
5. Training - Mike to provide training and FAQ to end users.
5.1. Can open a ticket by sending an email to notis@
5.1.1. If the name of the quick pick is in the subject line, it will choose it for us.
5.1.2. Only works if the recipient is already a registered user
5.2. Users are not forced to use quick picks, but it helps the technicians if they are used.
5.2.1. Leave it up to the submitter if they want to use them or not.
5.2.2. The Quick Picks are designed to automatically choose the appropriate Issuetypes and subtypes, and also prompt the Submitter to provide required information for us to be able to fix the issue. The danger of not using a quick pick is that technicians may not have all the info they need.
5.3. Submitters can feel free to use the "Choose for Me" option, we'll fix it on the back end.
5.3.1. Provides a higher level of customer service; techs would be doing this anyway if the person had called 5690; should not take us long to do it for the end user; satisfies a number of "Dislike" survey user comments
5.4. Sometimes there is long delay waiting for a new user request because a personnel jacket does not exist yet.
5.4.1. Because most of the systems we use keep users forever if they're ever used once, we require specific people at specific agencies to Approve the addition of new personnel, units, call signs and the like.
5.4.2. If Submitters find they are having to wait too long because a specific person is not available, we have the ability to create a group and assign multiple people to it, then assign the task to the group instead of an individual. In this way, anyone from the group can keep the ticket moving forward.
5.5. Want one login for all programs
5.5.1. Unable to meet this request as most systems don't talk to each other, but we can adjust most systems if someone wants to change their current login name.
6. Maintenance
6.1. Weekly
6.1.1. Check for new self-registered users and fix their organization - Mike added outlook reminder
6.2. Quarterly
7. Purpose of Restructuring
7.1. Big Picture: The IT mission is to deliver technology solutions and services to meet the needs of our Communications Center, Police agencies, Fire agencies and internal business units. Our goals are to: • Exceed the expectations of our customers. • Improve efficiencies through automation and the application of new technology. • Provide responsive and proactive services to our public safety community. • Continually improve on our quality of support, technical skills, processes and documentation. • Collaborate with other public safety entities to provide additional value to our agencies and citizens.
7.1.1. NOTIS is the gateway for our end users to communicate issues with us, but we need to adjust NOTIS to fulfill our mission of exceeding expectations, improving efficiency and to improve our quality of support.
7.2. Current NOTIS captures a lot of info we DON'T use/need, and is failing to capture some info we DO use/need.
7.3. Changes need to be made, but Mike does not want to change things without group input.
7.3.1. That being said, the deadline for the restructure is ASAP, so we must move efficiently.
7.3.1.1. I will also be asking for flexibility and patience. Some things we change may cause additional temporary work, or may be reverted back if it doesn't meet our needs.