Enterprise-Wide Systems (EWS) is an area within University Information Technologies that provides services to support the university’s core administrative systems. Our team is responsible for the management, maintenance, and strategic development of the Banner ERP system and its related applications. We collaborate closely with departments across campus to provide dependable, responsive service—always with the goal of making systems easier to use, data more accurate, and processes more efficient for the people who depend on them every day.
This document outlines the procedures for requesting work from EWS and details how such requests will be managed. By following these procedures, we can ensure timely and efficient support for students, faculty, and administrative staff while maintaining clear communication and proper resource allocation.
These procedures are designed to provide clarity and consistency while supporting the diverse needs of the Villanova community. As we continue to collaborate, we will refine and evolve these processes to improve efficiency, responsiveness, and overall service. We’re not pouring concrete here—your feedback and partnership are essential as we identify new opportunities to streamline workflows and enhance the support we provide.
NOTE: THIS DOCUMENT WILL BE UPDATED AND EVOLVE TO REFLECT CHANGES AS UNIT ADOPTS THE SMARTSHEET
PLATFORM FOR PROJECT MANAGEMENT DURING THE SPRING AND SUMMER OF 2025.
A clear distinction between Service Requests, Incidents, and Projects ensures that routine tasks are handled quickly, urgent issues are addressed appropriately, and larger initiatives are properly planned. This structure allows EWS to provide consistent, high-quality service while balancing the needs of all stakeholders.
Service Requests and Incidents are the two types of non-project tickets that should be submitted through the standard ticketing system. Understanding the difference ensures that requests are classified correctly and resolved as efficiently as possible.
A Service Request is a routine, repeatable task that follows an established procedure. These requests typically require minimal effort and can usually be completed within 4 hours of work duration (not turnaround time). Examples include:
An Incident, on the other hand, is an unplanned interruption to a service or a reduction in service quality. A request should be classified as an Incident only if a function that was previously working as expected has stopped working. Examples include:
If something isn’t working quite the way you prefer but still functions, it’s probably not an Incident. Instead, it might be something that needs improvement (an enhancement request) or something that could be addressed with guidance (a training issue). If you’re not sure how to classify your request, go ahead and submit it as a Service Request—EWS will review it and adjust the category if needed.
Resolution Time:
Incidents are prioritized to ensure critical services are restored as quickly as possible. The EWS team is committed to swift resolution and responsive communication. While timelines may vary depending on factors such as the number of users affected, issue complexity, and the availability of workarounds, we aim to minimize disruption and keep impacted users informed through timely updates and clear guidance.
We expect that most Service Requests are handled within one to three business days, following our general service-level agreements (SLAs). However, actual resolution times may vary based on:
SLAs provide helpful guidelines, but they aren’t hard deadlines — some requests may take longer depending on circumstances. We aim to periodically review and adjust our service targets to make sure they stay reasonable and reflect the needs of different request types.
Unlike Service Requests and Incidents, Projects require planning, coordination, and discovery before work begins. These larger initiatives have a defined start and end date and require more extensive effort than standard service tickets.
This document primarily focuses on Tier 3 projects, also known as the Book of Work, which are smaller-scale projects affecting a single department or area.
Typical Tier 3 projects include:
As a general rule, if a request requires planning, development, or coordination beyond a few hours of work, it should be classified as a project rather than a standard service ticket.
EWS team members are expected to recognize when a task begins to exceed routine service request levels. If the scope of a request expands beyond what was initially expected, EWS team members will notify their manager to ensure the work is appropriately classified and resourced.
NOTE: More complex initiatives, such as enterprise-wide system overhauls or multi-departmental implementations of a new system, fall into Tier 1 and Tier 2 projects and require formal consultation with the UNIT Project Management Office before work can scheduled. To initiate this type of request, please fill out the Request A Project Consultation form.
How to Submit a Service Request or Incident
While collaboration with EWS team members is encouraged through email, phone, chat, or video meetings, all new, non-emergency work requests (more on emergencies below) must be submitted through the Team Dynamix (TDX) system before work can be assigned.
This process ensures that requests are properly documented, prioritized, and tracked, allowing the team to provide efficient and timely support. If work is initiated without a corresponding TDX request and it is not classified as an emergency (see the Special Circumstances section below), the work will be paused until the request is formally submitted and evaluated.
For Service Request/Incidents:
To ensure timely resolution, submit a request through TDX with relevant details. The more information provided upfront, the faster and more efficiently we can assist.
For Routine Service Requests (Non-Urgent Needs):
Provide details relevant to your request, such as:
-
System or Application – Specify the relevant system (e.g., Banner, Slate).
-
Environment - Specify the environment (e.g. PROD, TEST, VAL)
For Incidents (Break/Fix Emergencies):
If something that previously worked is now broken or malfunctioning, include as applicable:
-
System or Application – Specify the affected system.
-
Environment - Specify the environment (e.g. PROD, TEST, VAL)
This list is not meant to be exhaustive but provides examples of key details --please use your judgment to include any additional information that may help us address your request efficiently.
The EWS team will review submissions and assign them to an EWS resource based on availability to ensure timely and effective support.
Note: Tickets should be submitted directly through TDX whenever possible to ensure faster processing and accurate tracking. Emailing support@villanova.edu should be used as a last resort, as requests submitted via email may experience delays due to manual review and reassignment.
Assignment of Tickets:
To ensure timely and efficient support, assignments are made based on availability, expertise, and current workload to best meet the needs of all stakeholders.
While we understand the value of working with familiar team members, repeatedly directing tickets to the same individual can lead to workload imbalances and may delay response times. Our goal is to provide consistent, high-quality service by distributing requests across the team, ensuring no single staff member becomes overwhelmed.
For Projects or Uncertain Requests:
If unsure whether a request qualifies as a service request/Incident or a project, submit an ERP Consultation Request. The EWS team will review and determine the appropriate classification during weekly manager meetings.
Misclassified Requests:
If a request is submitted as the wrong type (e.g., a service request or incident that should be a project, or vice versa), EWS will reclassify it to ensure it’s handled appropriately. When this occurs, an EWS manager will communicate the change to the requester, along with any updates to process, timeline, or next steps.
EWS team members are expected to be proactive in identifying when a request may need to be reclassified—particularly if the scope grows beyond initial expectations—and should notify their manager promptly.
Our goal is to minimize delays and ensure a smooth experience for all stakeholders as we continue refining these processes together.
Need Help Deciding?
If you're unsure whether your request qualifies as a ticket or a project, contact Julie Turnbull or any member of the EWS leadership team (Antony Lower, Julie Turnbull, Rob Mott, Josh Wharton, or Emily Wilms) for guidance.
Alternatively, submit an ERP Consultation Request through TDX to ensure the request is reviewed and classified appropriately.
For additional support or questions regarding specific situations, feel free to reach out to EWS—we’re here to help ensure your needs are met as efficiently as possible.
Emergency Situations:
In urgent situations where an issue severely disrupts critical operations or poses a security risk, contact an EWS team member immediately. Examples of emergencies include system outages, data breaches, and errors that prevent essential university functions. You can also check to see if an incident has already been reported via visiting https://villanova.edu/servicestatus.
While we understand the importance of meeting deadlines, routine requests with tight timeframes do not qualify as emergencies unless they directly impact essential functions. Note: Prioritizing new requests of this type may result in lowering the priority level of other work that is already in progress.
In emergency cases, work may begin without a formal TDX request; however, the requestor must submit a ticket as soon as possible to ensure proper tracking and accountability. Be sure to include all relevant details in the ticket submission.
EWS is committed to responding promptly to urgent needs while maintaining efficient service for all requests.
Non-Production Environments:
Non-production environments, including development and testing systems, are intended for experimentation and validation. While EWS strives to maintain stability in these environments, availability and performance may vary due to system maintenance, upgrades, or testing needs. Additionally, factors outside of EWS’s control --such as server patching or network upgrades may impact on performance or accessibility.
If development or testing requires guaranteed availability, please coordinate with EWS in advance to explore scheduling options. In the event of an interruption, restoring service in non-production environments may take up to 24 hours. Early coordination helps us ensure the best possible support while balancing system resources and priorities.
EWS team members play a vital role in ensuring that requests are processed accurately and efficiently, providing stakeholders with timely support. The following guidelines help maintain clear communication, proper tracking, and consistent workflow management, ensuring a seamless support experience for the Villanova community.
Ticket Management
To help support UNIT’s goal of assigning tickets to a resource within the SLA’s timeframe, EWS team members are expected to actively monitor both their assigned tickets and the Unassigned Ticket section of the EWS Ticket Overview dashboard in TDX. By ensuring timely assignments and proactive communication, we help stakeholders receive prompt and reliable support, while maintaining efficient workflows within the team.
Queue Triage rotation
Some EWS team members will rotate Queue Triage responsibilities where they are assigned a week to oversee the unassigned ticket queue to help point out any requests that are not assigned to a team member in a timely manner.
To assist the person doing this review and maintain a proactive approach to service, all EWS staff are expected to check the Unassigned section of the dashboard at least once daily and assign any tickets they can handle to themselves.
This shared responsibility helps distribute workloads fairly, reduces delays, and ensures stakeholders receive the timely support they need. By collaborating in this way, we help maintain a high level of service that reflects our commitment to supporting the Villanova community.
Ticket Processing Steps
If the request was created by an EWS team member sending an email to support@villanova.edu:
When Work Begins
-
For awareness, you may add additional stakeholders, such as your manager or other functional area team members who may need to take follow-up action after your work is complete. Click on the People tab and add a new contact. Note that once added, you must explicitly add them to receive notifications for each new update.
-
If you determine that a ticket is misclassified (e.g., a service ticket should be a Tier 3/BOW project or vice versa), promptly notify your manager and update the ticket type (see instructions below) to ensure accurate processing.
Ongoing Updates
-
If you notice after the fact that the PRIVATE checkbox was accidently checked, use the MORE link before the entry to update it to PUBLIC, and then enter a new entry to notify the requestor to look for the original update.
-
If a service request ticket begins to take significantly more time or effort than expected, evaluate whether it might fall under project work. Proactively notify your manager if the scope appears to be expanding beyond a standard service ticket to ensure it is appropriately classified and resourced.
When Work is Complete
This ensures that email-generated tickets are properly tracked and assigned, maintaining efficiency and accountability within the team.
How to Update a Ticket Type
Modify Service Level Agreement (SLA)
Closing
By adhering to these procedures, we can ensure efficient workflows, clear communication, and proper resource allocation to support our stakeholders effectively. Success relies on each team member’s proactive approach — recognizing when work is becoming more complex than expected, raising their hand when additional support is needed, and collaborating with managers to ensure tasks are correctly classified and resourced.