Beginner's question: What exactly counts as a 'task' versus an 'activity'?

That's a great test. It shows the billing logic might be completely detached from what you see in the UI.

Makes me wonder, does the same logic apply to escalations that are automated versus ones triggered manually? Like if a task expires vs. a manager forcing it to a new queue.

That's an excellent distinction to bring up. In the systems I've reviewed, automated escalations on a timer are almost always a billable event, treated as a new assignment. A manual reassignment by a manager *might* be, but it often depends if it's considered a new "work item" or just a routing change on the existing one.

The only reliable way to know is to include both scenarios in your test workflow. Sometimes the vendor's own support team isn't clear on the difference until they have to trace the specific log entries for your test bill.

I've seen that exact confusion on support calls. They'll say "a reassignment is just a routing change" until you point out the usage report line item timestamped exactly when the manager dragged the task.

It often comes down to whether the system creates a new database record. If it does, it's likely a new billable unit. The test needs to include both UI actions and API calls, since they can trigger different logic.

Oh, you sweet summer child, asking for a simple explanation from their marketing page. That's like asking for the secret recipe from the back of a ketchup bottle.

In your vendor onboarding example, here's the cruel joke: an "activity" is that tidy little box on your flowchart labeled "Approve Contract." A "task" is what the billing engine spits out when that box actually runs. If that approval goes to a committee of three people, you just bought three tasks for the price of one activity.

The pricing page can't tell you this because their own sales engineers often need a forensic accountant to explain the bill. Build your test process, run it with dummy data, and then stare directly into the soul-crushing abyss of your usage report. That's the only definition that matters.

You're spot on that the UI can't be trusted to reveal billing logic. That gap is the core of the issue.

I've seen cases where the UI shows three distinct items for a committee approval, but the billing report lists one "batch" task at a higher unit cost. So even visible separation isn't a guarantee.

Your test addition for escalations is crucial. The real cost often isn't in the initial setup, but in the churn - reassignments, approvals, and revisions. A static test won't catch that. You need to simulate the messy reality of a process actually running.

Yep, that "batch" task scenario is a classic trap. It looks cheaper until you realize their batch rate is 5x the unit cost, so you pay more for the "single" item.

The worst I've seen is when the churn itself creates a new batch. Ten reassignments on the same work item gets logged as one batch of ten tasks, billed at the premium batch rate again. Your test needs to simulate volume over time, not just a single instance.

Don't bother with their definitions. They're meaningless. The only thing that matters is what shows up on your bill after you run a real test.

For your vendor onboarding example, create a simple workflow: "Request Approval" (one activity). Send it to three approvers. Check your usage report. Is it one line item or three? That's your answer. I've seen it go both ways.

Then break it. Reassign it, escalate it, loop it back. See what new charges appear. The cost is always in the execution churn, not the pretty diagram.

Exactly. That conditional logic trap is a perfect microcosm of the whole problem. The billing engine isn't looking at your business logic, it's listening for the `POST /task` call. When the workflow hits that conditional branch, the engine fires another create event. Doesn't matter if it's the same human, same data, same universe. New record, new line item.

I've had to trace logs where the only payload difference between the "standard" and "priority" task was a single `priority: true` key. Cost us a 20% upcharge per instance because their system treated it as a distinct task *type*. The support ticket resolution was, essentially, "the system is working as designed."