Qualify application fit
Objective. Distinguish a time-visibility problem, an output problem, a process problem and a planning problem, and recommend the smallest useful starting scope - including when to call a no-fit.
Teaches you to map a discovered problem to the right application class and the smallest scope that proves value, rather than proposing the whole platform. You will learn the four problem classes, which applications answer each, and how to state an honest no-fit so you protect the pipeline and your credibility.
See it in the demo
The customer problem
AEs lose deals two ways at this stage: over-scoping and mis-scoping. Over-scoping proposes eight applications to a buyer who has one problem and one budget, which inflates price, lengthens security review and kills urgency. Mis-scoping demos the wrong application because the symptom was taken literally - showing Work Output to a team whose real issue is a forecast that is always stale, or showing Scheduling to a team whose real issue is that activity does not convert to completed work. Business impact: longer cycles, lower win rates, and pilots that cannot show a clean result because they were aimed at the wrong problem. The fix is to classify the problem before choosing the application, then deliberately pick the smallest scope that can produce a trusted number.
The four problem classes and their applications
TIME-VISIBILITY problem - 'we cannot see which paid hours are available and how they are used': Time and Activity (attendance vs available vs utilized, exceptions) and, for application-activity evidence, Employee Monitoring. Answers 'which hours do we have and where should a manager look'. OUTPUT problem - 'busy teams are not producing the expected work at acceptable quality and cost': Work Output (completed work, complexity, standards, quality, cost) and Quality and Call QA for the quality/coaching loop. Answers 'are we getting the work, well, affordably'. PROCESS problem - 'work takes too long and we do not know why': Work Understanding (waiting, friction, rework, variants, root cause). Answers 'why is it slow and which change to validate first'. PLANNING problem - 'we cannot match people to demand': Capacity Planning (how many, which skills, when), Scheduling (feasible schedules), Real-Time Adherence (plan vs actual vs output live), Intraday Management (reforecast and correct the day). Business-outcome layer (RCM Operations, RCM Insights, Value Leakage) sits across all four for the revenue-cycle executive. Most problems have a primary class and a secondary - name both, scope to the primary.
What to say / do - scoping to the smallest useful start
After classifying, say: 'Based on what you described, the problem that is costing you most and that you can measure soonest is X, which is a <class> problem. I would start with <one application> on <one team / one process / one payer> for a defined window, because that is the smallest scope that produces a number you will trust - and once you trust it, the natural next step is Y.' Rules for 'smallest useful': one application, one team or process or client/payer, a time window long enough to establish a baseline, and a completion/measurement definition the customer agrees to up front (critical for Work Output - if they cannot define a completed unit, start with Time and Activity or Work Understanding instead). Name the expansion path but do not sell it yet. For a KnackGlobal-style RCM output question you might scope Work Output on one claim-processing team plus the cost-per-clean-unit view (https://work-output.demo.timechamp.io/#/overview), not the whole WFM suite.
When to recommend a no-fit (and how)
Calling a no-fit protects revenue: a forced-fit pilot that fails poisons the account and the reference. Recommend a no-fit (or a 'not yet') when: the problem is a pure headcount-budget or org-structure decision with no measurable work process underneath; the customer cannot and will not define a completed unit of work or a trusted standard, so Work Output has nothing to count; there is no data source to capture the activity or work in scope (confirm capture/source feasibility with a specialist before promising); the only buyer is a monitoring-first stakeholder who wants surveillance, which is a values mismatch and a reputational risk; or the urgency is entirely external and fake (board wants 'an AI tool') with no owned operational problem. How to say it: 'Honestly, I do not think we are the right first step for that specific problem - here is why, and here is what I would need to see change before a pilot would prove anything.' This earns the right to the next real opportunity.
Objections and honest limits
'Why not just give us everything, we will grow into it?' - Because a trusted number from one scope beats an unused eight-application rollout; price and risk scale with scope, and a clean pilot result is your best expansion lever (S08, S09 handover). 'We have an output AND a planning problem.' - Fine - name both, pick the one with the clearer baseline and shorter time-to-number as the start, and put the other on the expansion path. Honest limit: fit classification is a hypothesis, not proof - it should be validated in the evidence-led demo and the pilot, and you should never assert that a given application will solve a problem whose data feasibility a specialist has not confirmed. If source coverage is uncertain, say 'confirm with product' rather than promising the application can count the work.
Interpretation check
Classifying the problem is not the same as proving the application fits. A time-visibility, output, process and planning problem look similar on the surface ('we are busy but behind') but need different applications; and even the right class can be a no-fit if the data or the completion definition is not there.
In the field
KnackGlobal: the primary class is an output/cost problem (output per FTE, cost per claim), so the smallest useful start is Work Output on one claim-processing team with an agreed clean-unit definition, with Value Leakage and RCM Operations on the expansion path - rather than proposing the full WFM suite to win a displacement on day one.
Practical task
For a given (or your own) discovery, recommend the smallest useful starting scope: name the primary problem class, the single application and the one team/process/payer to start with, the completion or measurement definition required, and the expansion path. Separately, write one honest no-fit case explaining why a specific problem is not a fit (or not yet) and what would need to change.
Self-check
A team is active and on-shift but the queue is not clearing. Which problem class, and why not the obvious one?
This is an output problem (activity is not converting to completed work), not a time-visibility problem. Showing attendance/utilization would confirm they are present but not explain the output gap - Work Output is the fit.
What is the hard prerequisite before scoping a Work Output pilot?
A completed unit of work and a trusted standard the customer will agree to. Without a definition to count against, Work Output has nothing to measure - start with Time and Activity or Work Understanding instead.
Give two legitimate reasons to recommend a no-fit.
Any two: pure headcount/org decision with no measurable process; no agreeable completion definition or standard; no data source to capture the work (confirm with specialist); monitoring-only buyer (values mismatch); only fake external urgency with no owned problem.
Why does 'smallest useful scope' win over 'start with everything'?
A trusted number from one scope is the strongest expansion lever; broad scope inflates price, lengthens security review, and risks an unused rollout and a failed, poisoning pilot.
Which suite spans all four problem classes for a revenue-cycle executive?
The Business Outcomes layer - RCM Operations, RCM Insights and Value Leakage - which connects any of the four to revenue-cycle outcomes and recoverable value.
Verified vs demo. Which application addresses which problem class is demo-grounded; whether the customer's specific data and completion definitions make a given application viable is NOT - confirm source coverage and capture feasibility with a specialist before committing.