Automating Personal Sales Follow-Ups Across Salesforce and Slack

The Business Situation

Cedar Vale Business Systems is a fictional 42-person provider of managed IT and workplace technology services. Its sales department consists of five account executives and one sales manager. An operations administrator also supports Salesforce configuration and monthly reporting for several hours each week.

Note: This case study is provided as a representative example of the types of AI integration and digital transformation solutions Intelligex designs and delivers. Actual engagements are tailored to each client’s goals, constraints, existing systems, timeline, and available resources, so the approach, tools, and outcomes may vary.

The sales team already used Salesforce for opportunities, Google Workspace for internal collaboration, and Slack for day-to-day communication. However, follow-up management remained personal and largely invisible. Reps flagged emails, added notes to private documents, relied on memory, and occasionally created Salesforce tasks.

The team managed approximately 90 open opportunities and recorded or performed about 220 meaningful follow-up activities each month. An average account executive therefore had 15 to 20 open opportunities at any time.

The sales manager could see opportunity stages and values in Salesforce, but could not reliably answer several operational questions:

• Does every open opportunity have a specific next action?
• When is the next action due?
• Which follow-ups are overdue?
• What happened during the last contact attempt?
• Which opportunities require management intervention?
• Are reminders being resolved or repeatedly ignored?

The objective was not to automate relationship-building or send generic messages without review. The objective was to establish consistent follow-up discipline while allowing each account executive to adapt the message, timing, and approach to the prospect.

The Existing Process

The original process followed a loose sequence:

1. An account executive created or updated an opportunity in Salesforce.
2. The rep decided when to follow up, often without recording a date in Salesforce.
3. The rep flagged an email, wrote a private note, or added a calendar reminder.
4. After contacting the prospect, the rep sometimes logged a Salesforce task or call.
5. If no response arrived, the rep moved the email flag or created another private reminder.
6. Once a week, the sales manager reviewed the pipeline and asked each rep for updates.
7. The manager manually assembled a summary in Google Sheets for the leadership meeting.

Salesforce remained the nominal source of truth, but important follow-up details lived outside it. The manager’s spreadsheet was more current for some opportunities, while inbox flags were more current for others. No system had a complete record.

This also created an audit-history problem. A completed activity might show that a call occurred, but not the result, the agreed next action, or the reason an opportunity remained open. The process depended heavily on each rep’s memory and personal organization method.

What the New System Needed to Do

The team defined the requirements before selecting an automation design.

The system also needed a manual override. A manager had to be able to reassign an opportunity, correct an invalid due date, close an obsolete exception task, or return a record to manual review without editing the automation.

Implementation Approaches Considered

The spreadsheet-only option was rejected because it would make the manager’s tracker a competing system of record. Reps would still have to update Salesforce, creating duplicate entry and reconciliation.

A Salesforce-only design could enforce next actions and create internal tasks. It remains a reasonable alternative for organizations that want all users to work entirely inside Salesforce. Cedar Vale selected a connected design because the manager already relied on Google Sheets for operating reviews and the team responded quickly to Slack notifications.

A separate no-code database was not selected because Salesforce already contained accounts, contacts, opportunity ownership, stages, and activity history. Rebuilding those relationships elsewhere would add synchronization work without solving a missing system capability.

A dedicated sales engagement platform was considered excessive for the current volume. The requirement was follow-up control and visibility, not automated multichannel sequencing.

The Selected Solution

The selected implementation retained Salesforce as the authoritative CRM. Google Sheets became a read-oriented working tracker for management, not a replacement CRM. Make handled synchronization, exception logic, reminders, and monitoring. Slack delivered concise alerts to the sales team.

The design removed manual spreadsheet maintenance, manager-generated reminder messages, and the need to reconstruct recent activity before each pipeline meeting.

It did not remove human control over sales conversations. Reps still decided how to contact prospects, edited every AI-assisted draft, sent messages themselves, and made opportunity-stage recommendations. Managers retained responsibility for significant closure or reassignment decisions.

System Architecture and Data Flow

• Intake: Authenticated Salesforce Opportunity and Task records
• System of record: Salesforce
• Automation layer: Make scenarios with internal checkpoints and idempotency records
• Document storage: Salesforce Files linked to opportunities
• Notifications: A private Slack sales follow-up channel with direct owner mentions
• Reporting: Protected Google Sheets tracker, exception tabs, and dashboard
• AI layer: Optional reviewed follow-up drafting after the core workflow is stable

1. An opportunity is created or changed. Salesforce receives the opportunity name, account, owner, stage, amount, next action, and due date. Salesforce validates required fields before saving. Make detects the changed record on its next scheduled check.

2. Make validates the event. The scenario verifies that the record has an Opportunity ID, an owner, an open or closed state, and a valid date format. It constructs an event key from the record ID and Salesforce system modification timestamp.

3. The owner is mapped. Make searches the protected Google Sheets owner-mapping tab using the Salesforce Owner ID. The returned Slack member ID and manager mapping are added to the processing bundle. A missing mapping becomes an exception.

4. The management tracker is updated. Make searches column A of the tracker for the Salesforce Opportunity ID. It updates the existing row or adds one row if no match exists. The returned row number is written to the automation log.

5. Compliance conditions are evaluated. An open opportunity without a next action or date enters the missing-action route. An action due today enters the reminder route. An overdue action enters the overdue route. Closed opportunities are marked closed in the tracker.

6. Slack reminders are sent. Make posts only when the stored reminder level and last-reminder date indicate that a new notification is required. The message includes the owner mention, opportunity name, due date, next action, and Salesforce record link.

7. An exception task is created when required. For a missing action or an action at least two calendar days overdue, Make searches for an existing open exception task. If none exists, it creates one in Salesforce and stores the returned Task ID on the opportunity and tracker.

8. A completed sales activity is processed. Make detects a completed follow-up task, validates its outcome, retrieves the related opportunity, and updates the opportunity’s last outcome, last follow-up date, next action, and next-action date.

9. Resolved exceptions are closed. If the activity creates a valid future next action, Make closes the associated exception task, clears the exception fields, resets the reminder level, and refreshes the tracker row.

10. Failures are recorded. Failed actions enter an error route. Make writes an automation-log row, increments the retry count when possible, sets a next-retry timestamp, and notifies the automation owner. A recovery scenario retries eligible records.

11. Weekly reconciliation checks completeness. A scheduled scenario compares open Salesforce Opportunity IDs with tracker IDs. It adds missing rows, refreshes stale rows, and identifies tracker rows that no longer match an accessible Salesforce record.

Make-originated Salesforce changes are written by a dedicated integration user. The general opportunity-change scenario excludes that user to avoid processing its own status updates repeatedly. The originating scenario updates Google Sheets directly after each Salesforce write.

Data Structure

Salesforce contains two related operational record types. An Opportunity is the parent sales record. Standard and custom Task records relate to an Opportunity through the Task WhatId. Google Sheets contains a flattened management view keyed by the 18-character Salesforce Opportunity ID.

Salesforce Opportunity Fields

Sales Follow-Up Task Fields

Google Sheets Structure

The tracker uses the following column order:

A  Opportunity_ID
B  Opportunity_Name
C  Account_Name
D  Stage
E  Amount
F  Owner_ID
G  Owner_Name
H  Slack_User_ID
I  Next_Action
J  Next_Action_Date
K  Last_Outcome
L  Follow_Up_Status
M  Exception_Type
N  Exception_Task_ID
O  Salesforce_Record_URL
P  Last_Activity_At
Q  Days_Overdue
R  Automation_Status
S  Last_Automation_Run
T  Retry_Count
U  Error_Message
V  Salesforce_System_Modstamp
W  Manager_Review
X  AI_Draft_Status
Y  AI_Draft
Z  Tracker_Updated_At

The Google Sheet is a projection of Salesforce. Users do not edit opportunity stage, next action, outcome, or ownership in the tracker. Protected ranges and a visible notice direct staff to make operational changes in Salesforce.

Workflow Statuses and Ownership

A record can move backward when a user clears a required field through an authorized data load, reopens an opportunity without a next action, or completes a Task with data that cannot be mapped. Those records enter Missing Next Action or Manual Review rather than being silently accepted.

Routine activity outcomes do not reject an opportunity. A recommendation to close does not automatically change the stage. It creates a management-review item so the owner and manager can confirm the commercial decision.

Step-by-Step Implementation

Step 1: Prepare the Accounts and Permissions

1. Confirm Salesforce API access. The Salesforce environment must support authenticated API access for the Make connection. Create a dedicated integration user rather than connecting with a personal sales account.

2. Create a Salesforce permission set. Grant the integration user read access to Account and User fields required for names and ownership. Grant read and update access to the selected Opportunity fields. Grant read, create, and update access to Task fields. Do not grant broad administrative permissions such as unrestricted organization-wide modification unless a documented requirement makes them necessary.

3. Create a validation-bypass custom permission. Assign Bypass_Follow_Up_Validation only to the integration user and designated administrators. This allows Make to mark legacy incomplete records as errors while normal users remain subject to next-action validation.

4. Prepare the Google account. Use an automation-owned Google account or a controlled service identity supported by the organization’s Google administration model. Share only the follow-up workbook with that identity. Reps do not need edit access to the reporting workbook.

5. Prepare Slack. Create a private channel such as sales-follow-up-alerts and a second restricted channel for automation failures if required. Authorize a Slack application connection in Make and invite the application to the destination channels.

6. Prepare Make. Create a team or organization workspace controlled by the business, not an individual consultant. Restrict scenario editing to the operations administrator and backup owner. Enable execution-history retention and incomplete-execution handling according to the organization’s operating requirements.

7. Create connections. Establish OAuth connections for Salesforce, Google Sheets, and Slack. Store the optional AI API key only in the secured Make connection. Do not place credentials in Salesforce fields, Google Sheets, Slack messages, or scenario notes.

8. Create test identities. Use at least one test account executive, one test manager, and one inactive-user case. Record their Salesforce User IDs and Slack member IDs in the test owner map.

9. Create a test environment. Use a Salesforce sandbox where available. Otherwise, use clearly prefixed test records, a duplicated Google workbook, a test Slack channel, and inactive cloned Make scenarios. Avoid sending test notifications to production channels.

The implementation does not require direct database credentials or a public webhook. Salesforce, Google, and Slack authenticate through controlled Make connections. Exact connector labels can vary as Make and the connected platforms update their interfaces, but the required permission boundaries remain the same.

Step 2: Build the Intake

The main intake is the authenticated Salesforce Opportunity form. A second intake occurs when a rep completes a Salesforce Task marked as a sales follow-up.

The next-action help text should ask for a specific verb and object. Entries such as Follow up or Check in are allowed technically but discouraged through training. Better entries include Send revised proposal, Confirm security review attendees, or Call procurement about approval date.

The Task layout contains the sales-follow-up checkbox, outcome, next action, and next-action date. Conditional page-layout guidance tells users that closure recommendations do not require another next action, but all other outcomes do.

Because intake is authenticated, public-form spam controls are unnecessary. Salesforce session security, login policy, and user permissions provide access control. The layout includes a short privacy reminder instructing users not to place credentials, payment data, health information, or unrelated sensitive information in activity notes.

Salesforce duplicate rules should continue to identify likely duplicate Accounts and Contacts. Opportunity names are not globally unique because an account can have multiple valid opportunities. Reps receive a warning when an open opportunity has the same account and a substantially similar name, but the automation never attempts to deduplicate opportunities by name.

Attachments are uploaded to Salesforce Files and linked to the Opportunity. An incomplete submission is blocked by validation. A successfully saved record receives the normal Salesforce confirmation and appears in the tracker after the next Make run.

Step 3: Create the System of Record

Create the custom Opportunity and Task fields listed in the Data Structure section. Use API names consistently because Make mappings depend on them. Document each label, API name, type, allowed value, default, and description.

Set these defaults:

• Reminder_Level__c: 0
• Retry_Count__c: 0
• Automation_Status__c: Pending
• Sales_Follow_Up__c: False unless the Task is created from the follow-up activity action
• AI_Draft_Requested__c: False
• AI_Draft_Status__c: Not Requested

Create Salesforce list views for open opportunities due today, overdue opportunities, missing next actions, manager review, automation errors, and recently resolved exceptions. These views provide an operational fallback if Google Sheets is temporarily unavailable.

Configure Automation_Key__c on Task as a unique external-ID text field. Exception task keys follow this pattern:

EXC:{OPPORTUNITY_ID}:{EXCEPTION_TYPE}:{ORIGINAL_DUE_DATE_OR_MISSING}

For example:

EXC:006DEMO000000001AA:OVERDUE:2026-07-20

If two Make executions attempt to create the same exception simultaneously, Salesforce rejects the second unique key. The error route then searches for the existing Task and stores its ID rather than creating another.

Create the Google workbook with the six tabs defined earlier. Freeze the header rows, enable filters, protect formula columns, and use data validation on configuration values. Do not store secrets in the workbook.

In Owner_Map, create these columns:

Salesforce_Owner_ID
Owner_Name
Owner_Email
Slack_User_ID
Manager_Slack_User_ID
Backup_Salesforce_Owner_ID
Active
Reminder_Time
Last_Verified_Date

In Automation_Log, create:

Event_Key
Scenario
Source_Record_ID
Started_At
Finished_At
Duration_Seconds
Result
Attempt_Count
Error_Message
Make_Execution_ID

Configure Make’s internal data store with an event key as its primary key and fields for source ID, source type, processed time, result, and execution ID. This adds an idempotency check before destination actions are performed.

Step 4: Connect the Tools

Salesforce to Make

Use the Salesforce connection owned by the integration user. Configure one scheduled scenario to watch or search changed Opportunity records and a second scenario to watch changed Task records. The underlying requirement is to retrieve records in ascending modification order and retain a checkpoint. Connector labels may vary by version.

The Opportunity source must return the Opportunity ID, account name, owner, stage, amount, next action, next-action date, outcome fields, exception fields, reminder fields, status formula, last modifier, and system modification timestamp.

Exclude records whose last modifier is the Make integration user in the general change scenario. Scenarios that write Salesforce changes also update the tracker directly, so this filter prevents update loops without losing the resulting sheet change.

Make to Google Sheets

Authorize only the specific workbook. Search Opportunity_Tracker by exact Opportunity ID in column A. If no row exists, add one. If exactly one row exists, update it. If more than one row exists, stop the normal route and create a duplicate-tracker exception.

Make to Slack

Authorize the Slack application to post only in the approved private channels. Use Slack member IDs from Owner_Map, not display names or email addresses. Member IDs remain stable when a display name changes.

Make Back to Salesforce

Use Salesforce create and update actions for exception Tasks and Opportunity workflow fields. Capture every returned Salesforce Task ID. Write the Task ID back to the Opportunity and Google tracker before sending the Slack notification.

Use the company’s Salesforce My Domain value to build record links:

https://YOUR_MY_DOMAIN.lightning.force.com/lightning/r/Opportunity/{OPPORTUNITY_ID}/view

Store only YOUR_MY_DOMAIN or the completed non-secret base URL in the Config tab. Validate the host against an approved value before including it in Slack.

Step 5: Build the Core Automation

Automation 1: Opportunity Change Synchronization

• Trigger: A Salesforce Opportunity is created or modified, checked every five minutes.
• Conditions: The change was not made by the Make integration user and the event key has not been processed.
• Actions: Retrieve the full record, validate fields, map the owner, upsert the Google row, evaluate follow-up status, and mark the event processed.
• Fields updated: Tracker columns A through Z and, when necessary, Salesforce automation or exception fields.
• Notification: Only missing, due, overdue, mapping, or error conditions generate Slack messages.
• Exception: Invalid dates, duplicate tracker rows, inaccessible owners, or failed upserts enter Manual Review.

The action order is important:

1. Construct OPP:{Id}:{SystemModstamp}.
2. Search the Make data store for that key.
3. Stop successfully if the key already exists.
4. Retrieve the Opportunity and related Account and Owner values.
5. Validate the Opportunity ID and open or closed state.
6. Search Owner_Map by Owner ID.
7. Search the tracker by Opportunity ID.
8. Add or update exactly one row.
9. Route the record by follow-up status.
10. Perform required exception or reminder actions.
11. Update the Salesforce automation fields only when their values need to change.
12. Write an Automation_Log row.
13. Create the processed-event data-store record.

Automation 2: Completed Activity Processing

• Trigger: A Salesforce Task marked as a sales follow-up reaches the organization’s closed Task status.
• Conditions: Sales_Follow_Up__c is true, WhatId points to an Opportunity, and the event is unprocessed.
• Actions: Validate outcome fields, retrieve the Opportunity, update its latest outcome and next action, resolve any active exception, and refresh the tracker.
• Fields updated: Last outcome, last follow-up time, last Task ID, next action, next-action date, reminder level, exception fields, and automation status.
• Notification: The owner receives confirmation only when an exception was resolved. Managers receive closure recommendations.
• Exception: Invalid outcomes, missing related records, or closure recommendations enter Manual Review.

For normal outcomes, Make copies the Task’s next action and date to the Opportunity. For Recommend Closed Won or Recommend Closed Lost, Make does not close the Opportunity. It creates a management-review Task and leaves the commercial decision to authorized staff.

If an active exception Task exists and the new action is valid, Make closes the exception Task, clears the exception fields, resets the reminder level to zero, and posts a concise resolution notice.

Automation 3: Daily Follow-Up Compliance Scan

• Trigger: A weekday schedule at 08:30 in the configured business time zone.
• Conditions: Opportunity is open and the next action is missing, due today, or overdue.
• Actions: Calculate escalation level, check notification history, create or reuse an exception Task, update Salesforce, refresh the tracker, and notify Slack.
• Fields updated: Reminder level, last-reminder date, exception type, exception Task ID, automation status, and tracker status.
• Notification: Owner at due date and first overdue day; manager from day five; management review at day ten.
• Exception: Missing Slack mapping sends the message to the restricted manager channel and creates an owner-mapping exception.

The reminder schedule is:

• Due today: One private-channel message mentioning the owner.
• One day overdue: Owner reminder with overdue status.
• Two days overdue: Create or reuse a Salesforce exception Task.
• Five days overdue: Mention the owner and manager.
• Ten days overdue: Change the record to Manager Review and request reassignment, closure, or a documented next step.

The scenario checks Last_Reminder_Date__c and Reminder_Level__c before posting. A rerun on the same day updates records but does not duplicate the notification.

Automation 4: Recovery and Reconciliation

• Trigger: Recovery runs every 15 minutes; reconciliation runs weekly.
• Conditions: Retry count is below three and the next-retry time has arrived, or an open Salesforce ID is missing from the tracker.
• Actions: Repeat the idempotent upsert, repair missing mappings when possible, compare record counts, and report unresolved differences.
• Fields updated: Retry count, automation status, error message, log result, and tracker timestamp.
• Notification: Operations receives a notice after the third failed attempt or any weekly reconciliation difference.
• Exception: Records that cannot be recovered remain in Manual Review with the original source ID.

Recovery repeats destination actions, not source creation. It uses the Salesforce ID, Task automation key, and Make event key to make retries safe.

Step 6: Add Approvals, Reminders, and Escalations

Routine reminders do not require approval. They contain factual Salesforce data and do not communicate with prospects. Routine follow-up messages remain manually written and sent by the account executive.

The approval and escalation rules are:

• Routine next action: Owned and completed by the account executive without manager approval.
• Closure recommendation below 25,000: Owner confirms the outcome and manually updates the opportunity according to the company’s sales policy.
• Closure recommendation at or above 25,000: Make creates a manager-review Task before the final stage change.
• Ten-day overdue opportunity: Manager chooses whether to reassign, close, pause, or retain the opportunity with a documented next step.
• AI-generated draft: The opportunity owner must review and edit before sending. Risk-flagged drafts also require manager review.

Approval is sequential where two reviews are needed. The owner first confirms the factual outcome. The manager then reviews high-value closure or a risk-flagged AI draft. Parallel approval was not selected because two simultaneous editors could produce conflicting follow-up language or stage decisions.

Owner action is expected within one business day of an exception Task. Manager review is expected within two business days. Exact business-day calculations can be added using a maintained holiday calendar. The representative implementation uses calendar-day escalation to keep configuration simple.

If an owner is unavailable, Make reads Backup_Salesforce_Owner_ID from Owner_Map. The sales manager may reassign the Opportunity and open Tasks in Salesforce. Make detects the new owner and refreshes the Slack mapping.

A rejected closure recommendation returns the Opportunity to the owner with a required future next action. A rejected AI draft is deleted or replaced, and no external message is sent.

Approval evidence consists of the Salesforce Task ID, owner, timestamps, outcome, manager-review status, Opportunity field history, and Make execution log. Slack acknowledgments alone are not treated as approval evidence.

Step 7: Add Documents and File Management

Supporting documents remain in Salesforce Files because they belong to the account and opportunity record. The automation does not copy files into Google Drive or Slack.

Use this naming convention:

OPP-{LAST_6_ID}_{ACCOUNT}_{DOCUMENT_TYPE}_{YYYY-MM-DD}_v01.ext

Examples of document types include Proposal, SecuritySummary, Pricing, and MeetingNotes. Remove restricted characters and shorten account names before applying the file name.

• Folder relationship: Files are linked to the Salesforce Opportunity rather than stored in a separate operating folder.
• Version control: Revised documents are uploaded as new versions where appropriate instead of creating unrelated copies.
• Permissions: File visibility follows Salesforce record and file-sharing permissions.
• Tracker link: Only an approved Salesforce URL is placed in Supporting_Document_Link__c and the tracker.
• Replacement: The prior version remains available according to Salesforce retention and access settings.
• Duplicate handling: Staff check the related Files list before uploading a same-name document.
• Missing files: A missing document does not stop a general reminder. Stage-specific documents can be added to a separate checklist if required.
• Failed upload: The user sees the Salesforce upload error and retries there. Make does not mark a file as available unless Salesforce returns a valid link.
• Archiving: Closed-opportunity files follow the organization’s Salesforce retention policy.

Slack messages contain record links, not file attachments. This avoids uncontrolled document copies and preserves Salesforce access checks.

Step 8: Add Reporting and Operational Views

The Opportunity_Tracker tab provides one row per opportunity. Additional protected tabs use filters or formulas to create operational queues.

The Dashboard tab contains counts by owner and status, the age of overdue actions, monthly follow-up outcomes, exception volume, and automation-failure totals. It should not expose detailed customer notes beyond the authorized sales audience.

Useful calculated fields include Days Overdue and automation duration. Google Sheets formulas are protected from normal editors. The manager owns metric definitions; the operations administrator owns formula and data-refresh maintenance.

Event-driven synchronization occurs every five minutes, while the daily compliance scenario refreshes date-sensitive statuses. Weekly reconciliation provides a completeness check. An alert threshold is triggered when any of these conditions occurs:

• More than five automation errors remain unresolved
• Any record reaches ten days overdue
• Any active owner lacks a Slack mapping
• More than one tracker row uses the same Opportunity ID
• The tracker’s open-opportunity count differs from Salesforce after reconciliation

Step 9: Add Security and Governance Controls

• Least privilege: The integration user receives only the object and field permissions required by the scenarios.
• Role-based access: Reps update their Salesforce records. Managers see the full sales tracker. Operations can monitor integrations without editing commercial decisions.
• Sensitive fields: Private notes, credentials, payment information, and unrelated personal information are excluded from Google Sheets and Slack.
• Shared links: The workbook is not shared through public or organization-wide links. Salesforce document links still require authentication.
• Credential storage: OAuth tokens and AI keys remain in Make connections. Placeholder values such as YOUR_API_KEY are used in documentation.
• Activity logs: Salesforce field history, Task history, Make execution history, and the Automation_Log tab provide traceability.
• Former employees: Salesforce, Google, Slack, and Make access is removed through the offboarding process. Opportunities are reassigned before the owner account is disabled.
• Retention: Opportunity, activity, file, log, and AI-draft retention follow the organization’s documented policies.
• Backups: Salesforce data exports and controlled copies of workbook configuration are tested periodically.
• Privacy: Only the minimum customer and prospect information required for follow-up operations is copied to the tracker and Slack.
• AI restriction: AI receives approved commercial context only. It does not receive credentials, protected personal data, legal advice requests, or complete confidential documents.
• Human approval: AI output cannot send messages, close opportunities, approve discounts, or change account ownership.

The business should review applicable privacy, records-management, communications, and industry requirements before production use. The representative workflow is not a substitute for legal or regulatory advice.

Step 10: Deploy and Test

1. Build in the test environment. Create Salesforce fields, the duplicated workbook, test channels, and inactive Make scenarios.

2. Load sample records. Include scheduled, due, overdue, missing-action, closed, reassigned, and malformed test cases.

3. Run technical tests. Validate every route, mapping, permission, retry, and idempotency rule.

4. Run user acceptance testing. Each sales role completes an opportunity update and sales follow-up Task. The manager tests reassignment and exception resolution.

5. Pilot with one account executive. Run the workflow for one week using a controlled subset of opportunities. Compare Salesforce, the tracker, and Slack daily.

6. Clean legacy data. Before enforcing validation broadly, assign next actions to all open opportunities or close records that should not remain open.

7. Enable validation. Activate the Opportunity and Task validation rules after the cleanup and pilot.

8. Activate scenarios in sequence. Enable Opportunity synchronization first, activity processing second, daily compliance third, and recovery and reconciliation last.

9. Monitor the first production week. The operations administrator reviews Make runs and Automation_Log entries each business day.

10. Document rollback. If a material problem occurs, deactivate the Make scenarios, preserve error logs, keep Salesforce validation where safe, and use Salesforce list views as the temporary operating queue.

11. Communicate the launch. Provide a one-page role guide covering required next actions, outcome values, exception handling, and where to report issues.

The sales manager is the business owner. The operations administrator is the primary technical owner, with a documented backup who can deactivate scenarios, refresh connections, and recover failed records.

Code and Configuration

No custom application code is required for the core implementation. Salesforce validation and formula fields, Make’s native Salesforce, Google Sheets, and Slack actions, and protected Google Sheets formulas provide the required behavior.

The following configuration is still essential and should be treated as production logic.

Opportunity Follow-Up Status Formula

Create Follow_Up_Status__c as a Salesforce text formula:

IF(
  IsClosed,
  "Closed",
  IF(
    OR(
      ISBLANK(Next_Action__c),
      ISBLANK(Next_Action_Date__c)
    ),
    "Missing Next Action",
    IF(
      Next_Action_Date__c < TODAY(),
      "Overdue",
      IF(
        Next_Action_Date__c = TODAY(),
        "Due Today",
        "Scheduled"
      )
    )
  )
)

Days Overdue Formula

Create Days_Overdue__c as a number formula with zero decimal places:

IF(
  AND(
    NOT(IsClosed),
    NOT(ISBLANK(Next_Action_Date__c)),
    Next_Action_Date__c < TODAY()
  ),
  TODAY() - Next_Action_Date__c,
  0
)

Open Opportunity Validation

Create a validation rule that requires next-action text and a date for open opportunities. The custom permission allows only controlled bypass:

AND(
  NOT($Permission.Bypass_Follow_Up_Validation),
  NOT(IsClosed),
  OR(
    ISBLANK(Next_Action__c),
    ISBLANK(Next_Action_Date__c)
  )
)

Use a clear error message such as:

Open opportunities require a Next Action and Next Action Date.

Add a second validation rule to prevent users from entering a past next-action date:

AND(
  NOT($Permission.Bypass_Follow_Up_Validation),
  NOT(IsClosed),
  NOT(ISBLANK(Next_Action_Date__c)),
  Next_Action_Date__c < TODAY()
)

Completed Follow-Up Task Validation

Replace Completed if the Salesforce organization uses a different closed Task status label:

AND(
  Sales_Follow_Up__c,
  ISPICKVAL(Status, "Completed"),
  OR(
    ISBLANK(TEXT(Follow_Up_Outcome__c)),
    AND(
      NOT(
        OR(
          ISPICKVAL(Follow_Up_Outcome__c, "Recommend Closed Won"),
          ISPICKVAL(Follow_Up_Outcome__c, "Recommend Closed Lost")
        )
      ),
      OR(
        ISBLANK(Next_Action__c),
        ISBLANK(Next_Action_Date__c)
      )
    )
  )
)

The error message should explain that a completed follow-up requires an outcome and, unless closure is recommended, a next action and date.

Daily Salesforce Query

If the Make Salesforce connector supports a SOQL search action, the daily compliance scan can use this query. Otherwise, apply the same conditions through the connector’s search fields:

SELECT
  Id,
  Name,
  Account.Name,
  StageName,
  Amount,
  OwnerId,
  Owner.Name,
  Next_Action__c,
  Next_Action_Date__c,
  Last_Follow_Up_Outcome__c,
  Follow_Up_Status__c,
  Days_Overdue__c,
  Follow_Up_Exception_Type__c,
  Follow_Up_Exception_Task_ID__c,
  Reminder_Level__c,
  Last_Reminder_Date__c,
  Automation_Status__c,
  SystemModstamp
FROM Opportunity
WHERE IsClosed = FALSE
AND (
  Next_Action__c = NULL
  OR Next_Action_Date__c = NULL
  OR Next_Action_Date__c <= TODAY
)

At this volume, pagination is unlikely to create a large workload, but the scenario must continue through every returned page. Do not assume the first API page contains all qualifying opportunities. Keep the field selection narrow and schedule searches conservatively to respect Salesforce API limits.

Google Sheets Formulas

Place this formula in Opportunity_Tracker!Q2 and copy it down if Days Overdue is not mapped directly from Salesforce:

=IF(OR($A2="",$L2="Closed",$J2=""),0,MAX(0,TODAY()-$J2))

Create an overdue operational view with:

=IFERROR(
  FILTER(
    Opportunity_Tracker!A2:Z,
    Opportunity_Tracker!L2:L="Overdue"
  ),
  "No overdue opportunities"
)

Create dashboard counts with formulas such as:

=COUNTIF(Opportunity_Tracker!L2:L,"Overdue")

=COUNTIF(Opportunity_Tracker!L2:L,"Due Today")

=COUNTIF(Opportunity_Tracker!R2:R,"Error")

=COUNTIF(Opportunity_Tracker!W2:W,TRUE)

These examples assume a Google Sheets locale that uses commas as function separators. Adjust separators and date handling for the workbook locale.

Make Scenario Configuration

Configure the Opportunity event key as:

OPP:{{Opportunity.Id}}:{{Opportunity.SystemModstamp}}

Configure the Task event key as:

TASK:{{Task.Id}}:{{Task.SystemModstamp}}

Normalize date output using Make’s date functions and the configured business time zone:

formatDate(
  parseDate({{Next_Action_Date__c}}; "YYYY-MM-DD");
  "YYYY-MM-DD";
  "YOUR_BUSINESS_TIME_ZONE"
)

A representative Slack reminder body is:

<@{{Slack_User_ID}}> follow-up is {{Follow_Up_Status}}.

Opportunity: {{Opportunity_Name}}
Next action: {{Next_Action}}
Due date: {{Next_Action_Date}}
Days overdue: {{Days_Overdue}}
Salesforce: {{Salesforce_Record_URL}}

Update the Salesforce opportunity or complete the related follow-up task.

For each Make scenario, add an error-handler route that records the scenario name, source record ID, attempt count, sanitized error, and execution ID. Retry transient rate-limit, timeout, and server errors up to three times. Respect a returned retry interval when the connector exposes one. Do not retry invalid credentials or validation errors without human correction.

Test formulas using scheduled, due, overdue, missing, and closed records. Test Make mappings first with one bundle. Confirm that the returned Google row number and Salesforce Task ID are recorded. Inspect Make execution history and the Automation_Log tab when a result differs from expectations.

Failure Handling and Operational Reliability

Idempotency is applied at two levels. Make stores source event keys, and Salesforce enforces unique exception automation keys. Google Sheets upserts use the immutable Opportunity ID rather than the opportunity name.

The manual-review queue acts as a lightweight dead-letter queue. It contains records that have exhausted retries or require a business decision. Each entry includes the source ID, failure category, last attempt, retry count, sanitized error, and assigned recovery owner.

Staff recover a failed record by correcting the source data or connection, confirming the destination’s current state, resetting Automation_Status__c to Retry Scheduled, and invoking the controlled recovery scenario. They do not create replacement opportunities to work around an automation error.

A Complete Example

On July 15, 2026, account executive Jordan Lee creates an opportunity for a fictional prospect called Easton Dental Group.

Salesforce accepts the record because it is open and includes both required follow-up fields. Make detects the change and creates this event key:

OPP:006DEMO000000001AA:2026-07-15T14:22:31Z

Make finds Jordan’s Slack member ID in Owner_Map, adds row 37 to Opportunity_Tracker, and records the status as Scheduled. No Slack alert is sent because the action is not yet due.

On July 17, Jordan sends the security summary and completes a Salesforce follow-up Task. Jordan selects Information sent and enters Schedule technical review as the next action with a date of July 20.

The Task receives sample ID 00TDEMO000000041AA. Make validates the completed Task, retrieves Opportunity 006DEMO000000001AA, and writes these values:

• Last outcome: Information sent
• Last follow-up time: July 17 at the Task completion time
• Last follow-up Task ID: 00TDEMO000000041AA
• Next action: Schedule technical review
• Next-action date: 2026-07-20
• Follow-up status: Scheduled

The security summary remains a Salesforce File related to the Opportunity. No duplicate document is created in Google Sheets or Slack. The tracker contains only the approved Salesforce record link.

Jordan does not complete the next action by July 20. The daily scan sends one due-today message. On July 21 it sends the first overdue reminder. On July 22, the action is two days overdue, so Make creates an exception Task using:

EXC:006DEMO000000001AA:OVERDUE:2026-07-20

Salesforce returns sample Task ID 00TDEMO000000052AA. Make stores that ID on the Opportunity and tracker, then posts a Slack message mentioning Jordan. The manager is not yet escalated because the record has not reached five days overdue.

Jordan contacts the prospect on July 22. The prospect agrees to a technical review. Jordan completes a new follow-up Task with outcome Meeting booked, next action Prepare technical review agenda, and a July 24 due date.

Make updates the Opportunity, closes exception Task 00TDEMO000000052AA, clears the exception type, resets the reminder level, and updates row 37. The final follow-up status is Scheduled.

If Jordan requests an AI draft for the July 24 follow-up, the optional scenario generates a draft using approved opportunity and activity fields. The draft is stored with Review Required status. Jordan edits it before sending. The automation does not contact Easton Dental Group or close the opportunity automatically.

Implementation Cost

All amounts below are representative planning assumptions, not quoted vendor prices or verified client costs. Current vendor licensing, API access, consumption, taxes, currency, and implementation rates must be confirmed for each organization.

The professional implementation amount is optional when the company has internal Salesforce and Make expertise. Internal implementation still requires design, testing, documentation, monitoring, and support time.

Estimated Time and Cost Savings

The representative estimate uses these assumptions:

• Monthly follow-up volume: 220 activities
• Current handling time: 9 minutes per activity
• Current management reconciliation: 6 hours per month
• New regular handling time: 4 minutes per activity
• Exception rate: 12 percent, or 26.4 records per month
• Exception handling time: 6 minutes per exception
• Monthly automation maintenance: 2 hours
• New dashboard review: 1 hour per month
• Loaded hourly labour cost: 55
• Recurring core software cost: 40 per month
• One-time implementation cost: 9,570

Current monthly labour hours: Monthly volume × current minutes per record ÷ 60

220 × 9 ÷ 60 = 33.00 direct handling hours

33.00 direct hours + 6.00 reporting hours = 39.00 current monthly hours

New monthly labour hours: Monthly volume × new minutes per record ÷ 60, plus exception handling and maintenance

220 × 4 ÷ 60 = 14.67 regular handling hours

26.4 exceptions × 6 ÷ 60 = 2.64 exception hours

14.67 + 2.64 + 2.00 maintenance + 1.00 dashboard review = 20.31 new monthly hours

Monthly hours recovered: Current monthly labour hours minus new monthly labour hours

39.00 – 20.31 = 18.69 hours recovered per month

Estimated monthly labour value: Monthly hours recovered × loaded hourly labour cost

18.69 × 55 = 1,027.95 per month

Net estimated monthly value: Monthly labour value minus recurring tool costs

1,027.95 – 40 = 987.95 per month

Estimated payback period: One-time implementation cost ÷ net estimated monthly value

9,570 ÷ 987.95 = approximately 9.7 months

Recovered time does not automatically reduce payroll. It can represent additional selling capacity, quicker follow-up, reduced overtime, fewer administrative tasks, more consistent coaching, or the ability to manage a larger pipeline without adding the same amount of coordination work.

Non-financial benefits include clearer ownership, fewer manager follow-ups, more consistent activity outcomes, better coverage during absence, stronger audit evidence, faster pipeline reviews, and a more consistent prospect experience.

Readers should replace the volume, handling time, exception rate, labour cost, maintenance effort, implementation cost, and software allowance with their own measured figures.

Adding AI to the Automation

AI is added only after required fields, deterministic validation, reminders, exception handling, and reporting work reliably. Most of the value in this case comes from normal automation rather than AI.

Required fields, exact dates, workflow status, ownership, and escalation should not be delegated to AI. They are more reliable and less expensive when implemented with validation, formulas, lookups, and deterministic conditions.

The Recommended AI Enhancement

The recommended enhancement creates a reviewable first draft of a follow-up message. It does not send the message.

• Trigger: The opportunity owner selects AI_Draft_Requested__c and saves the Opportunity.
• AI input: Contact first name, account name, opportunity stage, next action, next-action date, last approved outcome, up to three approved activity summaries, sender name, and requested tone.
• System instruction: Draft a concise B2B follow-up using only supplied facts. Do not invent commitments, dates, prices, results, or customer statements.
• Expected output: Structured JSON containing a subject, body, confidence score, missing-information list, and risk flags.
• Validation: Make parses the JSON, checks required keys, validates length and confidence, and rejects prohibited content.
• Record update: Valid output is stored in Salesforce with Review Required status.
• Human review: The owner edits the draft and sends it through the approved communication tool.
• Low confidence: Scores below 0.75 enter Manual Review without a send-ready status.
• Prohibited data: Credentials, payment data, protected health information, legal conclusions, sensitive personal data, and complete confidential documents.
• Logging: Store request time, model identifier, status, confidence, token or usage data when available, reviewer, and final disposition.
• Failure behavior: Set Draft Status to Failed and instruct the rep to write the message manually.

Use a secured Make AI connection with a placeholder such as YOUR_API_KEY. The key must not appear in the prompt, workbook, Salesforce record, or log.

The exact reusable system and user prompt is:

SYSTEM INSTRUCTION

You draft concise B2B sales follow-up messages for human review.

Use only facts provided in the user input.
Do not invent meetings, commitments, pricing, deadlines, customer opinions,
product capabilities, attachments, or previous conversations.
Do not make legal, security, financial, or contractual assurances.
Do not use pressure tactics.
Do not state that an attachment is included unless attachment_available is true.
Keep the body under 180 words.
Use a professional and natural tone.
Return valid JSON matching the required schema and no additional text.

USER PROMPT

Create a follow-up draft from the following approved CRM data:

sender_name: {{OWNER_NAME}}
contact_first_name: {{CONTACT_FIRST_NAME}}
account_name: {{ACCOUNT_NAME}}
opportunity_stage: {{STAGE}}
next_action: {{NEXT_ACTION}}
next_action_date: {{NEXT_ACTION_DATE}}
last_outcome: {{LAST_OUTCOME}}
recent_activity_summaries: {{APPROVED_ACTIVITY_SUMMARIES}}
requested_tone: {{REQUESTED_TONE}}
attachment_available: {{ATTACHMENT_AVAILABLE}}

If important context is absent, list it in missing_information.
If the request appears to require legal, contractual, pricing, security,
or other high-risk assurances, add a risk flag and avoid making the assurance.
The human owner will review and edit the draft before sending.

The required structured output is:

{
  "draft_subject": "string",
  "draft_body": "string",
  "confidence": 0.0,
  "missing_information": [
    "string"
  ],
  "risk_flags": [
    "pricing_commitment",
    "contractual_assurance",
    "security_assurance",
    "legal_language",
    "sensitive_data",
    "unsupported_claim"
  ]
}

A valid response might be:

{
  "draft_subject": "Technical review agenda for Easton Dental Group",
  "draft_body": "Hi Taylor,\n\nThank you for confirming the technical review. I am preparing the agenda for our discussion and will focus it on the items covered in the security questionnaire summary.\n\nIf there are additional topics your team would like included, please send them before the review and I will add them for consideration.\n\nBest,\nJordan",
  "confidence": 0.87,
  "missing_information": [
    "Confirmed meeting time was not supplied"
  ],
  "risk_flags": []
}

In Make, parse the returned JSON and apply these conditions in order:

1. Confirm the response is valid JSON.
2. Confirm all five required top-level fields are present.
3. Confirm confidence is a number from 0 through 1.
4. Confirm the subject and body are within configured length limits.
5. Confirm no prohibited source fields were sent.
6. If confidence is below 0.75, set status to Low Confidence.
7. If any risk flag is present, set status to Manager Review.
8. Otherwise, store the subject and body with Review Required status.
9. Clear AI_Draft_Requested__c to prevent repeated generation.
10. Notify the owner that a draft is available for review.

Malformed output is not repaired silently. Make can attempt one structured retry with the same factual input and an instruction to return valid JSON. A second failure enters Manual Review.

Benefits of the AI Enhancement

The core automation already provides follow-up discipline, ownership, reminders, exception tasks, outcome history, and reporting. AI does not create those benefits.

The AI-specific benefit is a faster first draft when the rep has enough approved CRM context. It can reduce blank-page time, summarize recent activity into a concise message, and apply a more consistent structure.

• Less time rereading several recent activity notes
• Faster creation of a usable starting draft
• More consistent inclusion of the stated next action
• Visible identification of missing context
• Risk flags for unsupported assurances
• Structured output that can be validated before storage

AI output still requires review because tone, commercial judgment, relationship history, and current prospect context may not be fully represented in CRM fields.

What Remains Rule-Based or Human-Controlled

Estimating the Additional Value of AI

The representative AI estimate assumes that 140 of the 220 monthly follow-up activities are suitable for drafting assistance.

• Drafting time without AI: 3.0 minutes per eligible message
• Initial review and editing with AI: 1.5 minutes
• Expected correction rate: 20 percent
• Extra correction time: 1.5 minutes for corrected drafts
• Expected service failure rate: 2 percent
• Manual fallback after failure: 3.0 minutes
• Monthly AI output sampling: 0.5 hours
• AI usage allowance: 10 per month

Average AI review time including corrections is:

1.5 + 20 percent × 1.5 = 1.8 minutes per eligible draft

Gross drafting time recovered is:

140 × (3.0 – 1.8) ÷ 60 = 2.80 hours

Failure fallback time is:

140 × 2 percent × 3.0 ÷ 60 = 0.14 hours

Net additional capacity after failure fallback and monthly sampling is:

2.80 – 0.14 – 0.50 = 2.16 hours per month

At a loaded hourly cost of 55, the additional labour value is 118.80. After the 10 AI usage allowance, the representative net additional value is 108.80 per month.

These assumptions must be validated during a pilot. AI does not eliminate correction, review, service failure, or the possibility that a rep decides to discard the draft.

Testing Checklist

Use synthetic sample data before processing real prospect or customer information.

Ongoing Maintenance

The sales manager owns the business process. The operations administrator owns technical monitoring. A trained backup must be able to review failures, reconnect services, and deactivate scenarios.

Documentation should include field definitions, scenario diagrams, connection owners, retry rules, configuration values, validation formulas, Slack destinations, AI prompt versions, and the manual-recovery procedure.

When to Move to Dedicated Software

The connected implementation can remain appropriate while Salesforce continues to perform well as the source of truth and the workflow remains understandable to its owners. Replacement is not automatically necessary as volume grows.

Dedicated sales engagement, revenue operations, workflow, or analytics software should be evaluated when several of these conditions appear:

• Follow-up volume increases enough to create API, polling, or workbook performance concerns
• The team requires multistep automated email and call sequences
• Multiple regions need different calendars, languages, policies, or escalation paths
• Formal regulatory controls require specialized retention or communications supervision
• Permissions become too complex for a flattened management workbook
• Exception rates remain high despite process changes
• Maintaining custom mappings consumes excessive administrator time
• Multiple CRMs or acquired business units must be integrated
• Formal audit evidence exceeds the available Make and workbook controls
• Managers require advanced attribution, forecasting, or engagement analytics
• Reps need an external customer portal, mobile-first workflow, or offline access
• Vendor support and contractual service commitments become mandatory
• AI use expands into governed conversation intelligence or large-scale document analysis
• Security risk grows because too much operational data is copied into reporting tools

Before replacing the implementation, the business should determine whether Salesforce-native reporting, Flow, a data warehouse, or tighter Make governance can address the new requirement with less disruption.

Implementation Checklist

• Confirm monthly volume, users, reminder timing, escalation rules, and ownership.
• Select Salesforce as the system of record and document the role of each connected tool.
• Confirm Salesforce API access and required platform features.
• Create controlled Salesforce, Google, Make, and Slack connections.
• Apply least-privilege permission sets and workbook sharing.
• Create Opportunity and Task fields with documented API names.
• Define next-action, outcome, exception, automation, and AI statuses.
• Create validation rules and the controlled bypass permission.
• Create the Google Sheets tracker, owner map, log, configuration, and dashboard tabs.
• Populate and verify Salesforce-to-Slack owner mappings.
• Define the immutable Opportunity ID and event-key strategy.
• Configure Opportunity synchronization and exact field mappings.
• Configure completed-activity processing and outcome updates.
• Configure daily reminders, exception Tasks, and management escalations.
• Store returned Salesforce Task IDs on the source Opportunity and tracker.
• Configure Salesforce Files naming, linking, access, and retention.
• Protect reporting formulas and operational source columns.
• Configure error routes, retries, the manual-review queue, and reconciliation.
• Test duplicate events, partial completion, expired credentials, and failed notifications.
• Run user acceptance testing with synthetic sample records.
• Pilot with a limited group before full activation.
• Document deployment, rollback, monitoring, and manual recovery.
• Confirm representative implementation and recurring cost assumptions.
• Replace savings assumptions with measured company figures.
• Add reviewed AI drafting only after the rule-based workflow is stable.
• Validate AI prompts, structured output, prohibited data, and human review.
• Assign a primary maintenance owner and trained backup.
• Define volume, security, reporting, workflow, and support criteria for evaluating dedicated software.