Retention and renewal: connect the support history to the next promise

A renewal email can look perfectly polished while ignoring an unresolved customer problem. For a solo founder, the challenge is remembering the account's full history at the moment a new commitment is discussed. The platform should assemble that history and make the next decision explicit.

This walkthrough joins Issue-to-Resolution and Lead-to-Cash. The current support prototype has customer-health states and churn alerts. The contract assigns renewal ownership to sales. The durable scheduler, live account signals and complete renewal orchestration are still to be connected.

Health is a summary with evidence underneath

The prototype models green, amber and red customer-health states. A state change should point to the facts that justify it: repeated unresolved issues, missed delivery expectations, declining usage or a direct customer concern. A red badge without evidence simply relocates the founder's uncertainty to a dashboard.

For the example studio, consider a customer whose search pilot is technically delivered but difficult to use. Two support tickets ask how to interpret citations. The account may need training or a UI change before a subscription conversation makes sense. The agent can collect those facts and prepare options; it should not infer the customer's intention to cancel solely from ticket volume.

{
  "account_id": "account-017",
  "health_band": "amber",
  "reasons": ["two unresolved citation-usability questions"],
  "evidence_refs": ["ticket-041", "ticket-048"],
  "next_review": "after training session",
  "proposed_action": "prepare_account_review"
}

This is a proposed operator-facing projection over the support and agreement records. The examples use fictional accounts.

Renewal is a new commercial decision

A due-date trigger should create a renewal review, not silently extend an agreement. The review needs the current offering, accepted price, renewal terms, usage, support obligations and unresolved exceptions. If the customer asks for a new capability, the commercial workflow should treat that as scope rather than hide it in a retention message.

The ownership boundary matters: support maintains issue and account-health evidence; sales owns the quote and renewal lifecycle; finance confirms payment; delivery accepts changed obligations. Having all four agents overwrite a renewal_status field would destroy the benefit of a shared model.

Suggested actions must be bounded

A retention agent can draft a summary, propose a meeting, recommend a service credit or suggest a different package. The discount, credit and contract change each need their own action policy. They should not share a generic “save customer” permission.

I would start with a weekly review queue. Each item includes the account's next decision, evidence age, open issues, commercial deadline and a suggested communication draft. Urgent contractual deadlines can use an event-driven path later. The first experiment does not need a constantly running account-management agent.

Avoid three tempting shortcuts

First, do not treat a sent message as a retained customer. The outcome might be a renewed agreement, a resolved issue or an explicit decision not to renew. Each is a different event.

Second, do not attribute every renewal to the assistant. A longstanding relationship, the product and the founder's direct conversation can all matter. The platform can report the administrative work it handled and the recorded outcome without claiming causal credit it cannot establish.

Third, do not present a guessed health score as a probability. A red state can mean “review required” without pretending it means “83% likely to churn.” A calibrated prediction would require its own labelled dataset and evaluation.

The next executable slice

I would connect one renewal trigger to an account-review record, populate it from support history, and require approval before a commercial message is sent. A delayed or duplicate trigger should reuse that review, not create another renewal opportunity.

The useful tests are concrete: an unresolved critical issue must appear in the review; a changed agreement invalidates the old draft; a duplicate scheduler event creates no second opportunity; and a confirmed non-renewal stops the reminder sequence. This sub-loop is successful when the founder sees the right conversation at the right time with the relevant history already assembled.

Start from the renewal decision, then gather context

For a small software subscription, a renewal agent can easily become an enthusiastic upsell generator. I want a more useful sequence: establish what was purchased, whether it was delivered, whether it is being used, whether material issues remain open and whether there is an unpaid balance. Only then prepare the commercial next step.

The reference decision table expresses that ordering:

from company_lab.business import renewal_action

assert renewal_action(
    days_remaining=14, open_critical=True,
    unpaid_minor=0, accepted_usage=True,
) == "RESOLVE_ISSUE"
assert renewal_action(
    days_remaining=14, open_critical=False,
    unpaid_minor=0, accepted_usage=True,
) == "DRAFT_RENEWAL"

This is an example policy, not a learned churn predictor. An unpaid balance may be a provider reconciliation problem rather than unwillingness to pay. An open issue may be inconvenient or genuinely blocking. The follow-on task needs the underlying evidence, not merely the label returned by the function.

Define usage in terms of the customer's promised outcome

For the document-search pilot, useful usage might mean that the two agreed reviewers completed their evaluation questions and followed citations successfully. Raw login count is weak evidence. A daily active user metric can rise because users keep retrying a broken workflow.

I would join accepted scope, delivery evidence, successful task events and support history by commitment identity. The resulting renewal packet includes observed outcomes, missing adoption steps, unresolved issues, contract dates and proposed changes. Each observation has a time window. Last quarter's healthy usage should not silently stand in for this month's data.

A practical packet might say:

Both reviewers completed the agreed evaluation. One source-format issue remains open and affects a third document type outside the pilot. The customer asked about extending coverage. Prepare a scope discussion after confirming the issue's impact; do not promise the extension in the renewal email.

This keeps the conversation grounded in the product actually delivered.

Connect the support desk, product events and commercial system

The support connector should provide issue identity, severity, current state and relevant customer impact. The product event stream should report successful task outcomes under a versioned metric definition. The commercial system supplies expiry, accepted terms and named account owner. None of those systems should independently overwrite a global health score without retaining its evidence.

I would store health as a derived assessment with inputs and version, so it can be recomputed. For example, “amber because two critical workflows failed in the last seven days” remains understandable after the thresholds change. A bare numeric score cannot explain its own history.

An account manager's correction is also data: perhaps the customer is intentionally inactive during a scheduled shutdown. The correction should annotate the interpretation, not delete the observed events. The next evaluator can then check whether the agent used the exception correctly.

Prevent duplicate commercial contact

A renewal task and a collections task can both wake for the same customer. Without coordination, one agent asks for payment while another offers a discount and a third sends a cheerful check-in. Introduce a customer communication plan containing active purpose, responsible workflow, proposed messages and minimum spacing chosen by the business.

The scheduler can ask for review when the purposes conflict. It should not give the highest-priority agent unrestricted ownership of the customer relationship. A support incident may temporarily suppress routine renewal outreach, while a contractual expiry still remains visible to the founder.

Test renewal as a changing situation

The useful cases include a recently resolved complaint, an unresolved complaint hidden by positive sentiment, partial payment, a customer who moved to a new organisation and an expiring agreement with no current usage data. Correctly asking for a missing fact is an acceptable outcome.

The first experiment should compare prepared renewal packets with the founder's actual decision and time spent collecting context. Track revisions to terms and unauthorised promises separately from prose quality. Renewal is a new commitment, so the quote and approval mechanics from the sales loop apply again.