Capacity Planning: Documentation
Objective. Use the documentation screen as a reference, while explaining that in-app docs describe intended behaviour and do not confirm a customer's production entitlement, integration or figures.
The documentation screen is the in-app reference for how Capacity Planning is meant to work. A CSM or rep uses it to look up intended behaviour - and treats it as guidance to confirm, not as proof of what a specific customer has.
See it in the demo
What this screen answers
A Sales or CSM person opens this to answer 'how is this feature meant to work, and where do I check the definition?' It is the reference layer - useful for grounding a claim or checking a term - rather than a screen that shows a customer's data or decisions.
The task
Use it to look up the intended behaviour, definitions or method behind a screen when preparing a demo or answering a question. The move is to pair anything you read here with a confirm-with-product step before stating it as fact for a customer. Describe it as 'the in-app documentation for this area'.
How to read it
Documentation describes intended behaviour, not a given customer's reality. The misread is quoting a doc as proof that a customer has an integration, entitlement or metric - it is not. Read it as the model and intent; confirm entitlement, integration scope and real figures with product and against the customer's contract. In a demo it also reflects the demo build, which may differ from a customer's version.
Honest limits
This screen does not establish what any customer has bought, integrated or is achieving. Never assert production entitlement, integration or a metric value from documentation. Use it to ground your understanding, then confirm the specifics with product and the account team before they become customer commitments.
Interpretation check
In-app documentation describes intended behaviour, not a given customer's reality - never quote it as proof of production entitlement, integration or achieved figures; confirm those with product.
Practical task
Look up one definition or behaviour in the documentation, then write a two-line note: what it says, and the confirm-with-product step required before it becomes a customer-facing claim.
Self-check
Can you cite the documentation to confirm a customer has an integration?
No. Docs describe intended behaviour, not a customer's entitlement or setup. Confirm integration, entitlement and figures with product and against the contract.
How should you use this screen when preparing a demo?
To ground your understanding of intended behaviour and definitions, then pair anything load-bearing with a confirm-with-product step before stating it as fact to a customer.
What caveat applies to documentation shown in the demo build?
It reflects the demo build and intended model, which may differ from a specific customer's version - so treat it as guidance to verify, not a guarantee.
Verified vs demo. Screen is live in the demo at /#/docs; exact controls and figures are SME-validation-pending.