From scattered renewal timing to one HubSpot task

Every active customer is evaluated into one of two states:

• At-risk renewal: renewal timing has been found and the renewal is inside the configured alert window (or overdue), and no mitigating action is already in motion.
• No active risk: no renewal at risk right now, or action is already happening.

Renewal timing is the primary signal. An activity check (replies, meetings, tickets, contact activity) supports it. When no renewal timing can be found anywhere for an active customer, Sighub falls back to an activity-only check for that customer, with lower confidence and clear labeling in the card.

Before any renewal check runs, each company is tested for scope. A company is considered active and in scope when at least one of the following is true:

• Lifecycle stage is "customer." This is the primary scope condition.
• Lifecycle stage is "evangelist" with an active contract. Evangelists with renewal timing detected are treated the same as customers.
• Recently closed-won. A company associated with a closed-won deal in the last 90 days is in scope even if the lifecycle stage has not yet been updated to "customer."
• Post-expiry grace period. If a renewal date has already passed, the company stays in scope for 30 days. This prevents recently churned accounts from silently dropping off the queue.

Companies outside these conditions — prospects, leads, subscribers without active contracts — are excluded automatically. No extra configuration is needed.

Renewal dates rarely live in one clean Company field. Sighub looks for renewal timing across HubSpot objects associated with each active customer:

• Company properties (mapped contract end / renewal date, if present)
• Deals (close date, renewal-type deals, deal stages)
• Deal line items (term start, term end, recurring billing dates)
• Quotes (expiration and effective dates)
• Subscriptions (next billing date, end date)
• Custom objects you use to track contracts or renewals

Whatever combination of these your portal uses, Sighub joins them at the company level and reasons over the earliest binding renewal date it can defend with evidence.

Before any risk is opened, Sighub applies a few guardrails:

• Active customers only. Churned, non-renewing, or out-of-scope accounts are excluded.
• Action already in motion? If a meeting is booked before the renewal, the deal is advancing, or a recent inbound reply suggests the conversation is happening, severity is lowered or the risk is suppressed.
• Thin data? Sighub holds back rather than create noise.

A renewal is "active" when its date is within the configured renewal window (30, 60, or 90 days; default 60) or already overdue.

Severity bands

• Critical: the renewal is overdue, or within about 7 days with no recent customer contact, or a renewal deal was closed-lost.
• High: the renewal is within 14 days, or within 30 days with no meeting scheduled before the renewal date.
• Medium: the renewal is within the window, but a mitigating sign is present (a booked meeting, an advancing renewal deal, or recent customer contact), or it is simply further out in the window.

A meeting booked before the renewal, or an advancing renewal deal, lowers severity. Several open tickets near the renewal can raise it. Both high and critical are treated as high-urgency and create a HubSpot task; medium does not. See Tasks.

Activity is a supporting check, used to confirm or mitigate a renewal risk. Only when no renewal timing exists anywhere for a customer does the activity check run on its own, with lower confidence. In that mode it is shown as Engagement Risk, and if it reaches high or critical severity it creates a "Sighub: Reactivate account engagement" task. The engagement thresholds (reply-staleness, high and critical day counts, and the open-ticket count) are configurable in the Sighub settings.

"Activity" is the most recent of:

• Company hs_last_logged_call_date
• Last associated meeting timestamp
• Associated contact hs_lastactivitydate
• Last inbound email reply timestamp

An "inbound reply" is an associated email whose direction is INBOUND/INCOMING (or whose status indicates REPLY while direction is not OUTBOUND). A "future meeting" is any associated meeting with a timestamp in the future. Open tickets are detected by status: a ticket is considered open unless its status contains "CLOSED" or "RESOLVED".

How activity is used:

• Future meeting before the renewal date lowers severity, because action is already in motion. Sighub does not raise a task when the conversation is already booked.
• Stale inbound reply before the renewal date is added as supporting evidence on the task body. The reply-staleness window defaults to 28 days and can be changed in the Sighub settings (15–90 days).
• Open tickets near the renewal date strengthen the case for high severity. A ticket is considered open unless its status contains "CLOSED" or "RESOLVED."
• Recent inbound reply (within 28 days) indicates the customer is engaged and reduces the urgency signal.

Every decision carries a data tier that tells you where the renewal timing came from. The card labels low-confidence states clearly, so you always know how much to trust an alert:

• Tier 1 — mapped contract date. Renewal timing comes from your mapped Company property. Highest confidence.
• Tier 2 — deal fallback. Renewal timing comes from an associated deal (close date or renewal deal). Medium confidence.
• Tier 3 — activity only. No renewal timing found anywhere. Sighub runs the activity check on its own, with lower confidence.
• Tier 4 — no data. Nothing usable. Sighub holds back rather than guess; the card shows that data is insufficient.

Risk is driven by HubSpot data, but you can override it when you know more than the data. From the Sighub card you can snooze a risk for 14 days, mark an account healthy for 90 days, record a Renewed or Lost outcome, and undo any of these.

See Risk controls for the full behavior.

• No health score. No black-box AI. No churn prediction model.
• No reading of message content.
• No real-time webhooks. Scanning is periodic with manual refresh.