TCTime Champ Academy
WorkflowCSM ยท SALES10 min

Capacity Planning: Data sources

Objective. Validate where the plan's volume and workforce data come from - check coverage and freshness - and explain that a connected source is not the same as validated, current data.

This configuration screen shows the sources feeding the plan - volume/demand and workforce data. A CSM validates coverage and freshness, because every requirement downstream inherits the quality of these inputs.

See it in the demo

What this screen answers

A CSM opens this to answer 'where does the plan's data come from, and can we trust it?' Volume and workforce feeds are the foundation; a gap or stale feed quietly corrupts every requirement. This screen is where the sources and their status are checked.

The task (validate, do not re-engineer)

Scope to the customer and confirm the expected sources are connected, cover the work and people in scope, and are fresh enough for planning. Flag missing or stale feeds. This is validation and escalation - confirm coverage and freshness; leave integration engineering to the specialist. Describe it as 'the data sources configured for this scope'.

How to read it

A connected source is not the same as validated, current data. The misread is assuming that because a feed shows connected, the data is complete and fresh. Read for coverage (does it include all the work and people being planned?) and freshness (how recent?). In the demo the data is seeded, so never present an on-screen source status as the customer's live integration. Stale or partial sources are the quiet root cause of a plan that looks right but is not.

Honest limits

This screen does not prove the data is complete, accurate or live - only what is configured. Confirm with product how volume is sourced and which integrations apply for the customer; the demo shows the model on seeded data. Escalate integration setup to the specialist.

Interpretation check

A connected data source is not the same as validated, current data - check coverage and freshness, and never present the demo's seeded source status as a customer's live integration.

In the field

An RCM operation planning on volume feeds: a stale or partial volume source silently under- or over-sizes the plan - validating coverage and freshness here is what keeps the requirement trustworthy.

Practical task

Review the configured data sources for one scope and write one line on coverage and freshness, flagging any gap, and note explicitly that demo data is seeded, not a live feed.

Self-check

A source shows connected. Is the data trustworthy?

Not on that alone. Connected is not complete or fresh. Check coverage (all work and people in scope) and freshness (how recent), and remember demo data is seeded.

Why validate sources before interpreting any requirement?

Every downstream number inherits input quality. A gap or stale feed quietly corrupts requirements that otherwise look fine, so source coverage and freshness are a foundational check.

What must you never do with the on-screen source status in a demo?

Present it as the customer's live integration. The demo is seeded; the real volume source and integrations must be confirmed with product.

Verified vs demo. Screen is live in the demo at /#/sources; exact controls and figures are SME-validation-pending.