TeamDynamix Implementation Syllabus

Overview
This section defines how incidents, requests, and changes will be submitted, prioritized, routed, and measured.

Estimated course duration:

We recommend setting aside about 30 - 50 hours total for Work Management content.

• Course Content: 
  • ITSM/ ESM 7 hr 42min (course viewing)
  • Additional Configuration Item Work: + 3 - 8 hrs. (homework/hands-on configuration) per week ≈ 30 hr – 50 total​​​​​​
    • This time could vary depending on how complex your organization's configuration will be.

Recommended roles

• TeamDynamix Global Admins
• Project Managers
• TeamDynamix App Admins
• Service Owners (Service Catalog Management)
• Technical Resources -
  • Web/ Marketing (Client Portal)
  • Authentication SSO (Core Integrations)
  • User Management (Core Integrations)
  • Email Management (Core Integrations)
• Knowledge Managers (Knowledge Management)
• Asset Managers (Asset Management)

• What you will define
  • In-scope processes (e.g., Incident, Service Request, Change; Problem as a later phase if desired)
  • Service catalog structure (services, categories, request offerings, and approval rules)
  • Priority/severity model (how impact and urgency map to priority)
  • Service targets (SLAs/OLAs), support hours, escalation expectations
  • Intake channels (portal, email, chat/Teams) and when to use each
  • Routing and assignment approach (assignment groups, auto-routing rules, on-call)
  • Knowledge expectations (what should be documented, who approves, review cadence)
  • Reporting needs (operational dashboards and stakeholder reporting)

Recommended starting point (example)
Start with Incident + Service Request + Change. Use a simple impact/urgency matrix (P1–P4). Publish a focused service catalog for your top 10–20 request types. Set support hours to business hours initially (e.g., 8am–6pm, Mon–Fri) and define clear escalation paths for P1/P2.

Constraints / notes
Keep the initial service catalog and automation rules intentionally small to reduce complexity at launch. Add additional services, workflows, and OLAs after your first 30–60 days of operational learning.

Deliverables / outputs
Documented priority model, SLA targets, intake channels, routing rules, assignment group model, initial service catalog, and a baseline reporting dashboard.

Overview
This section defines how project demand is captured, prioritized, approved, planned, and reported across the portfolio.

Estimated course duration:

We recommend setting aside about 20 - 30 hours total for Work Management content.

• Course Content: 
  • PPM 8 hrs 27 min (course viewing)
• Additional Configuration Item Work: + 3 - 5 hrs. (homework/hands-on configuration) per week ≈ 20 hr – 30 total​​​​​​
  • This time could vary depending on how complex your organization's configuration will be.

Recommended roles

• TeamDynamix Global Admins
• Project Managers
• TeamDynamix App Admins
• Technical Resources -
  • Web/ Marketing (Client Portal)
  • Authentication SSO (Core Integrations)
  • User Management (Core Integrations)
  • Email Management (Core Integrations)
• What you will define
  • Portfolio structure (portfolios/programs/project types and classifications)
  • Request intake (submission form, required fields, validation/triage process)
  • Stages and approval gates (entry/exit criteria and who approves)
  • Resource and capacity planning approach (role-based vs named; planning horizon)
  • Time/expense tracking (if used) and any downstream finance integrations
  • Governance cadence (intake review, steering, portfolio review, quarterly planning)
  • Standard dashboards and reports (health, demand pipeline, utilization, benefits)

Recommended starting point (example)
Begin with a single portfolio and a small set of project classifications (e.g., Run/Grow/Transform). Use a lightweight intake form and a 5-stage lifecycle (Proposed → Approved → Planned → In Progress → Complete). Establish a monthly portfolio review and a bi-weekly intake triage.

Constraints / notes
Capacity planning is most effective when the organization agrees on a consistent planning unit (e.g., hours per week by role) and a standard status cadence. Avoid over-customizing classifications early; expand once reporting and governance stabilize.

Deliverables / outputs
Defined intake form, lifecycle stages/gates, portfolio structure, governance calendar, capacity planning approach, and agreed baseline dashboards.

Overview
This section captures the integrations and automations needed to connect TeamDynamix with your identity, HR, and other business systems.

• What you will define
  • Target systems (source/target, data owners, and technical contacts)
  • Authentication and credential management (OAuth/service accounts, rotation)
  • Connector requirements (standard connectors vs API usage; network/VPN needs)
  • Integration patterns (batch sync vs event-driven) and expected volumes
  • Error handling (retry strategy, alerting, monitoring, and support ownership)
  • Scope boundaries (what will not be built in the initial phase)

Recommended starting point (example)
Prioritize identity/user provisioning and email intake first, then add HR-driven updates (new hires/terminations) and notifications. Use batch integrations for daily/overnight updates and event-driven notifications where user experience benefits (e.g., assignment or status change alerts).

Out of scope (typical for initial implementation)
Custom-coded middleware, complex ETL transformations, master data management, and highly customized encryption/transport requirements. Transformations are typically limited to field mapping, lookups, and simple logic.

Deliverables / outputs
Integration inventory (source/target, frequency), authentication approach, error handling/monitoring plan, and a runbook for integration support.

Overview
This section defines your conversational support experience, including channels, supported use cases, and how conversations escalate to tickets.

• What you will define
  • Channels (e.g., web chat in the client portal, Teams, other approved tools)
  • Initial bot use cases (FAQs, guided requests, status checks, outage messaging)
  • Ownership for intents/utterances and content governance (who maintains what)
  • Knowledge sources (what the bot can use as its approved source of truth)
  • Escalation and handoff (when to create a ticket, what data is captured)
  • Testing and validation approach (pilot users, success metrics, launch gates)

Recommended starting point (example)
Launch with a small set of high-volume intents (top FAQs and top requests), ensure each maps to a published KB article or a guided request offering, and provide a clear “create a ticket” fallback. Start with a pilot group for 2–4 weeks before broad rollout.

Constraints / notes
Bot quality depends heavily on the quality and consistency of your knowledge content and request catalog. Avoid launching broad, ungoverned intents; expand intentionally based on analytics and feedback.

Deliverables / outputs
Channel plan, list of initial intents/use cases, approved knowledge sources, escalation/handoff workflow, and a pilot/launch validation checklist.

Overview
This section defines how you will track assets in TeamDynamix, including required data, data sources, ownership, and audit practices.

Estimated course duration:

We recommend setting aside about 6 hours total for AISA content.

• Course Content: 4 hr 25 min (course viewing)
• Additional Configuration Item Work: + 5 - 7 hrs. (homework/hands-on configuration) ≈ 10 hr – 12 total​​​​​​
  • This time could vary depending on how complex your organization's configuration will be.

Recommended roles

• Inventory Managers
• Software Managers
• Project Managers
• TeamDynamix Admins

Courses

• ITAM:
  • Tailored ITAM Groundwork: 14 minutes
  • ITAM Groundwork: 14 minutes
  • ITAM Essentials: 1 hour 36 minutes
  • ITAM Additional Topics: 2 hours 21 minutes
• What you will define
  • Asset lifecycle stages and which team owns each stage
  • Required asset data fields and data quality expectations
  • Discovery/import approach and refresh cadence
  • Normalization rules (manufacturers/models, duplicates, naming standards)
  • Stockroom and ownership model (custodians, check-in/check-out, loaners)
  • Audit and reconciliation expectations (cycle counts, annual inventory, exceptions)
  • Reporting needs (inventory, warranty, aging, compliance)

Recommended starting point (example)
Start with endpoints (laptops/desktops) and a small set of non-discoverable assets (monitors/docks) using a clean CSV import. Define serial number as the unique identifier, standardize manufacturer/model naming, and establish a simple stockroom process for issuing and returning assets.

Constraints / notes
Asset management succeeds when receiving, deployment, and offboarding processes consistently update the system of record. If upstream data sources are inconsistent, prioritize data cleanup and normalization before expanding scope.

Deliverables / outputs
Asset data dictionary, import/discovery plan, normalization rules, stockroom procedures, and baseline inventory/warranty reports.

Overview
This section defines how AI assistance will be used in TeamDynamix, including feature scope, data readiness, governance, and privacy considerations.

Estimated course duration:

We recommend setting aside about 7 hours total for AISA content.

• Course Content: 5 hr 39 min (course viewing)
• Additional Configuration Item Work: 2 - 3 hrs (homework/hands-on configuration) ≈ 7 hr 39 min – 8 hr 39 min total
  • This time could vary depending on how complex your organization's configuration will be.

Recommended roles

• TeamDynamix Work Management Admins
• Project Managers

Courses

• AISA:
  • AI Service Assist Groundwork: 27 minutes
  • AI Service Assist Readiness Groundwork: 1 hour 2 minutes
  • AI Service Assist Implementation: 2 hours 50 minutes
  • AI Service Assist Readiness - AI Suggested Fields: 1 hour 20 minutes
• What you will define
  • Enabled AI features (e.g., summarization, suggested replies, suggested knowledge)
  • Data prerequisites (ticket history, field consistency, KB article quality)
  • Governance and approvals (IT leadership, security, privacy/legal)
  • Quality review process (sampling, feedback loop, rollback/disable criteria)
  • Privacy and compliance requirements (PII handling, retention, access controls)
  • Who can access AI features and where they appear in the application

Recommended starting point (example)
Pilot AI features with a limited set of technician teams (e.g., Service Desk) and focus on summarization and knowledge suggestions first. Require human review before saving AI-generated notes, and expand gradually based on quality results.

Constraints / notes
AI quality depends on clean ticket categorization and well-structured knowledge. Establish clear guidance for sensitive data and ensure appropriate approvals are complete prior to enabling features.

Deliverables / outputs
Approved feature scope, governance approvals, pilot plan, quality review checklist, and end-user/technician guidance on appropriate AI use.