Overview
Every Drum project has a default rate card, and by default, every deliverable in that project bills staff time against it. Some work, though, doesn't fit the default a certain type of deliverable might need to be billed at a different rate than the rest of the project. Deliverable-based rate cards exist for exactly this: they let a single deliverable carry its own billing rate while everything else in the project carries on as normal.
The Relationship at a Glance
A deliverable rate card doesn't replace the project default it sits alongside it, and only takes over for the one deliverable it's assigned to. The chain below shows how that override flows down to the time staff actually log.
Project Default Rate Card applies to every deliverable, unless overridden |
↓
Deliverable With a Custom Rate Card an override, scoped to this one deliverable |
↓
Tasks Within That Deliverable Everything logged inside it inherits the override |
↓
Staff Time Bills to the Deliverable's Rate Card not the project default |
Understanding the Behaviour
Why can a deliverable have its own rate card?
Because not all work in a project is billed the same way. Rather than splitting work into a separate project or changing the rate for everyone, a deliverable-level rate card lets you carve out just the billing for one piece of work, while the rest of the project keeps its existing rates.
How is a deliverable rate card different from the project default?
The project default is the baseline every deliverable uses automatically. A deliverable rate card is an override that applies only to the specific deliverable it's assigned to it doesn't alter the project's default setting, and it doesn't apply anywhere else in the project.
Which time uses the custom rate card?
Only staff time logged against tasks that live inside the deliverable the custom rate card is assigned to. Time logged on any other deliverable in the same project still follows the project default, or whatever rate card that deliverable has been given.
What happens to other deliverables?
Nothing. Every other deliverable in the project keeps billing against the project's default rate card, unless it's also been given a custom rate card of its own. Assigning a rate card to one deliverable has no effect on any other deliverable, and it doesn't change the project's overall default.
What happens to previously logged time?
It stays exactly as it was. A rate card change only applies going forward time that was already logged and billed keeps the rate that was in effect at the time, regardless of any change made afterward.
Why is the inline rate card label useful?
It's a visible signal that a deliverable is running outside the project default. Any deliverable using a different rate card shows that card's name next to its name, so anyone reviewing the project can immediately tell which deliverables are billing on custom rates without having to check each one individually.
Key Takeaway
A deliverable rate card is a scoped override, not a project-wide change. It affects only the deliverable it's assigned to and the time logged within it everything else in the project, and everything logged before the change, stays exactly as it was.