Knowledge Base
Note: This Knowledge Base is a work in progress – We’re adding things as quickly as we can
Agile Service Delivery Run Guide
Data and System Backup
Backup Monitoring and Management
Tell us how can we improve this post?
Monthly Maintenance Scheduling Procedure
General
Special Scheduling Notes
Tell us how can we improve this post?
Daily Monitoring of Client Systems (NOC Routines)
General
Tell us how can we improve this post?
RMM Methods and Configuration
General
Remote Monitoring & Management
Tell us how can we improve this post?
PSA Service Templates
Setting up Service Templates
Tell us how can we improve this post?
Invoice Review before Processing
General
Reviewing Invoice Time Entries
Reviewing Invoice Expense and Product Entries
Terms to use when annotating time entries
Tell us how can we improve this post?
Managed Services
General
New Client Onboarding
Tell us how can we improve this post?
Time Sheets Submission and Approval
General
All timesheets need to be maintained in real time for several reasons. The primary reason is it is the most efficient way to work for all involved. Second to that, the management process for completed tickets is to review the time and then Close the ticket. Once the ticket is closed, time entries cannot be made or changed without opening the ticket back up. This would require having to re-evaluate the ticket and close it again only because one time entry was added or altered.
Time Sheet Submission
Perform each of the following steps on every day’s entries before submitting your Time Sheet in the PSA.
- Verify all the days’ time entries are contiguous for your shift i.e. from 8:30am to 5:30pm or 12:30pm to 9:30pm.
- Scan down the Start/Stop column and verify each end time coincides with the next entries start time. Fill in all missing time slots.
- Verify each time entry starts and ends on either a quarter hour marks (Field Service) or five minute mark (Help Desk).
- Verify there are no overlaps in time entries.
- Verify all entries have the correct “Where” entry (Remote or On-Site).
- These are your time entries and no one knows better than you whether you were on Site or Remote so double check each entry and correct all those that have been miss marked.
Note: This is very important because the client is billed according to their On Site or Remote hour minimums.
- These are your time entries and no one knows better than you whether you were on Site or Remote so double check each entry and correct all those that have been miss marked.
- Verify all Personal and Vacation time entries have been correctly offset by a matching Deducted entry.
- Scan the Charge To column for Personal or Vacation entries. Verify the Type/Role column indicates Personal.
- For each Personal and Vacation entry verify that the time is zero hours. If it is not change the Deduct field in the time entry to completely off set the hours entered.
- Verify there is a lunch break entry every day and the time has been correctly offset using the deduct field.
- For each day there is not a specific Lunch break (Personal) time entry, find the time entry that overlaps the lunch break and verify the Deduct field entry completely offsets the time taken for that days lunch break.
- Make all final revisions on time entries that you know need to be updated with tech, internal or billing notes.
- Review all Time Entries and verify that the main Note section has sufficient information to support the time spent on that task. Update notes as needed to justify the time spent beyond what was estimated or is reasonable for the task.
- Verify that the Internal Notes section has sufficient information to support either Why we should bill the client for this time (task not covered under Managed Services) or Why we should Not bill the client. (Rework, Too much time on task, etc.)
- Submit Time Sheet for approval.
If your Time Sheet is rejected review and correct each entry as noted in the email received from the PSA or as noted in the Time Sheet entry rejection notes then resubmit.
Time Sheet Approval Process
- The Service coordinator reviews all the previous day time entry each morning for new techs or when a tech is still having trouble working and tracking time in real-time.
- For example, On Wednesday morning you would review Tuesday’s entries. On Monday morning you would do a final day of the week review for Friday’s time entries, and then accept the time sheet for final overall review.
- We review the following:
- Start with first technician check all service tickets that they have worked on for that day check the following:
- Correct contract
- Service Type
- Estimated time
- Resolution was the problem solved
- Grammar
- Start with first technician check all service tickets that they have worked on for that day check the following:
- Make sure they have 8 hours of time and meet the billable hour’s goal, you can hover over billable hours in the PSA and if it’s not meet it will be red.
- Next click on report view \ Report type drop down all days this will give you the daily time entry as they get entered into the PSA.
- Follow all the steps outlined in the Time Sheet Submission section above in reviewing Time Sheets.
- Reject all incorrect or incomplete entries.
- Use descriptive notes to ensure the entry is corrected the first time by the team member.
- Enter all needed corrections into the Timesheet Review Email – Template located the Share site and send to each technician.
- Note: Each incorrect entry must be individually marked as Rejected or the team member will not be able to edit the entry when their Time Sheet is rejected.
- Reject the Time Sheet and include any additional notes in the final PSA notice that will be sent to the team member.
Tell us how can we improve this post?
Troubleshooting Guidelines and Primer
General
Tell us how can we improve this post?
Service Call Guidelines
Travel Time Tracking
MPI Materials, Parts and Tools
Each technician needs to have the certain supplies and tools to be able to perform their daily work tasks.
Appendix A is the list of the minimum required items to have available or on hand for every visit to a client’s office. The technician is expected to maintain the on hand supplies listed (from MPI stock) at all times. That is to say, if something is used up or sold out of the tech’s supply they need to get it restocked as soon as possible. The intention is to never be on site without something you should always have on hand.
MPI will supply all the items on the list if necessary including a suitable container.
Once the list of items is assembled and inventoried the technician is to sign for the list of supplies.
A copy of their list will be maintained in their employee file. Once created, only major item additions and deletions will be tracked.
The technician is ultimately responsible for the care and inventory of the items.
Any delivery to a client, loss, damage, theft or other disposition of an item is expected to be reported to MPI in the appropriate manner as soon as possible. That is to say, if an item is delivered or left for a client to own and use it must be entered on the product tab of some SR in a timely manner so that it can get correctly billed. If an item is dropped, otherwise damaged, etc. it must be brought to the service managers attention immediately. The preferred method of informing the service manager is via email.
It is reasonably expected that the technician will safeguard any MPI property appropriately. It is expected that it will never be left in an unlocked vehicle or left in any vehicle overnight in a location that could be considered a high crime district.
Preparation for the visits
- Always dress professionally.
- Think ahead and obtain or arrange to have all of the following for the visit:
- TechNet binder
- MPI Materials
- Tools – General
- Tools – Specific as required
- Hardware required for the job
- Software required for the job
Parking
- Park in Visitor or Guest parking as designated. Try not to take spaces close to the building out of courtesy.
- Always park in a Pay parking lot vs. on street metered parking.
- MPI pays for all parking fees while on the clock.
- MPI does NOT pay for in and out fees if you choose to go somewhere for lunch other than what is available.
- MPI does not pay for parking tickets.
On Site Routine
- Follow the MPI guidelines for phone Etiquette.
- Follow the MPI guidelines for Email Etiquette.
- Check in with the client contact if possible.
- Always work from an SR. If there is not one, create one, get it prioritized and go on.
- Follow the MPI procedures for Service Request escalation.
- We have an on-site minimum of 1 hour so:
- Never leave the clients office without checking with the client contact to see if there are other things they need done.
- If they have nothing pressing then review and work on any open SR’s.
- Attempt to put in the remaining time performing some desired and useful work either on the Server(s), workstation or at a minimum the Network Documentation Binder.
- If there is time in the day move from one SR to the next keeping the PSA up to date as you go. It will allow you to get the most work done with the least clean up at the end of the day.
- Never be in a hurry to get out of the office.
- Check with Client Contact and convey status on all outstanding issues.
- Make a final round check with all users especially those who had issues to be resolved.
- If required, create Service Requests for all unresolved issues.
- Do not leave the site until the PSA is completely up to date.
- Time
- Travel Time
- Mileage
- Expenses (if possible)
- Detailed work documentation including Internal Analysis notes.
- Product delivered to the client. Billable or Not.
Tell us how can we improve this post?
Technician Time Management Guidelines
General
The Technician’s Day is a routine and it is expected that the technicians will follow it very closely.
The time log and PSA time entry examples are designed to show a technician how to track time if the PSA is down and help bridge the gap between running in logged time vs. real time.
A Technician’s Day
This routine is simply a continuously looping process of subroutines. After each subroutine, begin at the top of the list again. For example, if you have managed to complete a service ticket and have updated your time entry, you go back to the top and work your way through the subroutines in order again.
The Warm Up
The first thing every work day morning, long before you are expected to be at the office, on site, or the last thing at the end of the day before:
- Check the PSA Dispatch Portal to see what you have been scheduled for.
- Check your MPI email for updates or information from the Service Manager, scheduler or other manager regarding work and priority for the coming day.
Note: You are not expected to process all of your email at this time.
The Routine
- Check and Process your email (see Checking and Processing Email in an earlier section)
- Check and Process your voice mail (see Checking and Processing Voice Mail in an earlier section)
- Work what you have been scheduled to work on at the time scheduled – SR or Activity
Note: If there is travel involved plan ahead. - Work any Priority 1 SR’s that has been assigned to you.
- Work all High Priority Activities assigned to you.
- Work any Priority 2 SR’s that has been assigned to you.
- Work all Medium Priority Activities assigned to you.
- Work any Priority 3 SR’s that has been assigned to you.
- Work all Low Priority Activities assigned to you.
- Work any Priority 4 SR’s that has been assigned to you.
- Work all other SR’s from the appropriate service board
- Work Highest Priority to Lowest Priority
- Work what is closest to breaking SLA to what is farthest from breaking SLA
- Work from Oldest to Newest
Time Entries
- All time accounted for from start to end of your scheduled day.
- No gaps, no overlaps, no duplicates.
- Personal, sick and vacation time is always offset with a Deduct (total hours = 0).
- Helpdesk, Remote, and other Rapid Resolution work are tracked in 5 minute increments.
- Field Service and other Onsite work are tracked in 15 minute increments.
- All time entries end in 0’s and 5’s.
- 5 minute time entry round up at the 3rd minute
- 15 minute time entry round up at the 8rd minute
- 5 and 15 minute entries can be intermingled in your day. Use what is most efficient.
- 5 and 15 minute rounding can NOT be used on the same time entry. Use one or the other.
- Time below 45 minutes is usually tracked in 5 minute increments.
- Time beyond 45 minutes is usually tracked in 15 minute increments.
- Travel time is entered against MPI unless we are actually going to bill the client for travel.
- Personal, sick and vacation time is always offset with a Deduct (total hours = 0).
Time Tracking Log Example
Rounding to 5 and 15 Minutes
Note: The light Blue highlighted entries represent entries that will result in a zero time entry.
Note: All entries are rounded using the 3rd and 8th minute and all entries that end up being 0 minutes time still get entered into CW because the notes have to be there.
Time Tracking in 5 & 15 minute increments
Rounding at the 3rd and 8th minutes
Tell us how can we improve this post?
Technician Roles and Responsibilities
Daily
Weekly
Monthly
Quarterly
Yearly
Tell us how can we improve this post?
Service Coordinator Duties and Tasks
Service Board Overview
Service Board Backlog
Time Sheet Approval Process (This is done every Friday)
Ticket Time Aging
Updating Budget
Steps to Dispatching / Scheduling
Credit Hold
Advance ticket priority based on age
Reoccurring Tickets
Follow up’s
Tell us how can we improve this post?
Service Coordinator Roles and Responsibilities
Daily
Weekly
Monthly
Quarterly
Yearly
Tell us how can we improve this post?
Service Manager Roles and Responsibilities
Daily
Weekly
Monthly
Quarterly
Yearly
Tell us how can we improve this post?
Service Board Management
General Notes
Acknowledging New Service Requests
Prioritizing Service Requests
Assigning and Scheduling Resources for Service Requests
Tell us how can we improve this post?
Service Request Path through the MPI Support System
General
Tell us how can we improve this post?
Service Request and Activity Work Flow
General Rules for Service Requests
Specific Rules for Service Requests
General Rules for Activities
- Activities in PSA are basically the Task or To-Do List for engineers.
- Activities do not violate the rule that all work is performed against and SR because the time will always be logged against some SR even if it is a Tech Admin SR.
- An Activity with a properly assigned priority is a way for the Service Coordinator or an Engineer to create a time slot to get a quantum of work done that otherwise would not be possible while still avoiding being interrupt drive.
Specific Rules for Activities
- Activities are worked from highest priority to lowest and from oldest to newest.
Tell us how can we improve this post?
Service Request and Activity Prioritization Guidelines
General
These are only guidelines for assigning priority to Service Request. As always for success there must be a human factor.
Note: We do not assign Priority 1 to SR’s, they assign themselves.
Priority 1 – Emergency Response
- More here…
Priority 2 – Quick Response
- More here…
Priority 3 – Normal Response
- More here…
Priority 4 – Scheduled Maintenance
- More here…
Activity Prioritization
High Priority
- Should be completed today before anything else but must be completed before close of business.
Example: Get your Supervisor Evaluation form from last week completed and turned in.
Medium Priority
- Needs to be done this week or the deadline is less than a week away.
Example: Get signed up for next week’s Exchange training before all spots close.
Low Priority
- Needs to be done but there is no specific deadline. Usually these items are more of a reminder.
Example: Research CA Solutions Protection product to see if it is a viable replacement for SAV.
Tell us how can we improve this post?
Alerts and Paging from MPI LOB’s
General
Setting the Service Request Paging in PSA
Setting Alerts in Continuum or LabTech
Tell us how can we improve this post?
Server Down During Off Hours Procedure
General
Tell us how can we improve this post?
Service Delivery Response Times
Guarantee of Response Time
Service Requests Response Time
Priority One or Server Down – After Hours
Voice Mail Response Time
Email Response Time
Tell us how can we improve this post?
Third Party Tech Support
HP Technical Support and Rules of Engagement
We are entitled to …
Here are the procedures for engaging XYZ for tech support.
Microsoft Technical Support and Rules of Engagement
We are entitled to …
Here are the procedures for engaging XYZ for tech support.
Paid (3rd Party) Technical Support and Rules of Engagement
Here are the procedures for engaging XYZ for tech support.
- Must get permission from…
- Contact will proceed as follows:
- First,
- Second,
- Third,
Tell us how can we improve this post?
Email and Their Etiquette
General
The Checking and Processing Email process outlined here is intended to be a time management helper. You do not need to follow it exactly but we do work on the assumption that everyone in the company follows the same general pattern for their day.
Rules
- You are to process your email a minimum of three times per day. Morning, Noon and late in the work day.
Everyone needs to check their email and appropriately act on the content in a timely manner. This is especially true of interoffice emails. Quite often we need answers from our fellow techs to be able to proceed and a quick response means the least time lost in momentum of the work at hand.
- DO NOT camp out on your inbox and DO NOT attend to any email that pops up.
Unless you are waiting on an email for the project, activity, SR or P1 that you are currently working on, only process email when you are between tasks and have set a side time to do it.
Anything else is interrupt driven and only causes you to waste time change tasks and distracts your focus.
Checking and Processing Email
Everyone at MPI should follow the same email retention practices in some form which is to create subfolders for each client whom you need to save an email for usually under the Inbox.
When you are checking your email do not waste time with email that is not business critical to your current project, SR, or Activity. Emails such as the latest MS Partners newsletter or the latest blast from some newsletter need to be read at a more appropriate time than in between clients, when getting started in the AM etc.
This process is very simple and allows anyone to clear their mail box quickly, efficiently, and not end up with 75 unread messages containing client requests for help or information aging away.
- For each and every email in the inbox, do only one of the following actions for every email:
- Reply to it and then Delete or Move the email to another folder
- Act on it immediately and then Delete or Move the email to another folder
- Forward it and then Delete or Move the email to another folder
- Create an SR and then Delete or Move the email to another folder
- Create an Activity and then Delete or Move the email to another folder
- Just delete it
- Always enter time or notes to any related SR immediately! If you do not do it now it will get lost.
- If there is nothing but 0 time entries during the entire time you spend checking your email enter your time into an Admin time entry.
Tell us how can we improve this post?
Phones, Voice Mail and Their Etiquette
Philosophy
It has been set out that this company will not be interrupt driven by phones of any type. It is considered rude to turn away from someone while in a conversation only to give all your attention to another. Many people today do this when their phone rings but we will not.
It is also recognized that anyone working on a task is distracted from that task the second they change their focus to the phone.
As stated in the company’s Modus Operandi:
It is assumed you prioritize your personal life in some organized fashion so that priority one items assign themselves and all others are planned. That is to say it is assumed that personal phone calls are during break times and if necessary in between service calls as not to interrupt the flow of work.
General Rules
- Technicians do not answer any phones at any time unless it is one of your co-workers or it is identifiable as being directly related to the Service Request or Activity you are working on at the time.
- Always set phones to lowest audible setting (or vibrate) when in any office including at MPI.
- Do not answer your desk or cell phone when you are in a meeting or giving someone else your attention.
- If you do not get vmail notifications on your cell phone, try to check voice mail every other hour on the hour for best response time. A simple rule is every odd hour of the day. This allows for a check after lunch and as one of the last things in the day. See the Technician Time Management Guidelines section for more information.
- No personal phone calls while on clients site ever!
Resetting the Interrupt
It is a fact that at one time or another you will find yourself on the phone with a client who needs attention but you cannot give it to them for one reason or another. The acceptable phrases to memorize and use are:
Common Answers to issues:
- I’m going to help you get a Service Request put into the system so that the service coordinator can get it prioritized and get someone on it as soon as possible.
- Even though you have reached me directly I am currently on another task / working with another client and can’t change my focus. I am going to help you … (see text above)
Voice Mail
- Desk Phones have preprogrammed voice mail greetings and menus. No changes are to be made.
- Desk phone voice mail passwords are blank and are to stay blank.
- All company cell phone passwords are to be the same as the last four digits of the phone number for that phone. No exceptions.
- All cell phone voice mails greetings must closely resemble the following statement and must contain the same information.
“Hello you have reached the voice mail for Joe Engineer. Please leave me a detailed message and I will return your call as soon as possible. If this is of an urgent nature please call 800-438-4357 Opt. 1 for our Helpdesk. Thank you.”
Helpdesk Call Script
Call Received –
- “MPI Helpdesk, this is _______________. How may I help you?”
- Identify that call is requesting any technical information or support, otherwise transfer them on.
- “Is this a new issue or is this related to an existing ticket?”
- “O.K, let me help you with that.”
New Ticket –
- “Please bear with me while I open a ticket for you so the issue can be properly tracked and resolved.”
- Use your personality to keep the customer feeling cared for.
- Be sure to relate your willingness to help them!
- While opening the ticket, you MUST ask the following questions if the information is not know:
- “What COMPANY are you calling from?”
- “What is your NAME?” Or “What is the NAME of the user this is ticket is for?”
- “What is the Site or location you are calling about?”
- If there is no phone number for the CONTACT in the PSA:
- “We don’t currently show any PHONE number in our system for you, can you please tell me the best number to reach you at?”
- If there is no email address for the CONTACT in the PSA:
- “We don’t currently show any EMAIL address for you in our system for you, can you please tell me the best number to reach you at?”
- “O.K. Now please give me the DETAILS of your issue.”
- Ask the right questions to get the complete Who, What, When, Where, Why and How of the issue! Ask for specific error messages, symptoms and outputs.
Note: Do NOT troubleshoot the issue now. That is not the role you are in right now. - Select the most descriptive sentence from the DETAILS you have typed up and enter it as the SUMMARY for the ticket.
Note: There is a 5 word minimum for Description! - Verify all CRITICAL SETTINGS for the ticket:
- Status: Set to “In Queue” for basic Helpdesk tickets. Set to “New” for Field Service.
- Source: Phone is the default
- Priority: Priority 4 is default
- Where: Remote is the Default
- Budget Hours: 0.5 hours max. for most any Helpdesk ticket.
0.12 hours min. (5 minutes)
- Ask the right questions to get the complete Who, What, When, Where, Why and How of the issue! Ask for specific error messages, symptoms and outputs.
- “I believe we have everything we need so let me read this back to you.”
- Read the DETAILED DESCRIPTION back to the contact and make any corrections necessary.
- “Ok, we have a ticket in the system and our Technical Support will be working on this as possible and they will contact you if they need anything.”
- “Have we addressed all of your current concerns for now?”
- “If there is anything else we can do for you please give us a call.”
- “Thank you and have a great day!”
Existing Ticket –
- “Please bear with me while I find the ticket for you and we will get it updated.”
- Use your personality to keep the customer feeling cared for.
- Be sure to relate your willingness to help them!
- When you find and open the ticket, you MUST ask the following questions if the information is not know:
- If there is no phone number for the CONTACT in the PSA:
- “We don’t currently show any PHONE number in our system for you, can you please tell me the best number to reach you at?”
- If there is no email address for the CONTACT in the PSA:
- “We don’t currently show any EMAIL address for you in our system for you, can you please tell me the address to reach you at?”
- If there is no phone number for the CONTACT in the PSA:
- Read the Detailed Description, Internal Notes, and Resolution and look for and read the WITNS.
- Communicate with the customer to get all new and useful information entered into the ticket.
- Read back to the customer for verification all critical details. (Password, email, phone number, etc.)
- Verify all CRITICAL SETTINGS for the ticket:
- Status: The Status may not need to change but in general, if it was “Waiting on Client” and the information is now complete, set to “In Queue” for Helpdesk or “Schedule This” for Field Service.
- Priority: Priority 4 is default – Do not re-set the priority to 4 but do evaluate if the Priority should change based on the new information.
- Where: Remote is the Default – Do not re-set the Where to remote but do evaluate if the Where should change based on the new information.
- Budget Hours: Evaluate if the Budget Hours should change based on the new information.
Note: Do not just change the Budget Hours because you think “this sounds like more work”. If in doubt, leave it for the Service Coordinator or the Tech who catches this ticket.
- “Ok, I have updated the ticket and our team will move forward with this updated information.”
- “Have we addressed all of your current concerns for now?”
- “If there is anything else we can do for you please give us a call.”
- “Thank you and have a great day!”
Tell us how can we improve this post?
Meetings and Training
General
At the beginning of every meeting someone is to be appointed to take notes and or record the meeting. All notes for the meeting are to be emailed out to all attending and all interested parties within 24 hours of the meeting. The 24 hour rule is important because it allows everyone to easily identify their action items and move on them. Also, it allows for immediate feedback on the notes if there are discrepancies or missing information. An example would be that Tom was to take ownership of the new report not Joanne.
Monday Morning (Stand Up) Meeting Agenda
- The agenda will adhere to the following order:
- Review of the On-Call Engineer for the next week
- Review of MPI Best Practices
- Review of accomplishments including new or revised documentation
- Any new business
- Review of the time left in the quarter to pass an exam and a review of each persons intended exam
Tuesday Morning Meeting Agenda
- The agenda will adhere to the following order:
- Review of the On Call Engineer for the next week
- Review of the time left in the quarter to pass an exam and a review of each persons intended exam
- Review of NTS Best Practices
- Review of Documentation
- New Business
Final Friday training
Tell us how can we improve this post?
Timelines and Deadlines
Monday Morning (Standup) Meetings
Monthly Maintenance
Quarterly Maintenance
Systems Patch Management
Tell us how can we improve this post?
MPI Approved Technician and Engineer Tools
Philosophy
By adopting a set list of MPI approved tools for use by Engineers and Technicians we establish a level of professionalism for ourselves, an accountability and reliability to our clients and an expectation of repeatability and reproducibility in our work. Training new technicians will also be easier as we are not just saying “Go get something that works and use it”. Instead we will say “This is our chosen tool for this, learn to use it correctly”.
Exceptions
Any tool produced, certified, or authorized by a major manufacturer does not necessarily need to undergo the MPI approval process but may be selected for testing to verify if it is to be considered best of breed (The best tool for the job). Best of breed tools are simply favored as first to try and will be higher on the list than tools that perform a similar function.
Approval Process for “tools”
- Propose the tool for use and demonstrate it at the Engineers meeting. (or whenever)
- Proposal must have complete source and pricing info etc.
- Any interested Engineer or Technical can test the tool on their own machines or workstations but no production servers or client machines until approved.
- The tool can be discussed and further evaluated at subsequent Engineers meetings.
- Key Questions:
- Does it do something better than what’s available via the Software vendors or Hardware Manufacturer? Microsoft, HP, Dell etc.
- Is the tool cost effective and reasonably affordable?
- Does it actually save time, energy, or effort?
- Is it sturdy enough for the use? Server class, Desktop class, Home use, etc.
- On passing basic scrutiny a proposed tool will move on to field testing within a stated range of systems or scenarios. We will not release it to the wild for use just anywhere yet.
- Engineer meeting reviews will continue.
- On passing field testing a tool become MPI Approved and will be listed here.
MPI Approved Tools
First tool
Second tool
Tell us how can we improve this post?
Hardware
General
Registering Warranties
Documenting
Storage
Upgrading
Tell us how can we improve this post?
Firmware
General
Activating and Registering
Licensing
Documenting
Storage
Upgrading
Tell us how can we improve this post?
Software
General
Activating and Registering
Licensing
Documenting
Storage
Upgrading
Tell us how can we improve this post?
System Defaults
General
This section should not grow too large as most items related to systems are actually Best Practices. Some entries here may also appear in the Best Practice document. For example: The default location for Engineer temp files is a best practice that should be imposed to everyone who works on any system we manage. However, we have specifically recorded our location standard here.
Default location for Engineer temp files
For all systems MPI uses, manages or works on there should be only one directory for all temporary files.
It is !Tech and should always be in the root of the boot drive.
If there is a large amount of data that could end up causing a drive to be low on space the !Tech directory should be cleaned out.
In general the !Tech directory should always be eligible to be purged unless someone is actively working on an issue, installation or at there is a ticket in the system and the files needed are waiting in the !Tech directory.
Password Defaults
The default password for all MPI local administrator accounts and for all managed services clients is to be set to: ?????????
It is assumed that unless specifically indicated, during any interaction on any machine, MPI or client, the password can and should be safely set to this default.
Tell us how can we improve this post?
How to Document a Process
General
All content requires collaboration in one form or another at one time or another. Most of the content created by this company will be created through collaboration over time. We must have a set flow for how we intend to collaborate and how we will ensure the completion of everything we start.
Properly Documented Process Components
- Complete Flow Chart describing how this thing or idea works.
- Quality Narrative for each cell of the Flow Chart
- Forms for Input
- Reports for Output
- Email Templates for Communications
- Checklists for Progress Measurement
The Flow of Collaboration
- Everything starts with an idea, need for documentation, standard, process, procedure, etc.
- A seed is planted by creating a container document for the content that will be created and placing it in the most appropriate location for all who will be involved.
- The location can be inside of an application such as a PSA, SharePoint, Wiki page, or a network drive.
- The container document should be the most appropriate for the content. E.g. Word, Excel, HTML Wiki, Visio, Etc.
- This does not dictate or restrict the distributed / distributable form of the document once complete. I.e. Word docs will usually be converted to PDF for release to clients.
- Everyone involved who needs access should be granted permissions and given a link to the container document and location.
- The actual container document should never be attached and distributed. It creates problems with version control and lost data. Use links to content.
- As content is created or updates all those involved (collaborators) should be updated or informed.
- There should be frequent stand up meetings to discuss additions, revisions, deprecations, and issues (bugs).
- Once everyone has had a chance to review the content and there are no more changes, there should be a call to release the content as official or accepted. We call this “Released to the wild”.
- There should be frequent releases of usable content versus waiting for things to be 100% complete. The rule of thumb should be; that if the content is released, will our process, work product, or client value be better off for having this content available without causing a slow down due to missing elements?
- Can the missing content be explained well enough and are there directions on how to proceed without the missing elements?
- Can the content be labeled or otherwise designated as MPI eyes only? I.e. Internal use only, not ready for release to clients.
- Can the content be labeled or otherwise designated as Beta or Work in Progress – Not to be relied upon yet?
Tell us how can we improve this post?
MPI Branding
General
We know that an important and often overlooked element of branding and marketing a company, products, or services is the standardization of company documents and emails. This is true for all documents in all forms internal and external not just the few that are forward facing such as the automated emails form our PSA or our weekly newsletter. We chose to have a superior level to which we brand every single iota of data that comes out of our company.
We know that companies who have everything from their business cards to their invoices to their email signatures and everything in between, consistently branded are recognized faster and further than those who do not. So when the whole point of branding is to make our company instantly recognizable and associated with our logo, name and other such iconic representation. WE always start with the most used core documents everyone in the company use every single day. Our rule of branding should be simply this: if a client or potential client will see it, it will have our name and / or logo on it.
Names
Names associated with this company, entity, product or service
- Manuel Palachuk International
- Fonts Used: Maiandra GD
- Font Size:
- “Manuel Palachuk” 28 point for all document First Page Headers
- “International” ” 18 point for all document First Page Headers
- “Manuel Palachuk International” 20 point for all document Second Page Headers
- Kerning: Auto
- Anti-Aliasing: Sharp
- Angle of Rotation: 0 degrees
- Font Color: #0000ff (R=0, G=0, B=255)
- Background/Fill Color: White
- Fade Information: no fade
- Shading information: No shading
- Lighting Information: No special lighting
- Examples of Acceptable Use: Any size is acceptable provided the aspect ratio is not changed.
Manuel Palachuk International
-
- Font Files:
List all files including their complete path
F:\Standards and Procedures\Fonts\ - Trade and Service Mark:
- Font Files:
2010 – Registered with U.S. Patent and Trademark Office
CLASS 35 – Advertising; business management; business administration; office functions.
2010 – Registered with Florida Department of State
CLASS 35 – Advertising; business management; business administration; office functions.
Logos
Logos associated with this company, entity, product or service
- Manuel Palachuk International Company Logo
- Font Used: None
- Font Size: N/A
- Kerning: N/A
- Anti-Aliasing: N/A
- Angle of Rotation: 0 degrees
- Font Color: R=0, B=255, G=0, #0000ff
- Background/Fill Color: White
- Fade Information: no fade
- Shading information: No shading
- Lighting Information: No special lighting
- Application used to create and maintain this logo: Corel PaintShop Pro x4
- Examples of Acceptable Use: Any Size is acceptable provided the aspect ratio is not changed.
- Logo Description:
Manuel Palachuk Initials emblazoned on a compass rose.
Original logo designed by Manuel Palachuk
Colors used:
MP Initials: #0000ff (R=000, G=000, B=255)
Compass Shading: #d7d7ff (R=215, G=215, B=255) - Trade and Service Mark:
2010 – Registered with U.S. Patent and Trademark Office
CLASS 35 – Advertising; business management; business administration; office functions.
2010 – Registered with Florida Department of State
CLASS 35 – Advertising; business management; business administration; office functions. - Graphic Files:
List all files including their complete path
F:\Standards and Procedures\Graphics\Company Logo’s\MPI Company Logo.pspimage
F:\Standards and Procedures\Graphics\Company Logo’s\MPI Company Logo.jpg
F:\Standards and Procedures\Graphics\Company Logo’s\MPI Company Logo.png
F:\Standards and Procedures\Graphics\Company Logo’s\MPI Company Logo.ico
Tell us how can we improve this post?
Knowledge Management
General
Knowledge Management (KM) is only component of Information Management. A robust Knowledge Management system supports the Information Management system and addresses specific needs to put Information into action. Information is simply data, but Knowledge is Information in action.
To be a learning company and to actuate information in the most useful way we must master Knowledge Management. It is also imperative that we master KM not only for ourselves but for our clients. As we mature, so do our clients and we must be in the lead helping them get to the next level.
Our Knowledge Management system has many components some of which are listed here:
- Share Site – Public and Private content, resources and collaboration
- Website – Portals and Libraries
- File System – File Structure or Shared Files
Share Site Structure
Sites
- Home
- Components
- Links
- Calendar
- Company Images
- Activity (Notices)
- File Share
- Folder Structure
- Components
- Management
- Components
- Links
- Calendar
- Company Images
- Activity (Notices)
- File Share
- Folder Structure
- Components
- Human Resources
- Components
- Links
- Calendar
- Company Images
- Activity (Notices)
- File Share
- Folder Structure
- Employee Information
- Employee Records
- Folder Structure
- Components
- Sales
- Components
- Links
- Calendar
- Sales Images
- Activity (Notices)
- File Share
- Folder Structure
- Components
- Marketing
- Components
- Links
- Calendar
- Marketing Images
- Activity (Notices)
- File Share
- Folder Structure
- Components
- Service Delivery
- Components
- Links
- Calendar
- Service Delivery Images
- Activity (Notices)
- File Share
- Folder Structure
- Getting To The Next Level
- Email Templates
- Document Templates
- Standards and Procedures
- Best Practices
- How-To’s
- Active Clients
- Archived Clients
- Work in Progress
- Folder Structure
- Components
Share Site Management
Share Site General Rules of Use
Attachments
It is MPI policy to never attach any file or content to any form of correspondence or transferring any file or content using any device unless it cannot be reached by the recipient under any means. Doing so creates issues with document revisions and document management. Wherever possible content should be made available to the client, partner, provider, etc. using permissions based solution such as a special public facing site and folder.
Linking and Embedding
It is MPI policy that we always use links to files and content wherever possible. We will also take care to use clean and familiar names for the links versus simply pasting the link into the message or content.
E.g. we will do this: Get the File Here
Not this: http://www.manuelpalachuk.com/resources/free-stuff/culture-and-compass-webinar
Further, we will always take care to select New Window for the Target where a website is the link.
E.g. www.manuelpalachuk.com
Referencing Content
Whenever referencing any content on the Share Site that is not a specific link the following format should be used consistently.
Example:
MPI Share > Marketing > Files Share > The Document Your After
Website Structure
Website Management
File System Structure
File System Management
Standard Document Templates
All MPI branded document templates are to be stored in the Share Site in the top level Document Template folder. All of the Document Templates are to be set to Read Only. No other files should be stored in the Document Template folder.
Standard Email Templates
General
All MPI Email Templates are to be stored in the Share Site in the top level Email Templates folder. All of the Email Templates are to be set to Read Only. No other files should be stored in the Email Templates folder.
Formats
Files stored in the Email Templates folder should be of only two types: .msg or .oft.
- .oft files are Microsoft Email Template files. When they are opened from a machine that has any Outlook compatible application the email will look exactly as designed but will auto-populate the signature of the Outlook user if it has been configured.
- .msg files are Microsoft Email Message files. When they are opened from a machine that has any Outlook compatible application the email will look exactly as designed and will not auto-populate a signature.
Which Format To Use
- When the email templates is built for a specific use by anyone in the company and require a specific email signature such as:
Reminder about upcoming Service Call or Meeting
More text
More text
Yours truly,
The Service Team
Phone: 561-577-1979
Support@ManuelPalachuk.com
- When the email templates is built for general use by anyone in the company and require the email signature for the user who is sending the email such as:
A follow up to our conversation regarding your service
More text
More text
Sincerely,
Manuel Palachuk
Phone: 561-577-1979
Manuel@Palachuk.com
Written Documentation
When updating any written document do not scratch out or otherwise obscure the original entry with anything other than a single line through the middle of the entry. The intent is to not remove from eternal history the entry but to mark it as outdated, updated, inaccurate, or no longer relevant.
Tell us how can we improve this post?
Information Management
According to Wikipedia, Information management (IM) is the collection and management of information from one or more sources and the distribution of that information to one or more audiences. This sometimes involves those who have a stake in, or a right to that information. Management means the organization of and control over the structure, processing and delivery of information.
Information is data and it comes from many sources. Some is of great use to us and some is of little use but all data must be managed.
- Capture
- Store
- Preserve
- Deliver
Tell us how can we improve this post?
Modus Operandi
Continuous Incremental Improvement
This document represents the commitment of this company to continuous incremental improvement and the dedication to holding itself to a measurable standard. Having a core philosophy of working to standards and documenting everything is what it takes to be a learning company and to build a strong Knowledgebase. This means training of new employees is quicker, rework is reduced and it demonstrates a very professional appearance to clients and competitors. One of MPI’ primary goals are to continuously and incrementally improve its methods, practices and procedures through ownership of process and continuous useful feedback. It should be the primary rule that every time we touch a process we improve it.
Vision, Mission, Values
Our Vision
A solid fabric of small businesses around the world, woven of strong culture and compass, with a dedication to quality products and services. (This is mine – Don’t steal it!)
Our Mission
To take you and your business to the next level. And I have the blueprint to do it! (This is mine – Don’t steal it!)
Our Values
Integrity, Compassion, Passion, Knowledge (study) , Experience (practice), Collaboration
What We Do (“Who” and “Do What” statement)
MPI designs, builds and supports Microsoft networks. (Or something like that…)
Our Tagline
I’m the coach that will take you to the gym, not just send you there! (This is mine – Don’t steal it!)
Our Mantra
Is this a profitable hour for MPI? Are we working in real time and on task? (Or something like that…)
Work Ethics and Core Beliefs
- We believe in continuous incremental improvement in all of our policies, standards, procedures, or best practices to ensure a high quality of product and service delivery.
- The privacy and confidentiality of MPI’s and our client’s information (Knowledge) is to be respected at all times. The assumption is that it is proprietary and coveted and is not to be shared, no matter how common it may seem.
- In general, when things need doing in the office or for the business at large, we pitch in and help out whether it is in our job description, position agreement or not. We work together. There is no task that needs doing that any of us are above.
- When something doesn’t work we bring it to an open discussion to evaluate it, think on it, and try something new. We will repeat as necessary until we find something that works better. We do not just keep doing things that do not work or do not work well.
- We strive to hire the smartest talent we can get our hands on and therefore whenever anyone has an idea for improving things, we speak up! New ideas and ingenuity are encouraged and rewarded.
- When we’re getting down to business, we get down to business. There is a time for work and a time for play and we will do our best to know the difference.
- We dislike re-work and duplicate work. We strive to drive it out of our systems at every opportunity. Complete the work the first time around and close the loop.
- We believe the most efficient way to work is to focus on one thing completely and when done or at a stopping point, we update our notes and documentation, log our time, and then move swiftly and cleanly on to the next task. Working and tracking time in real-time or as close to it as possible.
- The client you are servicing right now is the most important client at that moment. Give that person or people your full undivided, uninterrupted attention and effort.
- We only change focus or allow distraction to the one thing we are doing at the moment, if that interruption or distraction is directly related to the success or completion of the task at hand.
- We know that almost any potential distraction or interruption can wait or be handled by someone else if the issue is correctly recorded in the PSA for others to access. That is to say; if the PSA is up to date and the Issue is a Quality issue with accurate Status, Notes, WITNS, etc. anyone else with the correct technical ability can take over that Issue or help it move forward toward resolution. It does not have to cause us to lose focus or redirect.
- We believe in and strive to be a Learning Company and therefore we document everything. This also means we get as much information as possible as early as possible for issues and problems. We strive to get all the information the first time around and properly document it in the approved or appropriate location.
- Our work is always performed according to applicable state and federal laws, regulations, and the like. We do not break the law for ourselves, our vendors, or our clients. – Ever.
- To the extent possible our processes, procedures, and best practices for how we work will be systematized and documented. How we do things is MPI’s secret recipe and is not to be shared with anyone outside our company.
- For anything where we have regulations, policies, standards, procedures, or best practices, our work will be performed to those call outs.
- In areas where no regulations, policies, standards, procedures, or best practices exist, best judgment and effort will prevail but we will create the required regulations, policies, standards, procedures, or best practices from the work product and experience we gain in the “doing”.
- When in doubt about best judgment we will always reach out to our team and ask someone. Our efforts must always support the belief in continuous improvement in how we accomplish our mission more reliably and efficiently for as many clients as possible.
And when we do bring them up, we all agree to throw darts but not rocks. - We strive for closed loop communications with our team, partners, vendors, and clients. We will always respond to each other, our partners, providers, vendors, and clients (no matter what the medium) in a timely, appropriate, professional, and courteous fashion. We will always follow up with each other, our partners, providers, vendors, and clients with the best reasonable effort we are capable of. If someone has reasonably requested a status update because they have not heard back from us, we have failed them. The ball is always to be in their court.
Client Relations
Our customers and our interactions with them is the most critical portion of our business. Here are a few guidelines for consideration when working with our clients:
- We must always strive to maintain a professional appearance and attitude.
- We must always listen to the client and try to not just hear what they are saying but attempt to read between the lines.
- Try not to let the client see when you’re frustrated. Not because we do not want to show emotion, but because we do not want the client to feel they are the cause of our stress or somehow a burden to us.
- Get to know what type of client and end user you are dealing with. Some clients don’t have time or just don’t care to have casual conversation. They just want you to get the job done as quickly as possible without interrupting them. Some clients enjoy casual conversation. Both are OK.
- Communication with the client is essential. Keep the client informed of what you are doing at all times using closed loop communications.
Partners, Providers, Vendors
Our partners, providers, vendors and our interactions with them is the second most critical portion of our business. Here are a few guidelines for consideration when working with our clients:
- We must always strive to maintain a professional appearance and attitude.
- More stuff goes here…
Tell us how can we improve this post?
Creating and Updating Service Requests and Activities
General Notes
Our goal is to have all work assigned by and all resources scheduled by the Service Coordinator. Since we also strive to not be interrupt-driven, the idea is to enter new SR’s as a small function of our everyday work and then leave them for the Service Coordinator to sort out. This is why we always leave a new SR’s status as New. The SC will get an email within minutes of its creation and will be able to acknowledge and prioritize accordingly.
Note that the steps outlined here systematically go through the fields on the SR page starting with the upper left side then upper right and then to the lower section skipping over fields that are either auto filled or not used.
Service Request Status Definitions
General Notes
There is no Highlighting for this section because the entire section must be read and adopted as a whole before implementation. It is highly recommended that this section be read and implemented as is for a starting point and adjusted after implementation.
- New
- This is the default status assigned to all new Service Tickets.
- When a ticket is set to this status the PSA will send an email to the client contact indicated in the ticket informing them that we have in fact received their requests in our PSA.
- When a ticket is set to this status, the PSA will send an email to the MPI Service Coordinator informing him that a new Ticket has been entered.
- The ticket will be reviewed by the appropriate service team member according to and within the time specified in the MPI Standards and Procedures.
- Once a service team member has reviewed the new ticket its status will be changed from New to Queued any appropriate status further down the list. It will never have the status of New again.
- MPI clients cannot change any existing ticket to this status.
- No Time Entries can be logged against a ticket in this status.
- New (Approved)
Note: This status is not available or used unless there are clients who require that tickets be approved before they are worked. Use of this status should be avoided at all costs. If you are running an MSP, you should not need this status or the Waiting Approval.Use of this Status and the accompanying status of Waiting Approval require a special workflow rules. These workflow rules control the behavior of the ticket statuses based on the submitting client and they facilitate the ability for the client to respond to the Waiting Approval email to Approve or Close the new ticket.- When a ticket is set to this status the PSA will send an email to the client contact indicated in the ticket, informing them that their issue and ticket have been approved.
- When a ticket is set to this status, the PSA will send an email to the MPI Service Coordinator informing him that the issue and ticket have been approved.
- The ticket will be reviewed by the appropriate service team member according to and within the time specified in the MPI Standards and Procedures.
- Once a service team member has reviewed the new ticket its status will be changed from New (Approved) to Queued (for Helpdesk board) or Escalate (for Field Service board) or any appropriate status further down the list. It will never have the status of New (Approved) again.
- Only specific MPI client contacts can change an existing ticket to this status.
- No Time Entries can be logged against a ticket in this status.
- Customer Responded
Note: Only used for Autotask, not ConnectWise- When a customer responds to a ticket via email, the ticket is set to this status. The PSA will send an email to the Service Coordinator (and primary resource if applicable) informing them that a new customer ticket response has been received.
- The new response will be reviewed by an appropriate service team member according to and within the time specified in the MPI Standards and Procedures.
- Once a service team member has reviewed the new ticket its status will be changed from Customer Responded to the appropriate status. It will not stay in this status.
- MPI clients cannot change any existing ticket to this status.
- No Time Entries can be logged against a ticket in this status.
- Waiting Approval
Note: This status is not available or used unless there are clients who require that tickets be approved before they are worked. Use of this status should be avoided at all costs. If you are running an MSP, you should not need this status or the New (Approved).Use of this Status and the accompanying status of Waiting Approval require a special workflow rules. These workflow rules control the behavior of the ticket statuses based on the submitting client and they facilitate the ability for the client to respond to the Waiting Approval email to Approve or Close the new ticket.- When a ticket is received for a client that requires approval a workflow rule will change the status from New to Waiting Approval.
- When a ticket is set to this status the PSA will send an email to the client contact indicated in the ticket, informing them that their issue and ticket must be approved before we can touch it.
- When a ticket is set to this status the PSA will send an email to the client technical contact that is authorized to approve work, informing them of the issue and ticket and requiring them to either Approve or Close the issue.
- Once the client has approved the ticket by responding to the email sent to them by the PSA or via the Client Portal, its status will be changed to New (Approved) and moved back to the Helpdesk queue (and will be processed as indicated in New (Approved).
- MPI clients cannot change any existing ticket to this status.
- MPI Service Team members are never to change any ticket to this status. The client must do so by responding to the automated email sent out by the PSA or via the Client Portal.
- No Time Entries can be logged against a ticket in this status.
- Queued
- Ticket is ready to be worked on. Not being worked on! But Ready.
- MPI clients cannot change any existing ticket to this status.
- No Time Entries can be logged against a ticket in this status.
- Scheduled
- This status indicates that resources have been scheduled for this ticket.
- MPI clients cannot change any existing ticket to this status.
- No Time Entries can be logged against a ticket in this status.
- In Progress
- This status indicates that work is currently being done on the ticket and progress is being made.
- When a ticket is set to this status the PSA will send an email to the client contact indicated in the ticket informing them that the status has changed.
Note: Optional - MPI clients cannot change any existing ticket to this status.
- Escalate
- When a ticket is set to this status the PSA will send a notification to the Service Coordinator (and Service Manager?) alerting them of the new status.
- Using this status requires a WITNS such as: WITNS: Need to consult with senior tech for suggestions.
- The WITNS: Requesting escalation can be an internal or an open note but if it is an internal note there must be some WITNS in the open notes for the client to see and understand. E.g. WITNS: Requesting escalation due to complexity of this issue.
- The original resource is responsible to see to it that this issue is follow-up on and resolve.
- The service Coordinator is responsible for ensuring the resources required are directed to this issue.
- MPI clients cannot change any existing ticket to this status.
- No Time Entries can be logged against a ticket in this status.
- Waiting Results
- The ticket is waiting for some event to happen (usually on the customer’s system) that needs to be checked later i.e. If you started a virus scan and are checking the progress later, or anything that requires data collection for a period of time.
- This status usually does not involve any human interaction with the client. In contrast to Follow Up.
- This requires that you create a Task or To-Do for yourself that is window of time within a reasonable timeframe relative to the original creation time.
Note: The subject of the Task or To-Do should simply be Check on Results and it should be at least a 15 min event. - MPI clients cannot change any existing ticket to this status.
- No Time Entries can be logged against a ticket in this status.
- Waiting on Materials
- This status indicates that work cannot proceed until certain software, hardware, firmware or other materials are acquired.
- The WITNS or the most recent Time Entry will contain all relevant notes indicating what item is being waited on.
- There may (and should) be an associated Opportunity in the PSA for the required materials.
- When a ticket is set to this status the PSA will send an email to the client contact indicated in the ticket informing them that the status has changed.
- MPI clients cannot change any existing ticket to this status.
- No Time Entries can be logged against a ticket in this status.
- Waiting Customer
- This status indicates that the MPI service team is waiting for input, response or work product from the client.
- The WITNS section or the most recent Time Entry will contain all relevant notes indicating what is being waited on.
- When a ticket is set to this status the PSA will send an email to the client to inform them that their participation is required. It will also indicate that this issue will be automatically closed within 7 days of we do not hear back from them.
- Waiting on response reminder emails are automatically sent at 1 business day, 3 business days, and 6 business days.
- If no response is made within a total of 7 business days the ticket will be closed and a final notification sent to the customer.
- MPI clients cannot change any existing ticket to this status.
- No Time Entries can be logged against a ticket in this status.
- Waiting 3rd Party
- This status indicates that the MPI service team is waiting for input, response or work product from someone other than the client. I.e. Waiting on ISP, Copier tech, etc.
- The WITNS or the most recent Time Entry will contain all relevant notes indicating what is being waited on.
- When a ticket is set to this status the PSA will send an email to the client contact indicated in the ticket informing them that the status has changed.
Note: Not yet implemented – Or Verified! - MPI clients cannot change any existing ticket to this status.
- Technician needs to create a To-Do action type follow-up depending on the priority example the vendor tells you they will get back to you in 2 days you will create the Task or To-Do 2 days out.
- MPI clients cannot change any existing ticket to this status.
- No Time Entries can be logged against a ticket in this status.
- Pending Research
- This status indicates that MPI service team has to research the problem before we can continue.
- The Internal note section or the most recent Time Entry will contain all relevant notes indicating what is being waited on.
- MPI clients cannot change any existing ticket to this status
- There must be a defined amount of time budgeted for the research for this issue
- The WITNS must clearly define the resources and time frame for the research.
- Service coordinator will coordinate the technician and resources accordingly.
- MPI clients cannot change any existing ticket to this status.
- No Time Entries can be logged against a ticket in this status.
- Follow Up
- This status indicates that MPI service team has to follow-up with the client to make sure the steps taken has resolved the problem.
- This status usually involves a human interaction with the client. In contrast to Waiting on Results.
- This requires that you create a Task or To-Do for yourself that is window of time within a reasonable timeframe relative to the original creation time.
Note: The subject of the Task or To-Do should simply be: Follow-Up. - Examples of Follow Up: We removed a virus, we installed an update or patch but the problem is very intermittent. The client who uses that machine must verify for us that it has been resolved.
- No Time Entries can be logged against a ticket in this status.
- Schedule This
- This status indicates that work for this ticket is ready to be Scheduled or Re-Scheduled. I.e. the parts have arrived, etc.
- When a ticket is set to this status the PSA will send an email to the MPI Service Coordinator informing them that the status has changed.
- MPI clients cannot change any existing ticket to this status.
- No Time Entries can be logged against a ticket in this status.
- On Hold
- This status indicates that the MPI Service Coordinator has called for a hold on any work to this ticket. No one is to perform ANY work on this ticket. Intervention and or interaction are required by the Service Manager, Service Coordinator, or other higher levels.
- The WITNS or the most recent Time Entry will contain all relevant notes indicating what is being waited on.
- When a ticket is set to this status the PSA will send an email to the client primary contact and the client contact indicated in the ticket informing them that the status has changed.
Note: Not yet implemented – Or Verified! - Only the Service Coordinator or Service Manager should process on HOLD Tickets.
- MPI clients cannot change any existing ticket to this status.
- No Time Entries can be logged against a ticket in this status.
- Completed
- This status indicates that one or more of the following conditions have been met:
- All Time Entries and notes are up to date
- All work outlined or required has been completed
- The issue outlined in the ticket has been resolved or sufficiently alleviated
- The client has not responded to requests about this ticket within the required timeframe
- When a ticket is set to this status the PSA will send an email to the client contact indicated in the ticket informing them that the ticket has been resolved and that the status has changed.
Note: Optional - MPI clients cannot change any existing ticket to this status.
- No Time Entries can be logged against a ticket in this status.
- This status indicates that one or more of the following conditions have been met:
- Closed
- This status indicates that the MPI Service Manager has performed a final quality control and believes all is in order.
- The Service Manager has reviewed the:
- Ticket issue, Notes, and Resolution
- All time entries and Billing
- NTS clients cannot change any existing SR to this status.
- No Time Entries can be logged against an SR in this status.
Defining a Quality Service Request
A Quality Ticket has all of the following correctly verified and set:
- Correct account name.
- Correct contact. If that user is not in the system, add them.
- Ticket source – How was this ticket generated?
- A call in?
- A Monitor alert?
- The portal?
- Sent an email?
- Shoulder tap – Entered for client while onsite?
- Ticket title with at least 5 words.
- Ticket description has a robust narrative (user story). The more information, the better we can prepare our self for what to expect when we tackle the issue.
- Correct ticket status.
- Correct Priority.
- Realistic due date and time. Only if required.
- Most work should be scheduled 3 days out.
- Correct SLA for that client.
- Realistic time estimate.
Pay attention to Helpdesk max time limits - Assign to the correct queue.
- Assign a primary resource and role.
If necessary, assign secondary resources to the ticket. - Correct work type according the SLA.
If you have verified all of the fields above, we should now have a quality ticket that we can all understand and work on without any questions.
Creating a New Service Request
10 Steps to Success Theory
- MPI has a standard format that is to be used when creating a new Service Request.
- A serious effort must be made to list 10 Steps to Success for every new Service Request
Updating Service Requests
Time Entry Notes:
- MPI has a standard format that is to be used when entering time notes on any ticket. This uniformity of notes allows for a repeatable and reproducible experience for both staff and customers when reviewing time
- The note format is:
Format of technician notes entry
WITNS:
– If the ticket is not completed, you must determine and note What Is The Next Step
- Example of a complete entry would be:
Example of technician notes entry
WITNS:
– Waiting for supervisor’s response on Word Perfect.
Creating and Assigning Activities
Updating Activities
Tell us how can we improve this post?
Time Stamp, Date Stamp, and Version
General
Use of Date Stamps for simple version control is acceptable for documents that change fast and frequently and are not under strict release control. Although Time Stamps can be used in Document Contents and in the Filename, they should be reserved for fast-changing work or in very specific high-scrutiny scenarios. Automated systems commonly use Time Stamps for specific situations and they are supported by very tightly managed algorithms. Humans, however, will have trouble with not only getting the initial formatting for the Time Stamp creation correct, but also in the interpretation of it.
For any content under strict revision control, such as Company Policies and Standards, Procedures, Document, Client Contracts and Agreements, or Client-facing detailed Checklists, a proper Version Notation control should be used in the Document Content or in the Filename. Please see the appropriate section below for details on using the Date and Time Stamps or Version Notation.
Date Stamps, Time Stamps and Version Notation each have their own purpose and appropriate use. Combining the use of Stamps and Version Notation for the same content can end up being redundant and confusing if not done properly. The straight line, general method for application should be to use either Stamps or Version Notation, not both. If both are used, it should be with a clear understanding of why and for how long both will be maintained.
For example: It makes sense to use a Date Stamp for a document being collaborated on by many people as it is brought from Version 3.0 to 3.1. The document will have an internal notation of the current version on the first page of the document. Once version 3.1 is released with the Version Notation updated on page one, the Date Stamp would be stripped off the filename and the document released to the wild.
This document does not attempt to discuss or consider version control available or imposed by document management and collaboration systems such as Alfresco, SharePoint, LifeRay, GitHub, etc. If any of these systems are used, their effect on your Date Stamps, Time Stamps, and Version Notation must not only be considered, but if incorporated or relied upon in any way, must also be documented in the appropriate or relevant standards and procedures document.
The default format used for date and time begin with and stem from the International standard ISO 8601 (Representation of dates and times) defines unambiguous written all-numeric big-endian format for dates, such as 1999-12-31 for 31 December 1999, and time, such as 23:59:58 for 23 hours, 59 minutes, and 58 seconds.
Date Stamp
Date Stamps can be used in the Document Content and in the Filename, so long as there is a standardized method adopted and called out in the Company Standards and Procedures document.
Documents where it is acceptable to use a Date Stamp as the simple version include basic checklists, client data files, and marketing material being developed.
General Guidelines
• All Date Stamps used in Filenames should be in the form YYYYMMDD, e.g. 20141213
• The stamp can also be presented with dashes or periods between the Year, Month and Day: YYYY-MM-DD or YYYY.MM.DD.
e.g. 2014-12-13 or 2014.12.13
• It is not acceptable to separate any portion of the Date Stamp with spaces.
• If only the Year and Month are being used, it would look like this:
201412 or 2014-12 or 2014.12
• When adding a Date Stamp to a Filename, it should be appended to the end of the name so as not to obscure the actual document name.
e.g. FileName-2014.12.13.docx
• The Date Stamp and the Filename can be separated by a space, dash, or space-space as long as they are separated by some character.
e.g. Filename-2014.12.13.docx or Filename 2014.12.13.docx or
Filename – 2014.12.13.docx
• If you have multiple files created on a given day (for example, iterations of a configuration file), you may add a letter(s), such as:
20141213a
20141213b
20141213c
20141213aa
20141213bb
• You should never abbreviate the year to only YY or two digits, e.g. 141213
• All Date Stamps used in Document Content should follow the standard writing and grammar rules for your country or region.
E.g. 13 December 2014 or December 13, 2014, etc.
Adding Time Stamps to Date Stamps
• Refer to the Time Stamp section below for specific rules about Time Stamps.
• Date Stamps can be combined with Time Stamps if necessary, but should only be used if absolutely necessary as it can quickly become cumbersome and confusing.
• For Filenames, this is usually left to automated systems that create files, such as graphic or audio file management systems, not human-created and handled files.
• For Filenames or in Document Content, if the Time Stamps are added to Date Stamps, follow the Time Stamp guidelines in the Time Stamp section below and the specified Time Stamp Company Standard when doing so.
Time Stamp
Time Stamps can be used so long as there is a standardized method adopted and called out in the Company Standards and Procedures document. The standard must including the clear details of the unique scenarios in which it is acceptable to use Time Stamps.
Time Stamps should rarely be used without Date Stamps. If there is no information indicating the date of the document (in the filename or the content), the Time Stamp will likely be of little use. And relying on the file management structure creation or touch date is not universally standardized, so it will be of no help.
Documents where it is acceptable to use a Time Stamp as the simple version include media flies (such as graphics, audios, videos), log entries or log files, and in/on most documents related to security or quality control.
Note: Time stamps in the format outlined below are not to be used in an actual filename as it would create an “illegal” filename for any OS. The only valid option would be to substitute the full colon symbol for an acceptable character.
General Guidelines
• All Time stamps used in filenames or technical content will be in the 24-hour Military format: HH:MM
E.g. 21:40
The Military format is used because there is no confusion about AM or PM and it is more efficient.
• All Time stamps used in client-facing document content will be in the 12-hour UTC format: HH:MMAM/PM UTC for easily human readable, international format.
E.g. 9:40PM EST
• The Time stamps should always include both the Hour and the Minute at a minimum.
• The default should be a conservative Time stamp with only Hours and Minutes.
• If you have multiple files at the same time (for example, iterations of a configuration file), you might add a letter, such as:
21:40a
21:40b
• The Time stamp can include Seconds by simply adding SS to the end of the stamp, such as:
21:40:55
Adding Time Stamps to Date Stamps
• Refer to the Date Stamp section above for specific rules about Date Stamps.
• When a Time Stamp is added to a Date Stamp in the filename, it should be appended following a single dash “-” to the end of the date stamp.
e.g. Filename with Date of 2014, December 13th @ 9:40pm => Filename-2014.12.13-21.40
With seconds added: Filename-2014.12.13-21.40.55
Version Notation
Version information is distinctly different from Date or Time stamping in that it has embedded major and minor revision information, not just the chronology information. Correct Version notation is intended for content under strict revision control, such as the Company Standards and Procedures Document, Client Contracts and Agreements, or Client-facing detailed Checklists.
Version Notation should not be used for fast-changing content as it would be cumbersome to maintain and you would likely find yourself at version 1,000,00.1 in a very short time.
While Version Notation can, as a general rule, contain or include any part of a Date Stamp or Time Stamp, it should be derived relative to the maturity of the content being tracked. To state it another way, a good Version notation should clearly indicate the maturity of the service or product in a simple way. Conversely, sometimes the Date or Time Stamp is the best measure of the maturity or the state of a given thing. The use of Date and Time Stamps is called out below to allow for cases where it will be used in a Version Notation.
Version information can be embedded in the name of the document or it can be inside the document.
All version information entries should follow the guidelines detailed below.
General Guidelines
• The Scale for the Version Notation for a given document, service, process, product, etc. must be called out and documented somewhere if it is not obviously tied to a Date or Time Stamp.
• The documentation of the Scale for the Version Notation of a given thing may be in any of the following locations:
In the actual document itself
In a readme.txt file in the document folder (or with the file group)
In a Standards and Procedures document
In a wiki page, forum entry, or other such collaboration site element
• Numbered Version hierarchy should always be separated by a period.
e.g. Where the major version is 3 and minor version is 0 (zero) => Version 3.0
• Mixed metadata Version hierarchy may use a dash “-” with or without spaces.
E.g. Where the major version is 3 and minor version is Revision 4
=> Version 3 – Revision 4
• Where possible and reasonable, the Version field should be denoted by one of these three nomenclatures:
The word: Version – e.g. Version 3.0
The abbreviation: Ver. – e.g. Ver. 3.0
The letter or entry: V. (Capital letter V with a single period.) – E.g. V. 3.0
• Any words used in the Version Notation may be abbreviated in any fashion desired.
E.g. Version 3 – Revision 3 => Ver. 3 – Rev. 4, V.3 – R4, etc.
• The Version metadata should be a simple-to-follow system, such as:
Major Version + Minor Version (Preferred)
Simple Numbers
Simple Letters
Numbers + Letters
Simple Date
Simple Time
Date + Time
Date + Number
Other logical combinations
• Unless absolutely necessary, the Version Notation should not be excessive or confusing in that it uses more than two nomenclatures.
I.e. Date + Time + Letter, as in: Version 2014.12.13.21.40a
Or
Date + Major Version + Minor Version, as in: Version 2014.12.13.3.0
• When a Version is embedded into a filename, it should be stripped down following the steps below:
Note: The only required step is the first one, removal of spaces. All other steps may be skipped.
1) Remove all spaces
E.g. Version 3.0 Rev. 4 => Version3.0Rev.4
2) Separate metadata using the most appropriate character (typically a period or dash) if there is any chance of confusion or ambiguity, or if it is simply desired for aesthetics.
e.g. Version3.0Rev.4 => Version3.0-Rev.4
3) Abbreviate any wording desired (try to keep it human understandable).
e.g. Ver.3.0-Rev.4 or V3.0-R4, etc.
• When entering a Version Notation into a document, it should be:
◦ Placed on the earliest possible relevant page of the document. I.e. Not on the company logo page, but on the Table of Contents Page or the Title page.
◦ Placed on the topmost line on the right side of the page. See the Version Notation of this document for an example.
• When referring to a Version Notation in writings, it should never be abbreviated or stripped down to avoid confusion or misunderstandings, or ambiguity.
Adding Date Stamps or Time Stamps
• Refer to the Date Stamp and Time Stamp sections above for specific rules about those Stamps.
Tell us how can we improve this post?
Labeling, Tagging, Identifying, Naming
General
The intent is to always label equipment, software packages, folders, etc. for easy identification especially used items. Used items that are not labeled will always cost time and energy in rework.
Labeling Equipment
Something goes here about using Brother Label machines
Something about custom equipment labels.
Tagging Equipment
A white toe tag should be used for all hardware that is not in the box. This excludes small consumable items such as net cables, power chords, etc. However, if the cable is not as expected such as a net crossover it should be tagged.
The label should indicate (at a minimum) the following:
• Where or What is it from?
• Current Status (Dead, Test, Do Not Use, Return to client)
• Date removed or updated status date.
• Technician(s) name
• Details on back
Asset or Resource Identification
Something about client provided asset tags
Something about MPI supplied asset or Identification tags (Managed/Unmanaged, Purchase Date, Etc.)
Software and Application Package Management
Machine Naming Convention
Servers
Workstations
Laptops
Printers
Tell us how can we improve this post?
Agile Service Delivery Implementation
TOC Example
Description of this text
This is the seed of the Agile Service Delivery Knowledge base
Heading 1
- This is a test of the Help & Support document sample text
- This is a test of the Help & Support document sample text
- This is a test of the Help & Support document sample text
Heading 1 – First Child
This is a test of the Help & Support document sample text
This is a test of the Help & Support document sample text
This is a test of the Help & Support document sample text
This is a test of the Help & Support document sample text
Heading 1 – Second Child
This is a test of the Help & Support document sample text
This is a test of the Help & Support document sample text
This is a test of the Help & Support document sample text
This is a test of the Help & Support document sample text
Heading 2
This is a test of the Help & Support document sample text
This is a test of the Help & Support document sample text
This is a test of the Help & Support document sample text
Heading 2 – First Child
This is a test of the Help & Support document sample text
This is a test of the Help & Support document sample text
This is a test of the Help & Support document sample text
This is a test of the Help & Support document sample text
Heading 2 – Second Child
This is a test of the Help & Support document sample text
This is a test of the Help & Support document sample text
This is a test of the Help & Support document sample text
This is a test of the Help & Support document sample text