A prospect who says “come back to me in two years” is not rejecting you, they are handing you a scheduling problem. Left to manual follow-up, that problem loses. Reps change roles, CRM task lists fill with nearer-term work, and the context of the original conversation (the objection raised, the budget cycle mentioned, the competitor already shortlisted) evaporates long before the two years are up. Make.com turns that scheduling problem into a structured, auditable workflow that survives staff turnover, does not rely on anyone’s memory, and gets sharper each quarter instead of going stale.
Why Long B2B Sales Cycles Break Manual Follow-Up
Most CRM task and reminder systems are built around a short horizon. HubSpot and Salesforce both surface upcoming tasks in day-and-week views by default, and by the time a task set two years out actually comes due, it is buried under thousands of nearer-term reminders created since. Worse, most CRMs tie a task to a specific owner record rather than a queue or a role. If the rep who set the reminder has since left, changed territory, or moved teams, the task often becomes invisible to anyone else, even though the account itself is still live.
There is a second, quieter failure: information decay. A rep’s notes from the original call (“evaluating in Q3 2028, budget currently allocated to a competitor, CFO wants a fresh valuation before renewal”) sit as free text in an activity log. Free text cannot trigger anything. Unless that context is captured as structured CRM properties at the point of disengagement, there is nothing for an automation platform to act on later, and the account effectively goes dark until someone happens to reopen the record.
Mapping the Two-Year Re-engagement Scenario
Before any workflow gets built, the sales team needs a discipline around what gets recorded and how. That means capturing, as dedicated CRM properties rather than paragraphs of notes, at minimum: the re-engagement date, the reason for the delay (budget, internal restructuring, contract lock-in with an incumbent), the specific objection raised, and the stakeholder’s role. A property such as “re-engage in 24 months” set on a dropdown or date field is something an automation platform can query. A sentence buried in a call note is not.
This is also where segmentation starts. An account manager selling into regulated financial services will want to treat a compliance officer differently from a CFO evaluating cost. Mapping those segments at the point of disengagement, rather than trying to reconstruct them from scratch two years later, is what makes the eventual automation scalable across hundreds of similar accounts instead of being a one-off manual exercise for each one.
Building the Workflow in Make.com: A Step-by-Step Walkthrough
Make.com’s strength for this use case is its module-based architecture: a scenario is built from discrete steps (a trigger, a router, one or more action modules, a data store) that can be tested and adjusted independently rather than as one monolithic script. That matters over a two-year timeline, because the content and cadence will almost certainly change before the cycle ends, and you need to be able to edit one module without rebuilding the whole scenario.
Step 1: Sync CRM Fields and Tag Long-Cycle Contacts
Connect Make.com to your CRM (HubSpot, Salesforce or Pipedrive all work) so the properties captured in the mapping stage, re-engagement date, objection, segment, are read directly rather than duplicated into a second system. Duplication is where these workflows usually rot: a value updated in the CRM but not mirrored into the automation tool means the scenario is acting on stale data. Equanax has recorded an 86 percent reduction in fixable sync errors on engagements where field mapping between CRM and automation platform was treated as a defined, owned task rather than a one-time setup step.
Step 2: Trigger on a Field Change, Not a Polling Scan
There are two ways to start this scenario: have Make.com poll the entire CRM database daily to look for contacts whose re-engagement date has arrived, or have the CRM push a webhook to Make.com the moment a relevant property changes. Polling is simpler to set up but wasteful: every daily run consumes Make.com operations scanning records that have not changed, which adds up across a database of any size. A webhook triggered by the CRM (for example, a HubSpot workflow action that fires when a contact’s re-engagement date matches “today”) only invokes the scenario when there is genuinely something to do. HubSpot’s own developer documentation covers the webhook and workflow actions that make this possible.
Step 3: Route Content by Segment with a Router Module
Once triggered, a Router module splits the scenario by the segment property captured earlier, sending, say, regulatory updates down one path and cost-efficiency benchmarks down another. This is the single biggest lever for relevance: without it, every long-cycle contact receives an identical quarterly email regardless of role, which is the fastest way to train a CFO or a compliance lead to stop opening your messages.
Step 4: Log Every Send Back to the CRM
Every action module that sends content should be paired with a module that writes the send, and later the engagement result, back to the CRM timeline. Skip this step and you get a common and avoidable failure: a rep, unaware the automation has already sent a quarterly report, manually reaches out with the same content, and the prospect receives duplicate outreach from two apparently uncoordinated parts of the same company.
Personalising Engagement Without Manual Effort
Personalisation here is not a first-name merge field, it is content that changes shape depending on who is reading it. A router split by segment gets you halfway; the other half is making sure each branch delivers something genuinely different, not the same report with a different logo. A compliance-focused contact wants regulatory movement since the last contact; a CFO wants a refreshed valuation or cost benchmark; a broker wants distribution or margin data. Document automation tools such as PandaDoc can assemble these from CRM fields at send time, so the content is generated rather than hand-written for every recipient, while still varying by role.
Treat each quarterly send as a small trust deposit rather than a pitch. A vendor who reliably delivers the same useful update every quarter for two years, without asking for anything in return until the prospect signals readiness, is in a materially stronger position when the conversation restarts than one who goes silent and then reappears asking for a meeting.
Handling Consent and Data Retention Over Multi-Year Cycles
A workflow that runs for two years has to account for the fact that marketing consent and legitimate interest assessments are not fixed at the moment a contact is tagged, they can change at any point during the cycle. If a contact unsubscribes, changes role, or the company’s data retention policy requires the record to be reviewed, the scenario needs to check current consent status at the point of each send, not rely on a snapshot taken when the “re-engage in 24 months” tag was first set. Building that check as a filter before every action module, rather than assuming the original opt-in still holds two years later, is the difference between a compliant long-cycle programme and one that quietly keeps emailing people who withdrew consent eighteen months earlier. The ICO’s guidance for organisations and the UK government’s data protection guidance are both useful reference points when setting the retention and consent rules a workflow like this needs to respect.
Monitoring Performance and Iterating the Workflow
Open rate tells you whether the subject line worked, nothing more. The metrics that actually indicate whether a long-cycle programme is working are reactivation speed (how long after re-engagement does the account move to a live conversation), reply intent, and pipeline contribution logged against the original tagged date. All three need to be pulled from CRM activity data, not from the email tool’s own dashboard, because the email tool has no visibility into what happens after the click.
Iteration should be scheduled, not reactive. A quarterly audit of which content variants drove replies, which segments are going cold, and whether the cadence itself needs adjusting (some accounts respond better to a burst of contact just before their known budget cycle than to an even quarterly spread) keeps the programme adaptive rather than a set-and-forget script running unmodified for two years. At scale, this is genuinely substantial infrastructure: one Equanax RevOps deployment runs on 6 pipeline stages, 13 automation workflows, and 3 dashboards to keep a programme like this visible to the sales team rather than hidden inside the automation tool.
Common Failure Modes and How to Avoid Them
Beyond the trigger and consent issues already covered, three further failure modes show up repeatedly in long-cycle automations. First, ownership orphaning: if the re-engagement task or alert is tied to an individual rep’s user ID rather than a team queue or role, the whole workflow becomes invisible the moment that rep leaves, even though the scenario itself keeps running. Route alerts to a queue or a manager fallback, not a named person.
Second, audit trail loss. Make.com’s scenario execution history is retained for a period that depends on your plan, and a workflow spanning two years can easily outlast that retention window. If you need to demonstrate, eighteen months in, exactly what was sent to a contact and when, relying solely on Make.com’s own history is not enough. Write each send and its outcome to the CRM timeline as it happens, so the audit trail lives in the system of record rather than inside the automation tool.
Third, content fatigue from static templates. A quarterly report that uses the same structure and framing every single time starts to read as filler rather than insight after the third or fourth send. Building two or three content variants per segment and rotating between them, rather than reusing one template on a loop, keeps the programme feeling like ongoing attention rather than an autoresponder.
Related Reading
For more on this, see our automation and n8n coverage, including Best SaaS Onboarding Automation Tactics for Converting Trial Users, Proactive SaaS Churn Prediction & Retention Automation with n8n, and Best Sales Ops Automation Tools & Low-Code Alternatives Guide.
Why do long B2B sales cycles need automated workflows instead of CRM reminders?
Standard CRM task reminders are built for a short horizon and tend to get buried, and they are tied to an individual rep’s ownership rather than a queue, so a two-year-out reminder often becomes invisible if that rep changes role or leaves. A structured automation platform like Make.com acts on CRM properties directly, so the follow-up happens regardless of who owns the account by the time it is due.
Should Make.com poll the CRM for due contacts or wait for a trigger?
A webhook trigger fired by the CRM when a relevant property changes is more efficient than a daily polling scan, because polling consumes Make.com operations scanning records that have not changed, while a webhook only runs the scenario when there is genuinely something to act on.
How do you keep consent valid across a two-year nurture cycle?
Check current consent and legitimate interest status at the point of each send rather than relying on the status recorded when the contact was first tagged, since consent can be withdrawn or a role can change at any point during the cycle. The ICO’s guidance for organisations is a useful reference for setting these rules.
What is the biggest failure mode when automating a long-cycle nurture sequence?
Tying alerts and task ownership to an individual rep rather than a team queue, so the workflow effectively goes dark if that person leaves the company. Routing alerts to a queue or manager fallback, and writing every send to the CRM timeline rather than relying only on the automation tool’s own history, avoids both ownership orphaning and audit trail loss.
Leave a Reply