Salesforce Archives - Page 3 of 6

Stripe and Salesforce integration for SaaS companies

Your Stripe dashboard shows who is paying. Your Segment or PostHog shows who is actually using the product. Your Salesforce shows who the sales team is talking to. Three tools, three completely separate truths, and no connection between them. The most dangerous churn is the kind where a customer goes quiet in the product weeks before the renewal and nobody on the sales team knows, because they are looking at a different screen. At 30 to 50 people, this gap stops being an inconvenience and starts costing real revenue. How the Three Systems Connect in Salesforce Segment or PostHog PRODUCT EVENTS Stripe Billing & Subscriptions BILLING DATA Salesforce Account · Opportunity Contract · Lead · Contact SALESFORCE FLOW PQL events usage scores MRR · plan · status Renewal Opportunity auto-created at 90-day window PQL Task for Rep triggered by product threshold CS Churn Alert usage drop triggers CS queue Stripe and Segment/PostHog feed Salesforce. Flow automation handles the rest. How this gap forms at the 30–50 person stage At 10 people, three separate systems are manageable. The founder knows every customer. The CS lead knows the product numbers. The AE knows the renewal dates. Context lives in heads rather than systems, and that works until it does not. At 30 to 50 people, the team is too large for context to live in heads, and too small to have dedicated RevOps infrastructure. Stripe renewals are tracked in a shared spreadsheet that someone updates when they remember. Product usage reports are emailed by the data team on Fridays, if at all. Salesforce has the account records, but none of the product or billing reality is visible on them. The result is a sales team operating on incomplete information, a CS team reacting to churn rather than preventing it, and a leadership team whose pipeline numbers do not reflect what is actually happening in the customer base. Three problems that appear when these systems are not connected The renewal blind spot A subscription renewal is not a surprise event. The date is known. The contract value is known. And yet, in most SaaS companies at this stage, renewals are managed through a combination of calendar reminders, spreadsheet exports from Stripe, and a Salesforce pipeline that someone populated three months ago and has not touched since. The specific failure mode is not the missed renewal itself it is the missed signal. A customer whose usage dropped 60% in the 30 days before renewal is telling you something. Without Stripe and product data flowing into Salesforce, that signal is invisible. The rep goes into the renewal call having seen nothing change in CRM, not knowing the customer has already mentally moved on. Research from SaaS industry benchmarks consistently shows that companies managing renewals manually lose 10 to 15 percent more ARR to avoidable churn than those with connected systems. At a $3 million ARR base, that is between $300,000 and $450,000 a year in revenue that a spreadsheet is costing you. 10–15% more ARR lost The cost of managing renewals manually SaaS companies that track renewals in spreadsheets — without automated CRM visibility into billing and product usage — lose 10 to 15 percent more ARR to avoidable churn than those with connected systems. At a $3M ARR base, that is between $300K and $450K per year that a spreadsheet is costing you. SaaS industry renewal benchmarks The PQL opportunity going uncontacted The most valuable leads in a SaaS company are not the people who filled out a demo form. These are Product-Qualified Leads, and they are worth three to five times the conversion rate of a cold inbound lead. The problem is that the signal for a PQL lives in Segment or PostHog. It does not live in Salesforce. So when a user activates your most advanced features and invites four teammates in the same week, nothing happens in CRM. Meanwhile, the rep’s call list is full of people who clicked an ad or downloaded a whitepaper. The highest-intent users in your product are invisible. The quote and proposal bottleneck At this stage, sales reps are usually creating proposals in one of three ways: a Google Docs template they copy and paste from, a PDF that lives on someone’s desktop, or an email they wrote from scratch. None of these live in Salesforce. None of them can be tracked, approved by a manager, or analyzed for win rates. Furthermore, when a deal closes, nobody can trace back from the Opportunity to the quote that was sent. Pricing decisions, discount patterns, and approval workflows are invisible to leadership. The audit trail does not exist because the quotes were never in the system. What a sales rep’s week looks like without the integration vs. with it What the rep sees Without integration With integration Current MRR / plan ACV from when the deal was first entered. May not reflect a seat reduction or downgrade that happened in Stripe. Live MRR pulled from Stripe, updated on the Account record in real time. Seat count and plan visible at a glance. Product usage trend Not visible. Rep would need to ask the CS lead, who would need to pull a report from PostHog or Segment manually. 30-day engagement score and key feature activation events visible directly on the Account record. Renewal date In the spreadsheet maintained by one person. Or a calendar reminder. Possibly both, possibly disagreeing. Renewal Opportunity auto-created 90 days out, visible in pipeline alongside new business, with value from contract. Churn risk signal None — unless a customer raises a support ticket or emails to cancel. Risk is identified at or after the churn event. Usage drop flag auto-generated when engagement falls below baseline for 14+ days. CS task created before the call. Payment health Unknown. A declined card or failed payment from last month would not appear in CRM. Payment status from Stripe on the Account record. Failed payments surfaced as a risk flag before the renewal call. Expansion opportunity Rep guesses

How to Use GEO in Salesforce Experience Cloud

SEO is not dead, but it has a new layer on top of it. Spring ’26 added Generative Engine Optimization to Salesforce Experience Cloud — a single toggle in Experience Builder that tells AI engines like ChatGPT, Perplexity, and Gemini how to read your portal content directly from the source. If your customers are starting their searches in AI chat instead of Google, this matters more than you might think. Here is what the feature does, how to turn it on, and which types of Salesforce sites benefit most. What Generative Engine Optimization actually does When a user asks ChatGPT or Perplexity a question about your product or service, the AI engine looks for publicly available content to ground its answer. If your Experience Cloud site is not set up to accommodate that process, the engine either ignores it or generates an answer from indirect sources — which may not reflect your current content accurately. GEO changes that by allowing AI bots to request a structured content snapshot of your public site pages. The snapshot gives the AI a clean, source-verified version of your content to work with, rather than a cached or scraped approximation. The result is that your portal becomes citable: when someone asks an AI assistant a question your help center or community site answers, there is a higher chance the answer comes from your actual content. This is the core difference from traditional SEO. Traditional SEO tells Google’s web crawler how to index your page for search ranking. GEO tells AI language model crawlers how to read and reference your page when generating answers. Dimension Traditional SEO GEO Target audience Google, Bing, and other traditional search engine crawlers AI-powered answer engines: ChatGPT, Perplexity, Gemini, Google AI Overviews Goal Rank higher in search results pages Be cited accurately in AI-generated answers Core mechanism Crawlable HTML, meta tags, backlinks, structured data, page speed Structured content snapshots that AI bots can request and process What it optimises for Click-through from a results list Accuracy and attribution when the user never sees a results list Where users see the result A link in a list of search results they click through An answer that cites your content directly in the AI interface Requires publishing Crawled on Google’s schedule, not yours Snapshot reflects your content as of the last site publish How to enable in Salesforce SEO settings: page title, meta description, canonical, sitemap Experience Builder → Settings → SEO → enable GEO toggle → republish Replaces the other? No — parallel tracks for parallel channels. Both are worth managing. Where to find the toggle and how to enable it The GEO setting lives in Experience Builder under the SEO settings panel. The path is: Experience Builder → Settings → SEO → Provide content snapshots of public site pages when requested by AI bots Enable the toggle, then republish the site. The setting takes effect on the next publish. It applies to both Aura and LWR sites and is available in Enterprise, Performance, Unlimited, and Developer editions. There is no additional configuration required at the page level. The toggle works across all public-facing pages on the site. Pages behind authentication are not included — GEO only applies to content that is publicly accessible without a login. How to Enable GEO in Experience Builder Spring ’26 — 3 steps 1 Open your Experience Cloud site in Experience Builder Navigate to the site you want to update. You need Admin access or a profile with Experience Cloud site management permissions. Setup → All Sites → Builder 2 Go to Settings → SEO and enable the GEO toggle In the left panel, open Settings. Select SEO. Find the option labelled “Provide content snapshots of public site pages when requested by AI bots” and enable it. Settings → SEO → AI bots toggle → ON 3 Publish the site The GEO setting takes effect on the next publish. Click Publish in Experience Builder to apply the change. The setting then applies to all public-facing pages on both Aura and LWR sites. Publish → Confirm Available in Enterprise, Performance, Unlimited, and Developer editions. Applies to public pages only — authenticated content is not included. What a content snapshot actually is A content snapshot is a static HTML version of your page that AI crawlers can request and process. It is optimised for machine reading rather than browser rendering — it strips out the dynamic elements, JavaScript-rendered content, and navigation chrome, and returns the core textual content of the page in a clean format. For AI engines, this is more reliable than attempting to crawl a JavaScript-heavy page where the main content only appears after client-side rendering. Furthermore, it means the snapshot reflects what is actually published in your Salesforce CMS, not a cached version from weeks ago. The practical implication is accuracy. If your help center article says your product supports a specific integration, the snapshot contains that exact statement. The AI engine citing your content has a verified source, rather than a reconstructed one. Which Salesforce portals benefit most from enabling GEO Which Salesforce Portals Benefit Most from Enabling GEO Public pages only 📖 Self-service help centers and knowledge bases Articles, FAQs, and troubleshooting guides are exactly the content AI engines look for when answering product questions. GEO makes your help content the cited source instead of a paraphrased approximation. Highest impact 🤝 B2B partner portals with public documentation Product docs, integration guides, and pricing pages are actively searched by B2B buyers using AI research tools. A GEO-enabled portal appears in that research process; one without it does not. High impact 💬 Community sites with publicly visible content Community answers to product questions are high-value for AI engines because they reflect real usage. If your community is publicly viewable without login, GEO makes that content accessible in the right format. Good candidate 🏢 Customer-facing product or service information sites Any Experience Cloud site where prospects or customers look up your features, plans, or support

Connected Apps Are Being Retired in Salesforce

Starting with Spring ’26, Salesforce disabled the creation of new Connected Apps by default across all orgs. Your existing ones still work for now. But the direction is clear: External Client Apps are the future, and the clock is running. This guide covers what changed, why Salesforce made this move, what External Client Apps actually give you, which apps are and are not affected, and a step-by-step migration walkthrough through App Manager. The second half is a structured checklist for the audit before you migrate and the testing after. The TLS certificate changes happening in the same release are covered at the end, because both come from the same security-first motivation. Spring ’26 Migration Timeline & TLS Certificate Phase-Down Connected Apps → External Client Apps 1 Winter ’26 New Connected App creation disabled by default in new orgs Opt-in 2 Spring ’26 New creation disabled across all orgs — Support request required Enforced 3 Summer ’26 Expected enforcement deadline — plan migration before this Deadline 4 Summer ’26 Triple DES for SAML SSO stops working completely Hard Stop TLS Certificate Lifespan Phase-Down (CA-signed certificates only) A Until Mar 14, 2026 Max lifespan 398 days (previous standard) B Mar 15, 2026 Max lifespan drops to 200 days Now C Mar 15, 2027 Max lifespan drops to 100 days Plan for D Mar 15, 2029 Max lifespan drops to 47 days — automation required Automate Why Salesforce is making this change Connected Apps have been part of Salesforce for over a decade. If you have ever set up OAuth for a third-party integration, configured Data Loader, or connected a custom web application to the Salesforce API, you have used one. They are everywhere, and most of them work fine. The problem is not the apps that are configured properly. The problem is the ones that are not, and the architecture that makes unsafe configurations easy to create. By default, Connected Apps allow any API-enabled user in an org to self-authorise a connection to an external application, without admin approval. That is how phishing and vishing attacks that targeted Salesforce orgs worked: trick a user into authorising a malicious Connected App, and the attacker has API access to the org’s data. Salesforce responded by tightening this behaviour, but the structural issue remained. External Client Apps take a different starting position. They adopt a closed security posture by default. Access is not granted unless an administrator explicitly permits it. Furthermore, the architecture separates developer configuration from admin policy, which means a developer building an integration cannot inadvertently override security settings that the admin put in place. What changed in Spring ’26, specifically The rollout has been gradual. In Winter ’26, Salesforce disabled Connected App creation by default in new orgs, with an option for admins to re-enable it manually. Spring ’26 tightened that further: new Connected App creation is now disabled across all orgs, including existing ones. Getting the ability back requires a Salesforce Support request, and Salesforce has been clear that this option will eventually disappear entirely. Two categories of Connected Apps are not affected by this change. Connected Apps created as part of a managed package continue to work and can still be created in that context. Connected Apps used for Slack in the legacy Agentforce Builder are also excluded. Everything else follows the new default. Any new integration from Spring ’26 onward must be built as an External Client App. ⚠ What happens if you try to create a new Connected App without a Support request The New Connected App button no longer appears in App Manager — the option is gone from the UI entirely. Attempting to create one via the Metadata API returns an error. There is no workaround inside the platform. Any new integration built after Spring ’26 that requires its own OAuth client must use an External Client App instead. If a specific business case genuinely requires a new Connected App, you must open a Salesforce Support case and explicitly request the capability. Salesforce may or may not grant it, and this option will be removed in a future release. What External Client Apps offer that Connected Apps do not External Client Apps are not just Connected Apps with a new name. The differences are architectural, and several of them matter a lot depending on how your org is set up. Separation of developer settings and admin policies In a Connected App, the developer configuration and admin security policies live in the same record. A developer with edit access to the Connected App can change the OAuth scopes, the IP restrictions, and the session policies. In an External Client App, those roles are separated. Developers manage the technical settings; admins manage the access policies. Neither can override the other without the appropriate permission. For ISVs and AppExchange partners, this matters enormously. It means the admin installing your package can control how it behaves in their org without touching the underlying app configuration. Second-generation packaging support External Client Apps are designed specifically for second-generation packaging, or 2GP. Connected Apps technically work with 2GP, but the process required manual steps that were fragile and time-consuming. ECAs package cleanly, distribute correctly, and integrate naturally with source control and CI/CD pipelines via the Metadata API. For admins managing integrations rather than building packages, the practical difference is that ECAs behave more predictably in sandboxes and scratch orgs. Scratch Org support for External Client Apps was added in Spring ’26, which makes the developer testing cycle considerably cleaner. Closed security posture by default A new External Client App is not accessible to any user until an administrator explicitly grants access. There is no self-authorisation pathway by default. This is the core security difference from Connected Apps, and it is the reason Salesforce is moving in this direction. What ECAs do not yet support Two important gaps remain. External Client Apps do not support the Username-Password OAuth flow. If any of your existing Connected Apps use this flow, you cannot migrate them

Salesforce Setup Roadmap for SaaS Companies

Setting up Salesforce for a SaaS company is not the same as setting it up for a real estate agency or a professional services firm. Subscriptions, trials, renewals, MRR, none of that exists in a default Salesforce org. Getting it right means building a system that reflects how SaaS revenue actually works: from the first lead through to the second and third renewal. This is the setup roadmap used with SaaS companies at every growth stage. SaaS Salesforce Setup — Three-Phase Roadmap Phase 1 Pipeline Control 2 – 15 people SaaS-configured objects (MRR, ACV, trial stages) Website lead capture via Web-to-Lead Email and calendar auto-sync Basic quota tracking Clean data migration Foundation Phase 2 Process & Prevention 15 – 30 people Contract Management object New Business vs Renewal quota split Round Robin lead assignment Calendly integration Outbound activity logging Scale-Ready Phase 3 Revenue Intelligence 30 – 50 people Product data via Segment / PostHog Stripe subscription sync Automated Renewal Opportunities Quotes object and PDF proposals RevOps forecasting Fully Connected Build in sequence — each phase is the foundation for the next The roadmap breaks into three phases, each tied to the problems that appear at a specific team size. Phase 1 is about getting your data into one place and your pipeline under control. Phase 2 is about building process before things break. Phase 3 is about connecting your product and revenue data so the whole system works without manual intervention. Most SaaS companies skip Phase 1 entirely, configure a few things in Phase 2, and then wonder why Phase 3 never delivers the visibility they expected. ⚠ What breaks when you skip Phase 1 and go straight to Phase 3 No clean data foundation Stripe sync and product events write to duplicate or incomplete records. Automation fires on bad data. No stage or quota logic RevOps forecasting has nothing reliable to forecast. Pipeline reviews become guesswork in a different tool. No email or activity sync Automated tasks get created on leads with no interaction history. Reps ignore them because there is no context. No Contract Management object Renewal Opportunity automation has no subscription terms to read. The automation cannot trigger correctly. No team training or adoption The Phase 3 system sits unused while the team works in spreadsheets. The investment does not produce results. Phase 1 (2–15 people): Get the pipeline under control At this stage, most SaaS teams have contacts in a spreadsheet, deals tracked in someone’s head, and follow-up happening through email threads. Salesforce at Phase 1 has one job: get everything into one system and make it usable for a small team with no dedicated ops person. Configure core objects for SaaS context A default Salesforce org is built for transactional sales. The standard Opportunity fields assume a one-time deal. For SaaS, you need subscription-aware fields from the start. That means adding fields for Monthly Recurring Revenue, Annual Contract Value, trial start and end dates, subscription tier, and billing interval. The Lead object also needs updating. Source fields should reflect where SaaS leads actually come from: product sign-up, inbound form, G2 review, or referral. Furthermore, the Opportunity stage names matter more than most teams realise. Default stages like ‘Prospecting’ and ‘Perception Analysis’ mean nothing in a SaaS context. Replace them with stages that reflect your actual sales motion: Trial Active, Demo Scheduled, Proposal Sent, Closed Won, Closed Lost. Set up lead capture from your website Every SaaS website has a form or a trial sign-up button. In most early-stage companies, those leads land in an email inbox or a spreadsheet. Connecting your website forms directly to Salesforce via the Web-to-Lead feature takes an afternoon and immediately removes the manual logging step. For trial sign-ups specifically, the connection between your product and your CRM is worth building early. Even a simple webhook that creates a Lead when a user signs up gives your team visibility into who is in the product — before you build anything more sophisticated. Connect email and calendar Manual activity logging is the reason most CRM data goes stale within three months of implementation. When reps have to log every call and email by hand, they stop doing it. Salesforce Inbox or the standard Gmail and Outlook integrations sync email threads and calendar events automatically. As a result, every Lead and Contact record shows a complete interaction history without anyone updating it manually. That is the baseline that makes everything else in the CRM trustworthy. Set up sales quotas early Most founders skip quota configuration at Phase 1 because the team is too small. That is a mistake. Setting up quota tracking in Salesforce from the beginning creates a performance culture before the team grows. Specifically, it gives you a reference point when you are making your first sales hire: what does good look like, and what is the current baseline? Quota configuration at this stage is simple. Assign monthly or quarterly revenue targets per user, and build a single Salesforce report that shows actuals versus target. That is all you need at 2–15 people. Data migration: clean before you move Almost every SaaS company arrives at Salesforce with a mix of HubSpot exports, Notion tables, and Airtable bases. Before migrating any of that data, spend time cleaning it. Remove duplicates, standardise company names, and decide which fields you actually need to carry over. Moving messy data into Salesforce does not fix the mess. It just moves it into a more expensive system. A clean migration of 500 accurate records is considerably more useful than importing 3,000 records with no confidence in the data. Phase 1 — Pipeline Control Checklist 2–15 people Core object fields configured — MRR, ACV, trial dates, subscription tier on Opportunity; SaaS lead sources on Lead Opportunity stage names updated — replaced with SaaS stages: Trial Active, Demo Scheduled, Proposal Sent, Closed Won, Closed Lost Web-to-Lead connected — website form and trial sign-up button create Lead records automatically Email and calendar sync live — Gmail or Outlook integrated;

How to Find Your SaaS PQL in Salesforce

Product-led growth gets talked about as a marketing strategy. It is actually a data strategy. The moment a user signs up for your free trial, they start telling you exactly how likely they are to pay, through every click, every feature they open, and every session they skip. Most SaaS sales teams have no idea any of that is happening. None of it is in their CRM. What is a Product-Qualified Lead? A Product-Qualified Lead, or PQL, is a user who has reached a meaningful milestone inside your product. They activated a key feature, hit a usage threshold, invited a teammate, or upgraded their storage. Whatever the milestone is, they are doing the thing your product is designed to do. That makes them different from every other lead type in your funnel. A Marketing-Qualified Lead clicked an ad or downloaded an ebook. A Sales-Qualified Lead filled out a demo form. Neither has actually used your product. A PQL has, and in most PLG companies, that difference shows up as a 3% conversion rate versus a 25% one. Furthermore, PQLs are consistently underused. Not because companies do not want to act on them, but because the signal lives somewhere the sales team cannot reach. Why the PQL signal gets wasted without CRM integration Product analytics tools capture this data well. Segment, Mixpanel, PostHog, and Amplitude track every session, every feature interaction, and every drop-off point with precision. The dashboards are detailed. The data is there. However, your sales team is not in those dashboards. They are in the CRM. And in most PLG SaaS companies, those two systems do not talk to each other. The result is a structural disconnect. Your product knows which users activated three core features in a seven-day trial. Your reps are calling people who downloaded a whiteboard template six weeks ago. Meanwhile, the user who is two steps from converting sits uncontacted in your product database, not in your pipeline. This is not a prioritisation problem. It is a data infrastructure problem. Specifically, it is fixable. PLG Trial-to-Paid Funnel in Salesforce Trial Signup by source & channel Activation key feature milestone reached PQL Trigger usage threshold, invite, or score met Sales Action rep task auto-created in Salesforce Closed-Won Here is what four common PQL triggers look like in practice. 1. Trial activation trigger A user activates three core features within seven days of signing up. Salesforce creates a task for a rep to reach out with a targeted expansion message. The rep sees the activation data directly on the Lead record. 2. Churn risk alert A user’s engagement drops below their baseline for 14 consecutive days. Salesforce creates a CS alert before the churn event. The CS team can intervene with full context on what the user did and did not do. 3. Account expansion signal Five or more users at the same account invite colleagues during the trial period. Salesforce scores the Account higher and moves it into an expansion workflow automatically. 4. Free-to-paid attribution A free-to-paid conversion is tracked as a closed Opportunity, connected to the original trial Lead record. Marketing attribution becomes real, not estimated. Situation Without PQL data With PQL data in Salesforce Who reps contact first Demo form leads, regardless of product activity Users who activated key features, ranked by engagement score What reps see on a Lead record Name, email, company, source Features activated, sessions logged, days since last login, PQL status Churn detection Customer cancels, CS finds out after the fact Usage drop triggers CS alert at day 14, before churn event Free-to-paid attribution Estimated or modelled based on last-touch channel Closed Opportunity linked directly to original trial Lead record Account expansion signals No visibility until a user reaches out or upgrades manually Automatic score increase when 5+ teammates invited during trial PLG funnel visibility Sign-up volume and revenue, nothing in between Full funnel: signup, activation rate, PQL rate, closed-won from trial How to build this in Salesforce The most practical starting point is a set of Custom Fields on the Lead or Contact record that reflect product activity. You do not need a full Customer Data Platform to get started. You need a clean data feed and clear trigger logic. 3 PQL triggers worth setting up first 1 Feature activation trigger User activates 3 or more core features within 7 days of signing up. This is the clearest signal that the product is working for them, and the highest-intent moment to start a conversation. Trigger: 3 features in 7 daysAction: Rep task created in Salesforce 2 Churn risk trigger User engagement drops below their personal baseline for 14 consecutive days. Acting at day 14 gives CS enough lead time to re-engage before the user mentally cancels. Trigger: 14-day usage dropAction: CS queue alert in Salesforce 3 Account expansion trigger Five or more users from the same account invite colleagues during the trial period. Team adoption during trial is one of the strongest predictors of a paid conversion at the account level. Trigger: 5+ teammate invitesAction: Account score increase + expansion workflow Step 1: Define your PQL criteria Before any configuration, decide what product-qualified means for your specific product. Pick two or three behaviours that correlate with paid conversion in your existing data. Common examples include activating a specific feature, reaching a usage volume threshold, or completing an onboarding checklist. If you do not have conversion data yet, start with Salesforce Trailhead’s PLG resources or the Salesforce Admins blog for benchmark guidance on typical SaaS activation signals. Step 2: Connect your product data to Salesforce The most common paths are a native integration from your analytics tool, a Salesforce-connected webhook from your product backend, or a middleware tool like Segment Connections or Census. Each approach writes product events into Salesforce fields or Custom Objects. Step 3: Build the trigger logic in Salesforce Flow Use Salesforce Flow to create the automation. When a product field meets your PQL criteria, Flow triggers an action. That action

10 Salesforce Automations Every SaaS Team Should Have

Salesforce is not magic. Out of the box, it is a database with a nice interface. What makes it actually useful for a SaaS company is the layer of automation built on top of it .

Salesforce Pipeline Accuracy For SaaS Companies

Your Salesforce pipeline shows $400K. Your actual closeable pipeline is probably closer to $180K. That difference is not a forecasting error. It is a structural problem that most SaaS teams at the 20 to 50 person stage have — and most do not catch it until a board meeting goes badly. There are three specific patterns that create what we call phantom pipeline. They are not exotic edge cases. They show up in almost every SaaS org we look at between 20 and 50 people. Here is what they are. What your dashboard shows $400K Pipeline total across all open opportunities ✗Deals with no activity in 60+ days ✗Contacts who stopped replying in March ✗Renewals with no opportunity attached ✗Accounts with zero product usage What you are actually working with $180K Active, contactable, closeable this quarter ✓Activity logged within last 30 days ✓Contact responded within last 14 days ✓Renewal opportunity created and staged ✓Product usage confirms active engagement 1. Dead deals that nobody closed There are opportunities in your Salesforce right now that have not moved in 90 days. They are still sitting at Stage 3 or Stage 4, still counting toward the pipeline total, and nobody is touching them. Reps do not close them because closing a deal as lost hurts their quota attainment number. Managers do not push because the conversation is uncomfortable. So the deal sits there, neither alive nor dead, just inflating the number. In practice, this means your pipeline report is showing revenue from opportunities that have a near-zero probability of closing this quarter. The reps know it. The managers suspect it. The dashboard does not. A deal with no activity in 30 days and no reply in 14 days is not in your pipeline. It is in your wish list. Those are different things. 2. Renewals that are not tracked at all At a SaaS company, renewal revenue is often more predictable than new business — but only if someone is actually tracking it. Most orgs at this stage have no renewal opportunity objects, no renewal stage, and no alert when a contract is 60 days out. What happens instead: the CS team finds out it is renewal time when the client asks why they were auto-charged. Or worse, the client reaches out to say they want to cancel, and that is the first time anyone internally knew the renewal was approaching. That is not a process. That is luck. And it means that a significant portion of your actual annual recurring revenue — the revenue that should be the most predictable number in your business — is completely invisible in the tool you use to run sales. When renewal ARR is not in the pipeline, two things happen. Forecasts are wrong. And at-risk accounts are not identified in time to do anything about them. 3. Product data that never reaches the CRM Your product knows who is logging in every day. It knows who activated three core features last week and who has not touched the app in six weeks. That information exists somewhere in your stack — in Mixpanel, Amplitude, Pendo, or whatever analytics tool you use. Your CRM has no idea. Consequently, reps spend time calling accounts that are completely disengaged, because those accounts have an open opportunity at Stage 2. Meanwhile, accounts that are thriving, using the product heavily, and expanding their team are getting no expansion outreach because nothing in Salesforce flags them as a priority. The most valuable signal in a SaaS business — actual product behavior — is entirely absent from the tool where selling happens. So the pipeline that shows up in your forecast is built on CRM activity and deal stages, not on what your customers are actually doing. 1 Dead deals nobody closed Opportunities stalled for 90 days are still in the pipeline because closing them hurts quota. Reps avoid it. Managers avoid it. The dashboard keeps counting them. No activity in 30+ days = not in your pipeline 2 Renewals with no opportunity object No renewal stage, no contract expiry alert, no tracking. The CS team finds out it is renewal time when the client asks about the auto-charge. That is not a process. No renewal object = invisible ARR risk 3 Product data that never reaches the CRM Who logs in daily, who activated core features, who has not touched the app in six weeks — all of this exists in your analytics stack and none of it is in Salesforce. Product behavior invisible to reps = wrong priorities The question worth asking today Pull up your pipeline right now. Then apply three filters: Remove every deal with no activity logged in the last 30 days. Remove every deal where no contact has responded in the last 14 days. Remove every account expiring in the next 90 days that does not have a renewal opportunity attached. What number are you left with? For most SaaS teams at this stage, the answer is significantly lower than what the dashboard shows. And knowing the real number — even if it is uncomfortable — is always better than being optimistic about the wrong one. You cannot fix a problem you cannot see. The pipeline reality check Pull up your pipeline right now and apply these three filters ✗ Remove every deal with no activity logged in the last 30 days ✗ Remove every deal where no contact has responded in the last 14 days ✗ Remove every account expiring in 90 days with no renewal opportunity attached What number are you left with? For most SaaS teams at 20–50 people, the answer is significantly lower than the dashboard. Knowing the real number is always better than being optimistic about the wrong one. Phantom pipeline is not a Salesforce problem. It is a process problem that Salesforce happens to be hiding very effectively. These three patterns show up in almost every SaaS org we talk to between 20 and 50 people. If you want to

Tag: Salesforce