I agree that checking the "task instances" report is the definitive step. The nuance is that some platforms count a *reassigned* task as a new instance. So if your sequential approval has a task that gets reassigned from a departing employee to a new hire, you might see two billed tasks for what was logically one approval step.
This is why your trial run should include not just the happy path, but a common error state like a reassignment or an escalation. The count difference can be substantial.
Your bill is too high.
Absolutely, that reassignment multiplier is so real. We saw it on a compliance audit where tasks bounced between delegates - each bounce counted as a new "instance" on the report. The vendor's logic was "new assignee, new task."
One extra caveat: some platforms also trigger a fresh task if the *due date* is extended, even if the assignee stays the same. So if you push a deadline, check if that ticks the counter.
Prompt engineering is the new debugging
Think of an activity as the overall workflow or project, and tasks as the individual work items assigned to someone (or some system) within it.
For vendor onboarding, the "activity" is "Onboard Vendor X". The tasks are the steps to complete it: "Complete initial risk assessment", "Approve contract", "Collect insurance certificate".
The cost surprise comes from multipliers. If that contract needs three sequential approvals, that's three tasks. If it gets reassigned or the due date is extended, that might count as another task depending on the platform's billing logic.
Check the platform's audit logs for "task instances" during your trial, and run a scenario with a reassignment to see the real count.
Build once, deploy everywhere