Skip to content

Customer-Managed Production Runs

Summary

We have identified a customer need for a more flexible operating model: customers want to create and manage their own production runs, while still staying inside the commercial boundaries we define.

The key requirement is that customers must not be able to extend tracker usage outside the period they have purchased. In other words, they can organise trackers for their own operational needs, but they cannot move trackers beyond the entitlement window we sold them.

Business Problem

Today, tracker assignment is controlled by creating production runs and campaigns on behalf of the customer. That works for fully managed deployments, but it becomes restrictive when customers want to manage their own operational workflow.

The risk is that, if customers can freely control run dates, they could use the system to extend tracker lifecycles beyond the period they paid for.

This creates two problems:

  1. Commercial leakage if tracker usage is extended beyond the purchased term.
  2. Ambiguity in reporting if one customer can move devices between separate purchases.

Proposed Model

The recommended approach is to introduce a parent entitlement batch that represents the paid commercial boundary, and allow the customer to create child production runs within that boundary.

Parent Entitlement Batch

The parent batch is created by us and owns the commercial rules:

  • Fixed start date
  • Fixed end date
  • Purchased tracker entitlement
  • Customer ownership
  • Controlled lifecycle status

This parent batch is the thing the customer has bought.

Customer Production Runs

Customers can create their own production runs underneath that parent batch. These runs are for operational convenience and internal planning only.

Customers can control:

  • Run name
  • Operational grouping
  • Tracker assignment within the batch
  • Reuse of trackers within the same batch window

Customers cannot control:

  • The parent batch start date
  • The parent batch end date
  • Tracker movement outside the batch boundary

Operating Rules

The rule set should be straightforward:

  • Trackers may move freely between runs inside the same parent batch
  • Trackers may not move into a different batch if that would extend their paid lifecycle
  • If a customer buys a second batch later, that is a new entitlement, not an extension of the first
  • Reuse of a tracker is allowed only while it remains inside the same batch window

This allows flexibility for the customer without creating a loophole that lets them stretch paid usage across multiple purchases.

Why This Works

This model gives each side what they need:

  • Sales keeps a clear commercial unit to sell
  • Project management gets a predictable entitlement structure
  • Customers get enough control to manage their own runs
  • The system keeps a hard boundary around paid tracker usage

It also avoids a naming problem. If both the parent and child are called a "production run," users will eventually confuse them. Separating the commercial batch from the customer-managed run makes the product easier to explain and support.

To keep conversations clear, we recommend:

  • Parent batch for the purchased entitlement
  • Customer run for the customer-created operational grouping

If the product team prefers to keep the term "production run" for the customer-facing object, that is fine, but the commercial boundary should still have a distinct name.

Examples

Example 1: One Batch, Multiple Runs

A customer buys a batch covering a defined date range. Within that range, they create several runs for different operational phases. Trackers can move between those runs as needed, as long as everything stays within the same batch.

Example 2: A Second Purchase

The same customer later buys a second batch. That second batch starts a new entitlement window. Trackers from the first batch should not be moved into the second batch in a way that extends the original commercial agreement.

Example 3: Reuse After Recovery

If a tracker is recovered and reused during the same batch window, that is acceptable. The system should treat that as reuse within the existing entitlement, not as a new commercial period.

Decisions Needed

Before implementation, we should confirm:

  • Whether the commercial unit is tracker count, tracker-days, or both
  • Whether the customer-facing label should be "production run", "campaign", or "customer run"
  • Whether cross-batch tracker movement should be blocked entirely or allowed only by admin action
  • How reuse of physical devices should be represented in reporting

Recommendation

Use a parent entitlement batch as the commercial boundary, and let customers create child runs inside it. That gives customers the flexibility they want while preserving the limits we need for billing, reporting, and lifecycle control.