The service catalog is a foundational, keystone component of your TeamDynamix implementation. Often, customers struggle to define an appropriate scope for their service catalog - especially if the idea of a service catalog is new to the organization. How many services and offerings should we have? How broad or detailed should we be with our services? It can be very challenging for your organization to develop to a satisfying answer.
Some guidelines that may help:
Resources:
In addition to thinking about the scope and what's going to be included in your service catalog, also spend time thinking about the appropriate way to organize and structure your services in order to make it work effectively for all stakeholders: clients browsing for a service to request; technicians organizing those service requests and processing them; leadership reviewing metrics and reporting off the services.
Be flexible with your structure - utilize category and service shortcuts to help your users find content where they might expect it to be. Think about your user flow and how you might utilize different navigation paths. For example: Direct links for targeting communication; Client portal search for immediate access to specific services/needs; Shortcuts and categories for discovery and browsing.
If you have the time and capability, usability analysis and focus testing with your users can help validate your assumptions or provide new perspectives on how your users may interact with your structure. Are there areas that are confusing or poorly worded? Are your common services hard to find or take many clicks to navigate to?
Your service catalog will have the most value and return on effort when it helps to streamline the fulfillment of common requests. A good service catalog should collect all the data you need upfront and route these requests directly to the teams, tools, or systems that can best fulfill them.
If you have the data, review examples of similar requests in your old ticketing system and look for the kinds of questions, follow-up information, or details that are used to help fulfill the request. Incorporate those insights into your forms and make it easier to collect that information up front.
Take a look at how those requests are processed or fulfilled. Are there fields you can add to the request form to help create dashboards or reports that could be used by technicians to better fulfill those requests?
Think about the customer experience when filling out the form. Is it intimidatingly long? If they make a mistake, do they have to backtrack and re-fill a lot of the form? Ideally, you want your forms to capture just enough detail to fulfill the request efficiently but not burden your customer with many fields, choices, or complex dependencies that they have to navigate just to submit a request.
If you have purchased a custom domain (also known as a "vanity URL"), have you decided on what that domain will be? Your domain is used in many other areas of configuration and implementation, so you will need to have your custom domain configured prior to setting up SSO, People Import, and other integrations. The longer you wait to configure your custom domain, the more painful the cutover process will be.
If your desired custom domain is already in use and cannot be used until go-live (e.g. it's currently in use by your old ticketing system), you will need to plan appropriately for the cutover process ahead of time to ensure a smooth cutover process.
Examples of changes you may need to perform when configuring a custom domain:
Who should be included in your people import? Typically, most clients will import their employees and staff. If you're an educational institution, you'll likely want to import faculty and students as well. Will you want to include prospective students, alumni, etc? Do these people need to have a full user record and be able to log in, track their request history, etc. or do you only need simple contact info for service request management purposes?
Once you've defined who should be included in your people data, determine what system or systems that data will come from. How will you be extracting that data from those systems? Do you need to combine it with data from other systems in order to fully populate what's needed for import into TeamDynamix? What does your data flow look like?
Do you have multiple different colleges, campuses or branded sub-divisions with distinct customer populations in your organization? If so, you may want to consider having multiple client portal applications to help provide consistent and familiar branding for your distinct groups of customers.
With multiple client portals, you can have uniquely branded landing pages for that entity, including logos, colors, introductory info, etc. Additionally, portal access is handled through user permissions, so you need to rely less on group permissions to manage visibility and show/hide items. However, adding multiple client portals does create more complexity for your customers - there are multiple places for your customers to find knowledge articles, services, and general information. Consider carefully what expectations your customers have around branding, access, and UX when requesting services or looking for information.
Will you have multiple departments using TeamDynamix to manage and fulfill requests? For example: HR, Facilities, Admissions. If so, you will likely want to consider having multiple ticketing applications to help intake those requests and keep them separate and scoped to the appropriate department: Tickets are only visible to admins and users who explicitly are given access to the ticketing app, and some branding (e.g. notification templates, email integrations) can be customized for each organization's branding.
Similarly, do you have multiple departments who need to track and manage assets? For example: IT, Facilities, Athletics, Manufacturing. If so, you will likely want to consider having multiple separate asset applications to help provide appropriate access and management of those items.
Asset Management is often a challenging component for many clients. Not necessarily due to configuration, but because existing asset management processes in an organization can be scattered and disorganized. Information needed for effective asset management may be incomplete or spread across the organization; data may live in spreadsheets owned by different teams or individuals, in standalone databases, ITSM or ITAM apps, endpoint management apps like SCCM, Intune, or JAMF. Or it may not exist at all!
Think about your asset management processes holistically as you consider how data may flow through your organization:
At the start and also ongoing throughout your implementation, be sure that you are appropriately planning and adjusting your scope according to your capability and deadlines. Is what you are planning actually realistic to accomplish for your target deadlines? Have you included slack time to account for unforeseen issues and delays? Or are you being overly optimistic with how quickly you can make decisions or configuration?
Review your planned scope alongside realistic demands on your resources from other projects/areas of your organization, and ensure you are appropriately planning for "unknown unknowns" that you may need to address - other projects, shifting priorities, emergencies, PTO/OOO/Holidays, etc.
You may want to do a work-back exercise: Starting from your target go-live deadline, work backwards to block out how much time is needed for: training, QA/UAT, organizational change management, communication, configuration, etc. Your implementation consultant can help guide you on typical timelines for different areas of configuration and provide reasonable first-guess estimates.
You may also want to review your processes and decide which ones are "must-haves" to build out in your TeamDynamix system prior to go-live, and which ones are "should-haves" that can wait until after your go-live. How well defined are those critical processes? Do you need to spend additional time or discussion to develop your process more thoroughly? Be sure to incorporate any additional time needed for process development into your planned scope above.
Examples of common critical processes for service management:
In addition to planning out your availability, resources, and timing for configuration, it's important to start planning your overall deployment strategy early. Your go-live is not only technical changes like a new system, new interface, and potentially new processes... but also an organizational and political change: the way people work, request help, access resources, and interface with your services will all be different. Change is scary! Planning out your deployment process early will help make those changes be accepted and integrated into your organization and give you opportunities to respond empathetically to negative reactions throughout the process.
Review your communications plans and work with resources in your organization to identify the best ways to manage communications about your implementation early and often. You may want to ask your HR department, PMO, or other similar departments to get tailored advice about what strategic key points should be considered when developing a communications plan for your specific organization's needs.
Think about what other outreach or deployment activities you may want to add into your deployment plan. Do you want to do user demos? A go-live party for the implementation team? Town hall discussions with stakeholders? Internal advertising and messaging on signage? Training or peer support forums? Email status updates to leadership? Think about the different stakeholder groups you want to engage, and the best way to manage the narrative about the implementation that you provide to those stakeholder groups.