Hey cats,
An analysis has identified customers whose ordering pattern has changed. The account team can see the names, the period examined and the orders behind the finding. What should happen next?
Someone still has to decide which accounts deserve attention, what work to assign and what a useful result would look like. If those decisions remain in a conversation, the person responsible for the account may receive a task without enough information to act on it. Or everyone may assume that somebody else will follow up.
This is where ACT fits in DUKE’s ASK / VERIFY / ACT approach. ASK starts with the business question. VERIFY examines the sources and business rules behind the answer. ACT is the link from the checked finding to an operational step that your team approves. Execution must be evaluated against the supported integration and scope agreed with your team. [1]
Let us follow one illustrative workflow: preparing an internal account-review task after an ordering change. This is a hypothetical example, not a customer result or a recording of a completed product action. The review method below describes what the team should agree and what an evaluation should demonstrate.
1. Establish what the finding actually says
“These customers have stopped ordering” sounds straightforward. It becomes less straightforward when one customer buys every week and another purchases stock before a seasonal peak. The same period without an order can mean different things.
Start by agreeing what counts as an order. A quotation, a confirmed order and an invoice describe different stages. Then check the reference period, the latest available data and whether the customer identifiers match across the systems being examined. A change in an identifier could otherwise make continuing business look like a disappearance.
The account owner also needs to understand the comparison. Has the customer missed its usual purchasing rhythm? Is the analysis comparing equivalent periods? Was a cancelled order removed? These questions determine which accounts belong in the review and which need further investigation.
A checked finding can establish that ordering activity has changed within a defined scope. It may still leave the reason open. A delayed replenishment, a planned closure or an unresolved service issue would call for different responses. The task should retain that uncertainty so that the account owner knows what to investigate.
In the ASK / VERIFY / ACT sequence, verification gives the proposed action its starting point. Preserve the definition, the source references and the date of the finding when handing it over.
2. Give the next step a useful shape
The business intention might be to recover an account that needs attention. The immediate operational step could be an internal review, assigned to the person who knows that account. Its purpose is to understand the change and decide whether a customer conversation or another response is appropriate.
Write the proposed task as something its owner can carry out. For example: review the specified accounts, examine the ordering evidence and recent interactions, then record the explanation found and the recommended next step. Name the owner and a review date. Customer contact or a change to commercial terms would require its own agreed scope.
The difference becomes visible in the task itself. A title such as “Check inactive customers” leaves the owner to reconstruct the work. A useful task carries the account list, the definition of the ordering change, the source period and the question to resolve. The owner can then spend time on the account instead of guessing why it appeared on a list.
Keep the proposed action proportional to what the analysis supports. An internal review may be the right response when the cause is uncertain. The finding earns attention; the review determines what that attention should lead to.
3. Make approval a decision someone can take
The approver should be able to see the proposed work before accepting it. For this example, the review should show the accounts concerned, the task text, the person assigned, the destination tool and the permissions required. It should also show the checked evidence that prompted the proposal.
The approver and the action owner may be different people. A sales manager might approve the scope while the account owner carries out the review. Stating both roles avoids an awkward handover in which approval is mistaken for ownership of the follow-up.
Here is a compact way to describe the decision in this illustrative workflow:
| Element to review | What the team needs to agree |
|---|---|
| Finding | The ordering change, its definition, source period and remaining uncertainty. |
| Proposed work | An internal account review, with its task text and expected output. |
| Scope | The named accounts, supported destination and permitted changes. |
| People | The approver, the account owner and the person handling exceptions. |
| Follow-up | The execution evidence to check and the date for reviewing the account situation. |
Timing matters as well. A customer may place an order while the proposal waits for review, or a colleague may already have opened a task. Agree how the team will recheck eligibility before execution. If the account list or the proposed work changes materially, the approver needs to see that change.
These are concrete points to examine in an evaluation. A label saying “human approved” becomes useful when the person can identify exactly what they accepted.
4. Check what happened in the destination tool
Approval authorizes the agreed step. The next question is whether that step actually happened. In our example, useful execution evidence includes the task reference, the destination, the assigned owner and the accounts linked to it. The task should contain the information that was approved.
This is a practical distinction for agent workflows. Anthropic’s engineering guidance describes checking results returned by tools or the environment to assess progress, with human checkpoints when needed. [2] For a business team, the corresponding question is simple: what can we inspect in the working system to confirm the result?
Discuss exceptions before the first run. What happens if the account has no owner, permission is refused or the destination does not return a clear result? Who decides what to do next? An uncertain response should prompt a check of the destination before the same task is requested again.
Also agree how an incorrect task can be amended or cancelled, using the capabilities and permissions of the destination tool. The ability to propose a correction and the authority to perform it need to be clear. Those boundaries belong in the operating method, including when an integration cannot support the intended step.
5. Review execution and business effect separately
Finding a correctly assigned task confirms an operational result. It does not yet tell us whether the account review was useful or whether the customer’s buying behaviour changed.
Define the follow-up before approving the action. The account owner might record whether the ordering change was explained, whether another action was agreed and when it should be reviewed. Later, the team can examine ordering activity over a period suited to that customer’s normal rhythm.
The original definition matters here too. If the first finding counted confirmed orders and the later review counts invoices, the comparison has changed. Keep the measure and observation period explicit. If a new definition is needed, record it so that the next person can understand the difference.
Even when ordering resumes, the sequence alone does not establish that the task caused it. The customer may have been ready to reorder anyway, or another interaction may have mattered. Record what was observed and what the account owner learned. A stronger claim about impact needs evidence designed to support that claim.
This gives the team two useful conversations. First: did the agreed work reach the right person in the right form? Then: what did we learn about the account, and what should we do with that knowledge? The second conversation is the reason to keep the finding, the action and the follow-up connected.
6. Keep enough context to use the workflow again
A recurring account review becomes easier to assess when the team can revisit its definitions and earlier decisions. Which purchasing patterns were meaningful? Which accounts were excluded? What information helped the owner understand the task? Which exceptions required a person to intervene?
DUKE’s published approach connects analysis, verification and approved operational steps. [1] The useful question for an evaluation is how that continuity works for your own case: what can be reused, what stays linked to the finding and what the team must review again. Product availability and supported integrations must be confirmed for the intended setup; this article does not establish them.
For the account example, ask to see the path from the analytical finding to the proposed task and its execution evidence. Then inspect how the result will be reviewed. An illustration can make the method understandable; a demonstration with the intended integration establishes what that particular setup can do.
Start with one action your team can describe
Our ACT Action Brief brings this discussion into a practical worksheet. It covers the finding and proposed action, the approver and owner, the supported integration and permissions, the evidence checks, the execution and outcome review, and the route for corrections or exceptions.
Complete it with one real workflow. Name the finding, choose the operational step and agree what you need to see before approving it. Bring the account owner and the person responsible for the relevant data into the discussion where their input is needed.
Evaluate that workflow with the DUKE Analytics team. Bring the business question, the tools involved and the action you would like to assess. Together, establish the supported scope and the evidence needed to judge the result.