Define a B2B pilot expiry policy before building it

A pilot end date looks simple in a proposal. It becomes several product decisions when one customer needs an extension, another wants its reports, and an export finishes after access closes.

Agree those decisions before estimating the first release. A useful policy specifies which actions remain available, the exact cutoff, who can approve an exception and how the team will demonstrate that the rules work.

The worked example below translates a pilot agreement into observable outcomes. It is deliberately narrow: commercial expiry and exceptions. Tenant isolation, payment integration and general launch readiness require their own controls.

One pilot, two companies, explicit boundaries

Here is a hypothetical agreement for an equipment inspection product. These dates and rules are assumed for illustration, not customer terms or legal advice. Two companies pilot the same inspection workflow. The product owner approves scope; the commercial owner alone approves extensions.

The pilot runs from 1 December 2026 at 00:00 UTC until 1 January 2027 at 00:00 UTC, with the end instant excluded. During that interval, authorised inspectors can create, revise and submit inspections. Administrators can read and export their company's records. After expiry, inspectors cannot create or change records; administrators retain read and export access until 8 January at 00:00 UTC. After that instant, interactive access closes. Data retention and deletion require a separate agreed schedule; loss of login access is not evidence of deletion.

31 December, 23:59:59 UTC

Expected outcome: In-scope inspection write can be accepted.

Release evidence: Test uses the server's agreed commit-time rule, not the user's device clock.

1 January, 00:00 UTC

Expected outcome: New writes fail; administrator can still read and export.

Release evidence: Boundary tests cover both allowed and denied paths.

Approved exception for company A

Expected outcome: Commercial owner extends A's write deadline to 3 January, 00:00 UTC; export deadline remains 8 January.

Release evidence: Approval record names company, reason, approver, effective time and exact expiry; company B remains unchanged.

Export queued before 8 January but delivered afterward

Expected outcome: Delivery fails under this example's policy; a documented support export requires separate approval.

Release evidence: Worker checks permission at delivery, and support can explain the denial.

8 January, 00:00 UTC

Expected outcome: Interactive read and export access closes for both companies.

Release evidence: Controlled-clock tests verify the exact cutoff and the approved support procedure.

An extension approved after access has closed restores access only from its recorded effective time. It does not backdate permission or authorise previously rejected writes. Expiry is evaluated by the application; a scheduler running late must not silently extend it.

For this two-company scenario, manual invoicing means two initial policy entries and an explicitly approved exception, each checked by an operator. Those counts describe this example, not an effort estimate. The failure case is concrete: if the operator extends the export deadline instead of the write deadline, the customer's inspection remains blocked while access lasts longer than agreed. Review the changed fields and exercise the boundary before accepting the exception.

Automated billing can reduce repeated administration once commercial rules stabilise, but it introduces event handling and reconciliation work. Choose it when repeated billing changes justify that work. Do not make subscription automation a prerequisite for a manually invoiced pilot.

A request for a configurable workflow builder during this pilot is a scope decision. Ask whether the two customers can complete the agreed inspection without it. If they can, defer it. If they cannot, replace or renegotiate the acceptance condition and estimate the change before treating it as included work.

Decide what automation is buying

For the example above, the minimum operating record has separate write and export deadlines for each company, the approval authority and a history of exceptions. A spreadsheet can document the agreement, but it should not be mistaken for application enforcement. The person administering the policy needs a controlled way to apply and verify it.

Before automating invoicing, decide whether payment state should change this agreement at all. A manually invoiced pilot might require commercial review before any restriction. An automated subscription needs a defined rule for payment failures and cancellations. Stripe's subscription documentation describes these changes as asynchronous events. Receiving an event supplies information; the product still needs the agreed policy for interpreting it.

The decision is operational. With two stable pilot accounts, a reviewed manual process may be sufficient. With repeated renewals and exceptions, its checking burden may justify automation. Record the actual number of changes, correction effort and failure consequences before choosing. No universal account-count threshold follows from this example.

Make acceptance evidence reproducible

Use synthetic customer records and a controlled clock to exercise all five acceptance cases. Record the policy version, application version, test instant and observed read, write and export outcomes. Include the exception for company A and verify that it leaves company B unchanged.

A request started before expiry but committed afterward needs an explicit rule. This example evaluates write permission at the server-side commit boundary. The implementation must enforce that decision consistently, including retried work. If that is impractical for the chosen architecture, agree a different observable boundary and update the example's acceptance cases before sign-off.

Keep commercial approval separate from test execution. The commercial owner accepts the exception; engineering demonstrates the resulting behaviour. Neither an approval email nor a passing login test alone proves the policy is implemented.

These cases are an engineering scope aid, not a contract template or evidence of compliance. Retention, deletion, security and recovery remain separate requirements. Nothing here demonstrates a real customer outcome or a tested software implementation.

Use the policy to sharpen the build proposal

Bring the pilot terms, expiry rules and unresolved exceptions into the MVP development scoping conversation. They help distinguish included behaviour from a later change and give both the buyer and delivery team a concrete basis for acceptance.