# How we stay one step ahead of contract renewals Every day, a Machine agent finds accounts 90, 60 and 30 days from renewal, builds a packet on usage and value, drafts the outreach, and flags any at risk so the account owner can review. Canonical page: https://themachine.myapps.ai/use-cases/renewal-manager We used to find out about renewals the way you find out about a parking ticket: too late to do much. An account owner would open HubSpot, spot a contract ending in three weeks, and begin from scratch. Dig up usage. Try to recall what had shipped since the last call. Take a guess at upsell room. Write the email that same afternoon. The renewals that went well were the ones somebody happened to check in time. The ones that slipped away quietly were mostly the ones nobody opened until all that was left was an apology. Now an agent on Machine watches the renewal date on every HubSpot deal and moves early, at 90, 60 and 30 days out, with the packet built and the email drafted. It never sends anything and never touches pricing. The account owner gets a running start instead of a looming deadline. - **Team:** Machine - **Runs on:** A cron once a day - **Connected systems:** HubSpot · Google Calendar · Slack · Email - **Mode:** Prepares and drafts only · the account owner hits send ## The problem A renewal date on a HubSpot deal is just a number on a calendar. It can't tell you if the account is in good shape, if the customer really uses what they paid for, if there's an obvious upgrade to bring up, or if the deal has gone silent in a way that ought to worry you. That story is spread across old notes, someone's memory of the last QBR, and whatever the owner can piece together in a hurry. The usual backstop is a calendar reminder, or a pipeline report sorted by close date. It's a bare list with no homework behind it. By the time the owner digs in, the renewal is near, there's no packet, and the email gets dashed off instead of built around what this customer actually needs to hear. ## What we built Once a day, a cron on Machine starts an agent that reads the renewal date on every HubSpot deal and picks out the ones hitting 90, 60 or 30 days to go. For each, it assembles a renewal packet: the usage and value the customer has had since they last renewed, plus one or two specific ideas for growing the account. It looks at Google Calendar to see if a renewal call is already booked, and it drafts the outreach email. Accounts that seem stuck, silent or shrinking get their own at-risk flag. The packet and draft wait for the account owner. Nothing leaves by itself. ## How it works ### Start once a day A **cron trigger** kicks off the agent daily. Each run gets a new **session**, a fresh cloud computer set up just for that run, with no memory of the day before. The list of deals and every signal are read fresh from HubSpot. A property on each deal records which renewal window it has already been flagged for, so an account sitting inside 90 days doesn't get a new packet every single morning. ### Hand it the renewal playbook A **skill**, the playbook the agent carries, spells out what goes in a renewal packet, how to read usage and engagement as signs of health, what counts as at-risk, and the way our team words renewal outreach. When we figure out what really tips a renewal, we update the skill, and every account gets the benefit the very next day. ### Connect HubSpot and Google Calendar Scoped **connectors** link the agent to each system. Machine keeps the tokens on its own servers, so the model never sees one. With them the agent: - **Reads deals in HubSpot.** Renewal dates, contract value, stage history, notes and past activity, so it can find each account entering a 90, 60 or 30 day window and notice the ones going silent. - **Reads Google Calendar, and only reads.** It checks whether a renewal or QBR meeting is already booked close to the renewal date, so the email can mention it rather than ask for a second one. - **Writes one thing back to HubSpot.** The window it last flagged for each deal. Never the stage, never the amount, and nothing else a rep relies on to track the real negotiation. ### Post to Slack, draft the email Each channel has its own job. In **Slack**, the account owner gets the day's renewal radar and any at-risk flags. In **email**, they get a draft holding the renewal packet and the outreach text, waiting for them to open, edit and send. ### Draw the lines The agent prepares and drafts. It never reaches out to a customer and never goes near price. Sending the email is beyond it, and so is applying, offering or even hinting at a particular discount. Talk of pricing belongs to the account owner. Credentials are stored encrypted in the Secrets Manager, added at run time, and only handed to the agents you grant them to. ### Pass over the packet The result: the account owner opens Slack to a ranked list of what's coming due and what looks shaky. Then they open their inbox to a drafted email that already tells the usage story, lists what's been delivered, and suggests an expansion idea worth bringing up. They read it, adjust it for the relationship, and send it themselves. > **The pattern** > Once a day a **cron** opens a session with reading connectors into HubSpot > and Google Calendar. A **skill** holds the renewal playbook. The agent > builds the packet and drafts the outreach, and the account owner reviews, > edits and sends. ## Guardrails These accounts carry revenue, so what the agent may do is spelled out and kept small: - **It prepares and drafts, that's all.** It never sends the renewal email, and it never makes or moves a calendar event. The email sits as a draft in the owner's inbox until the owner sends it. - **Pricing is off limits.** It never applies, offers or suggests a specific discount or credit. Anything about price is for the account owner to discuss, not for a draft to state. - **Tiny writes.** All it writes back to HubSpot is which renewal window a deal has been flagged for. The stage, the amount and the pipeline stay untouched. - **Kept apart.** Each run gets its own sealed-off sandbox. The HubSpot and Google Calendar credentials are stored encrypted in the Secrets Manager, added at run time, and only handed to the agents you grant them to. - **All of it lives in code.** The renewal playbook, the at-risk rules and what each system lets it do are files in the repo. They're versioned, and you change them with a reviewed **change request**, not a setting on a dashboard. ## The outcome - **90/60/30:** Days ahead that an owner first gets a ready packet, not a fire drill - **Every day:** Renewals and at-risk flags worked out again from live HubSpot data - **0 sent:** Emails or discounts the agent ever sends or applies by itself Renewals no longer begin with an empty page. They begin with the packet assembled and the email drafted, so the owner's first job is reading, not rushing. The agent keeps an eye on every deal and does the legwork. A person still chooses what to say and when to hit send.