Integration scope
Objective. Scope an integration conversation at app-logic level - what data is needed, from where, for which outcome - and route every technical specific to a specialist instead of guessing.
A worksheet that lets a non-technical seller or CSM run a credible integration conversation without overstepping. It frames integration by the outcome and the signals needed, captures the customer's systems of record, and draws a hard line between what you can say and what goes to a specialist. Fill it with the customer, then hand the technical half to the specialist.
See it in the demo
What it is and when to use it
An integration scope worksheet structures the 'how does this connect to our systems' conversation. Use it in discovery once an application fit is emerging, and before any implementation planning. Its purpose is to get the right inputs captured and the right questions routed - not to design the integration. You scope at app-logic level: which outcome needs which signals from which of the customer's systems. Connectors, APIs, auth, data formats, effort and timelines are the specialist's domain; your job is to frame the need accurately so the specialist starts from a real picture.
The worksheet - copy this
Integration scope - <customer>, <application>
- Outcome the integration serves: (the question/metric it must produce)
- Signals / data the application needs for that outcome: (described in business terms)
- Customer systems of record that hold those signals: (name them: case/ticketing, telephony, HRIS, claims/billing, etc.)
- Smallest useful starting data: (what is enough to produce one trusted number)
- Who owns each source system on the customer side: (named)
- Known constraints the customer raised: (access, security review, data residency, change freeze)
- Dependencies on other Time Champ apps: (inputs one app needs from another)
- Specialist questions (route, do not answer): connectors available? auth method? data format/frequency? effort/timeline? security questionnaire?
- Agreed next step + owner + date:
How to fill it
Start from the outcome, never the connector - 'we need output per paid hour for the claims team' tells the specialist far more than 'we need an API'. Describe needed signals in business terms and let the specialist map them to technical sources. Capture the customer's actual systems of record by name and who owns each, because that is what an implementation plan is built on. Push for the smallest useful starting data: one trusted number from a narrow source beats a full integration that stalls. Log every constraint the customer raises, especially anything touching security or data residency, and move it straight to the specialist. The bottom block is a routing list, not a quiz for you to answer - write the questions down and send them, confirm-with-product.
Honest caveat
You scope the need; you do not commit the integration. Do not name a connector as available, quote an auth method, promise a data frequency, or estimate effort or timeline - all of that is confirm-with-product and belongs to the implementation specialist. Never answer a security or data-residency question yourself; route it to security. Dependencies between applications are described at app-logic level (one app's output feeding another), not as a guaranteed technical pipeline. The worksheet is only useful if its specialist-questions block actually leaves your hands and reaches the specialist with the customer's constraints attached.
Interpretation check
Integration is scoped by outcome and signals at app-logic level; connectors, auth, formats, effort, timelines and security answers are the specialist's and are confirm-with-product. Framing the need accurately is your job - committing the integration is not.
In the field
OVO POC scoping: outcome = connect Salesforce case and AgentWork active-time with Time Champ desktop effort to show effort-to-outcome; systems of record named (Salesforce, telephony); starting data kept narrow (read-only case/AgentWork signals); connector, OAuth scope and effort routed to the specialist rather than committed on the call.
Practical task
Fill the worksheet with a real customer scenario: state the outcome, list the signals in business terms and the systems of record that hold them, then write the specialist-questions block and actually route it with the customer's constraints attached.
Self-check
Why start the worksheet from the outcome rather than the connector?
Because the outcome and the business signals it needs tell the specialist what to build; leading with 'an API' hides the actual requirement and invites a wrong scope.
A customer asks whether you integrate with their telephony system and how long it takes. Response?
Capture it as a specialist question and route it with their systems named; do not confirm a connector or quote a timeline - both are confirm-with-product.
What is the value of pinning the 'smallest useful starting data'?
It lets you produce one trusted number quickly rather than waiting on a full integration that can stall; it de-risks the pilot and proves value sooner.
Who answers a data-residency or security question raised during scoping?
Security / product - never you. Log it as a constraint and route it; never assert a security or compliance fact.
Verified vs demo. Integration and data-source areas are demo-shown for capability context (Employee Monitoring integrations, RCM Insights data); every technical specific - connectors, auth, formats, effort, timeline, security - is confirm-with-product and owned by the specialist.