High-Volume Community Users: Negotiation Strategies for Large Portals
Running a large Salesforce Experience Cloud portal with tens of thousands of external users brings unique challenges. Standard Salesforce Community pricing tiers may not always be suitable for high-volume scenarios, so you may need to negotiate a tailored deal.
This guide is a strategic, plain-English advisory for CIOs, procurement leads, and enterprise architects on securing Experience Cloud bulk pricing and the right license mix. For deeper insights, read the Salesforce Community (Experience Cloud) Contract Negotiation Guide.
We’ll cover how to choose between login-based and member-based models at scale, when to use Community, Community Plus, or Partner (Channel) licenses (and newer External Apps licenses), and how to lock in protections against overages, storage, and API costs.
Use these negotiation tactics to get the best value for portals with 10,000 to 100,000+ external users.
How to Negotiate Experience Cloud for 10k–100k+ External Users
Start with the Right Model at Scale — Login-Based vs Member-Based
Choosing the core licensing model is your first big decision. Salesforce offers login-based and member-based licensing for external community users:
- Login-Based Licensing: You purchase a pool of logins per month, which all external users can draw from. This model shines when you have a high user count, but each logs in infrequently. It’s ideal for infrequent or seasonal usage – for example, a portal where 100,000 customers each log in only occasionally. You pay essentially for usage (logins), not for every single user on record. If the average user logs in rarely (e.g., a few times a month or only during specific events), the login-based model keeps costs tied to actual activity.
- Member-Based Licensing: You pay a fixed price per named user (member), who can then log in as often as needed. This makes sense for frequent or active users. If a subset of your community is logging in weekly or daily, a member-based license for each of them will usually be cheaper and more predictable than burning through login quotas. In a high-volume context, login frequency is the key driver: once a user’s login count exceeds a threshold (often just a few logins per month), it becomes more cost-effective to make them a named member.
Decision rule of thumb: If an external user logs in say 1–3 times per month or less, they are a good candidate for login-based licensing. If they log in more frequently (e.g., every week or more), consider upgrading them to a member license.
Always analyze your user behavior data to set this threshold; recalculate the login vs. member cost comparison quarterly, as usage patterns can change as your portal grows.
Hybrid approach:
In large portals, you don’t have to choose one model for all users. Many organizations adopt a mix of login-based and member-based licenses to optimize cost. For example, you might place casual self-service customers in a login-based pool (since they only create support cases occasionally), but assign member licenses to power users, such as key partners or frequent community contributors.
Segment your user cohorts by behavior and assign the model that fits each group. This hybrid strategy ensures you’re not overpaying for infrequent users, while giving unlimited access to those who truly need it.
Read about Salesforce Community Licenses Explained: Login-Based vs Member-Based.
When to Use Community, Community Plus, Partner, External Apps, or Channel Licenses
Salesforce offers various types of Experience Cloud licenses for external users, each with distinct capabilities and price points.
For a high-volume portal, picking the right type of community license for each user segment is crucial to control costs:
- Customer Community (Standard): The basic community license for external customers. It’s the cheapest option and comes with limited access (e.g., cases, knowledge articles, your contacts, or orders). Use this for B2C self-service portals or any large user base that only needs to view and update their own records or simple information. Ideal for high-volume consumer support sites where you want to keep licensing costs low and advanced features aren’t needed.
- Customer Community Plus: This license adds more capabilities, like access to reports/dashboards, the ability for external users to have roles in the sharing model, and access to more objects (such as reading related records or collaborating in groups). Community Plus is a great “middle ground” for high-volume use cases that need elevated permissions without paying for full Partner licenses. For instance, if you run a large customer or partner portal where users need to view or edit data beyond their own (such as viewing all cases for their company or collaborating with other users), Community Plus might be a suitable option. It’s more expensive than standard Community, but still significantly cheaper than Partner. Use Community Plus for external users who require advanced sharing or content access, but avoid over-speccing – don’t pay for a Partner license if a Plus license meets the need.
- Partner Community (also known as Channel Account): The Partner license is designed for your business-to-business (B2B) partners, resellers, or distributors who require broad access to Salesforce objects, including leads, opportunities, quotes, and campaigns. It includes role-based access (typically up to three roles in the hierarchy) and additional CRM functionality, similar to an internal Salesforce user, but limited to their designated channel. This license is the most powerful (and costly) of the community types. Use Partner/Channel licenses for users in a partner program or channel sales scenario – e.g., a distributor portal where external dealers register deals, track pipeline, and need analytics. In large portals, only a subset of your external users (those who perform sales or support tasks on your behalf) likely require this level of access. Others can be on cheaper licenses. Map each external user role to the minimal license that covers their needs. For example, your third-party sales reps might need Partner licenses, but the customers they serve may only need Community licenses for support – a mixed approach keeps costs aligned with usage.
- External Apps License: Salesforce has introduced External Apps licenses to support extremely high-volume portals or custom external applications built on the platform. These can also come in login-based or member-based variants. External Apps licenses often include higher limits for data and API usage by default, recognizing that an app might serve hundreds of thousands or even millions of users. Consider External Apps licensing if your use case goes beyond traditional CRM portals – for example, a large-scale consumer application or a public site requiring user logins, where standard community licenses don’t economically scale. This license uses the high-volume sharing model (similar to Customer Community) or an “External Apps Plus” variant closer to Partner-level sharing, but the key is it’s meant for bulk scenarios. If you anticipate rapid growth or need generous limits on storage and calls, discuss External Apps pricing with Salesforce. (Note: You’ll likely still negotiate custom pricing for External Apps in a large deal, but it’s good to know the option exists.)
- Channel Account License: This is essentially a form of the Partner license tailored to channel partners (distributors, brokers, agents). In Salesforce terminology, “Channel Account” licenses enable full partner relationship management features for those users. Practically, you can consider this equivalent to Partner Community in terms of capabilities; it’s often just a packaging term when selling to organizations with complex distribution channels. Use it when you have a large network of resellers or franchisees who need to manage leads, orders, or service cases in your org. Again, only assign these licenses to external users who truly perform channel management tasks – they carry a premium cost.
Bottom line: Align each external user group with the most cost-effective license tier that meets its requirements. It’s easy to over-license “just in case,” which drives up cost at scale. Instead, conduct a permissions audit: list what each cohort of users (e.g., customers, partners, distributors) needs to do in the portal. If basic Community coverage is sufficient, stick to that.
Use Community Plus only for those who need the added features. Reserve Partner/Channel licenses for actual partners managing revenue or complex data. By avoiding over-speccing, you can dramatically reduce your licensing count and spend for a 100k-user portal.
You can always upgrade a subset of users later if their needs grow, but you don’t want to be paying for Partner-level licenses for tens of thousands of users who never use those features.
Bulk Pricing Outside Standard Tiers — How to Structure the Ask
Once you know your license model and its types, the next step is to negotiate bulk pricing. Salesforce’s public price list for Experience Cloud may not even list tiers beyond a certain volume; this means that large deals are largely about custom negotiation.
Here’s how to approach it:
- Present a Growth Forecast: Come to Salesforce with a well-researched usage forecast for your portal. Outline how many external users (or login counts) you expect at launch, after one year, after two years, etc. For example, maybe you have 10k users in year 1, growing to 50k in year 2, and 100k in year 3. This aggregate user/login forecast with a growth curve shows Salesforce the big picture (and the big revenue opportunity for them). Breaking it into phase gates (say 10k, 50k, 100k milestones) is helpful. Emphasize that you need a pricing structure that supports this ramp-up.
- Request Custom Volume Tiers: Armed with your forecast, ask Salesforce to create volume-based pricing tiers beyond the standard. For instance, Salesforce might normally charge a certain rate per login for up to 10k monthly logins. But what about 100k or 1 million logins? You’ll want a lower unit cost at those higher levels. Propose a sliding scale: as you hit 25k, 50k, 100k users (or corresponding login counts), the price per user or per login steps down. Essentially, you want a bulk discount that deepens with scale. Don’t be shy about naming target prices if you’ve done internal budgeting – Salesforce expects you to negotiate.
- Structure Multi-Year Deals: For very large portals, consider a multi-year contract to secure better rates. In return for a longer commitment (say 3 years), insist on rate locks or caps. Negotiating multi-year rate holds means Salesforce can’t raise the price in years 2 or 3 once you’re deeply invested in their platform. For example, secure a fixed price per login for the contract duration, or a pre-agreed small % increase at most. A multi-year deal also allows you to align pricing with your phased adoption – you might commit to certain volumes each year and receive assured discounts at those thresholds.
- Bundle in Value-Adds: The pure license price is one lever, but include other requests in the bundle to maximize value. When proposing your bulk deal, request extras that a large deployment will require: e.g., additional sandboxes, higher API limits, and more storage (we’ll cover these non-license items shortly). The idea is to bundle these items into the negotiation while you have leverage. You might say, “In exchange for committing to 50k users by year 2, we’ll need X, Y, Z included.” It’s often easier to get these thrown in upfront than to ask (and pay) for them later piecemeal.
- Showcase Commitment but Maintain Flexibility: Let Salesforce know you’re invested in a strategic partnership. This portal is core to your business, and you’re willing to commit to Salesforce as the platform as it scales. This gives them an incentive to accommodate you on pricing. However, also convey that you need flexibility (not an open checkbook). The goal is to create a custom pricing tier that benefits both parties: you achieve economies of scale, and Salesforce gains a long-term, growing client.
By structuring the deal around your specific high-volume needs rather than accepting list pricing, you can save dramatically. For example, companies have negotiated bulk license discounts for large communities, which significantly reduce the per-user costs relative to the base price.
Salesforce has some discretion on pricing, especially when the user counts reach six figures – but only if you ask for it and justify it with a solid business case.
Overage Risk Management — Contractual Controls You Must Include
A major concern with large communities is the risk of usage overshooting what you planned. Without safeguards, a spike in logins or users could trigger hefty overage fees (or compliance issues) from Salesforce.
Negotiating overage protections into your contract is therefore essential:
- Pooled Overage Buffer: Arrange for a buffer pool of logins or users above your contracted amount that won’t immediately incur charges. For instance, if you contracted for 50,000 logins/month, negotiate that the first 5% (2,500 logins) over that are free or forgiven. This cushion covers minor fluctuations. Essentially, you want a grace zone before overages kick in, recognizing that forecasts are never perfect.
- Seasonal Grace Periods: If your portal’s usage has seasonal peaks (e.g., an annual event or cyclical demand), get a grace period for spikes. This means if you exceed your allotment in a given month or two due to a predictable surge, Salesforce agrees not to bill overages immediately. Instead, you might true-up later if the trend stays high. Define what qualifies as seasonal or one-time – for example, “up to 20% over license count for no more than 2 months in a year incurs no penalty.” This protects you from being penalized for short-term bursts that average out over time.
- Pre-Purchased Overage Packs: Another strategy is to negotiate the right to purchase additional logins/users in blocks at a discounted rate ahead of time. Rather than paying an exorbitant per-login list price when you exceed your limit, you could say, “We can pre-buy packs of 100k logins at a 50% discount if needed.” Include this option in the contract. It’s like having extra ammo on the shelf – you pay a lower unit cost for those extra blocks than you would if Salesforce had you over a barrel mid-year.
- Cap or Fix Overage Rates: At the very least, cap the overage fees in the contract. Ensure it specifies the fees you’ll incur if you exceed the limits. Ideally, negotiate a modest fixed rate for any overage logins or users (e.g., any extra login beyond our pool will cost $X, which is only 10% above our normal rate). This prevents “blank check” overages. Without this, you may face a steep overage rate that Salesforce decides later. Get it in writing upfront that overages will be charged at the same discounted rate as regular or at a known surcharge cap.
- “Material Spike” Clause: Define what constitutes an anomalous spike in usage and agree on a remediation period. For example, if user activity unexpectedly doubles overnight (beyond any buffer), rather than immediately billing, Salesforce would notify you and allow 30-60 days to adjust. This may involve purchasing additional capacity or implementing controls to reduce usage. The contract should state that you won’t be deemed in breach or auto-charged huge fees for a material spike if you work to resolve it quickly. This is a safety net for truly unforeseen growth.
- Visibility & Alerts: Ensure you have tools to monitor your usage in real-time. While not a contract term per se, it’s part of overage management. Salesforce should provide admin dashboards or reports showing login consumption, active user counts, API usage, etc., as frequently as possible (monthly at least, weekly ideally). Additionally, ask for threshold alerts – e.g., an automatic email if you hit 80% of your monthly login limit. Having contractual language that Salesforce will assist in providing usage data and alerts can support this. The earlier you know you’re trending over, the more calmly you can handle it (either by curbing usage or negotiating an increase).
With these controls in place, you can run a large community with far less fear of a surprise bill. The key is to bake in tolerance for errors in forecasting.
Overage management clauses ensure that if your 100k-user portal suddenly gets 120k users one quarter, you won’t be punished immediately – you’ll have mechanisms to handle it smoothly.
Non-License Cost Drivers at Scale — Bake Them into the Deal
High-volume portals don’t just impact license counts; they also drive up usage of Salesforce storage and infrastructure. Many customers get surprised by ancillary costs once their community is live.
Avoid that by negotiating these items upfront:
- Data Storage: Tens of thousands of users generating cases, uploading data, or interacting with records can quickly consume your Salesforce data storage allocation. Extra data storage is notoriously expensive if bought later. Negotiate for additional data storage blocks as part of your deal now. For example, if your organization comes with 100 GB of storage, but your volume projections show you’ll need 200 GB, ask for that increment at a discounted rate or even have it included. It’s easier to justify when you bundle it with a big license purchase. Ensure the contract notes the total data storage included (and any additional costs) so you’re not blindsided down the road.
- File Storage: Similarly, if community users upload files (such as attachments, photos, or PDFs), file storage can quickly balloon. Salesforce typically allocates separate file storage (for documents, content, etc.). High-volume communities (like customer support portals with lots of attachments or a knowledge repository) can hit those limits. Include extra file storage in your negotiation. Calculate expected usage (e.g., X MB per user or a certain number of files per case) and secure a buffer. Obtaining a bulk add-on now (such as an extra 50 GB of file storage) at a reduced cost is far better than making emergency purchases later.
- API and Integration Limits: Large portals often integrate with other systems (for single sign-on, data sync, mobile apps calling Salesforce, etc.). Each external user action might trigger API calls. Salesforce has API call limits per 24-hour period, which are usually tied to user licenses. But if you have mostly low-cost external licenses, your API allocation might be insufficient for heavy usage. Negotiate higher API call limits or integration allowances if you anticipate high traffic. For example, ask for a higher calls/day limit or an included add-on for extra API capacity, especially if you’re using login-based licenses (which often provide fewer API calls per license than a full internal user). Likewise, discuss concurrency limits (i.e., the maximum number of simultaneous logins or API calls) if your portal usage is expected to spike at certain hours. The contract can include these technical limits as part of the package, so you don’t hit invisible ceilings after launch.
- Sandboxes and Environments: With a large community, your development and testing needs are more extensive. You’ll want additional sandbox environments to safely build and deploy updates for the portal. Full copy sandboxes (which mirror production data) are extremely useful for high-volume sites, but by default, you may only receive one or none, depending on your edition. Negotiate for extra sandboxes or upgrades in sandbox type (e.g., get a Full sandbox, or multiple Partial Copy sandboxes) as part of the deal. Also consider if you need dedicated developer orgs for multiple teams working in parallel (common in large implementations with continuous releases). By baking these into the contract, you won’t have to pay à la carte later, and you ensure your team can maintain the portal properly with ample testing.
- Content Delivery & Performance: Consider asking about CDN (Content Delivery Network) options or any performance enhancements if you anticipate high traffic, particularly globally. Salesforce does have a Lightning CDN for static content, which is usually included; however, please clarify if any additional costs are involved for scaling it. If your community has unauthenticated public pages (accessible to guest users without login), confirm with Salesforce that you can have high volumes of guest traffic without additional licensing. It’s wise to explicitly clarify terms for guest users or anonymous page views, especially if your knowledge base is publicly accessible to millions of visitors. While not typically metered like logins, extremely high guest usage might require infrastructure considerations – ensure Salesforce is aware and supportive as part of the deal.
- Identity and SSO: If you plan to use Single Sign-On (SSO) or an external Identity Provider for your community users, confirm that Salesforce won’t charge extra for things like an Identity license. (Salesforce has an External Identity license for login-only access, but if you’re already licensing users via Community licenses, SSO capability is generally included.) Still, explicitly include that SSO for all external users is allowed, and any necessary identity features (such as social sign-on, if relevant) are part of the package. This is primarily to avoid any misunderstandings – you don’t want a situation where enabling a convenient login method for users results in hidden fees. Most of the time it won’t, but it’s good to have it documented in large agreements.
In summary, bundle all these non-license cost drivers into your negotiation. If you only negotiate the per-user or per-login price and ignore storage, environments, and other limits, you could end up under-provisioned or facing additional charges later.
By addressing them upfront, you either get them included or at least price-capped. Think of it as getting the “all-inclusive” deal for your community deployment.
Phased Adoption & True-Down/True-Across Flexibility
When committing to a large number of users, maintain as much flexibility as possible to adjust over time. Your needs at launch versus two years out may change, and a smart contract anticipates that:
- Phased Volume Commitments: Only commit to what you genuinely expect to use in the near term, with options to scale up later. For instance, instead of buying 100k user licenses on day one (and paying for unused capacity), negotiate a phased ramp. You might commit to 20,000 users in year 1, with a contractual option to increase to 50,000 in year 2 and 100,000 in year 3 at predetermined prices. This way, you’re not overspending early on, but you have the negotiated prices locked in for later phases. Salesforce often appreciates a growth plan, and you protect yourself from over-commitment. Also, ensure that if your growth is slower than expected, you’re not forced to execute the next phase on a rigid schedule without actual need – keep the timing tied to hitting adoption milestones, not just dates.
- True-Down Rights: Enterprise software contracts notoriously allow you to add licenses but not reduce them. Try to negotiate a “true-down” clause, meaning that at renewal time, you can reduce the quantity if usage doesn’t meet projections. Salesforce might resist outright reductions mid-term, but you could at least secure the right to adjust downwards at the annual renewal or contract anniversary. For example, if, after year 1, you only reach 15,000 users instead of 20,000, you could true-down to 15,000 for year 2 (or receive a credit). Even if you can’t lower the fees, having the ability to reallocate or adjust counts prevents paying for shelfware. This is tough to obtain, but in a large deal, you might be able to negotiate some flexibility here as a condition.
- True-Across License Pooling: Ask for the ability to reallocate licenses between login-based and member-based pools as needed. Usage patterns can change; perhaps you initially license 10,000 users as logins and 5,000 as members, but later you find that more users are logging in frequently (so you want to convert some of those to member licenses). Ideally, you want a license pool approach where you’ve paid for a certain overall capacity and can distribute it between login and member licenses as needed. If strict pooling isn’t possible, at least negotiate the right to swap a chunk of licenses from one model to the other at certain intervals. This “true-across” flexibility means you won’t be stuck with the wrong allocation. For example, you might agree that at each annual true-up, you can convert up to 20% of your login licenses into member licenses or vice versa, to match actual usage behavior (with cost adjustments based on the pre-negotiated prices for each).
- Mid-Term License Tier Swaps: Similarly, build in the option to upgrade or downgrade license types for a subset of users as needs evolve. Perhaps you start by adding all customers to the Customer Community. Still, next year you realize 1,000 of them need Community Plus features – you should be able to upgrade those 1,000 without a fresh, expensive contract. Negotiate a swap right between Community and Community Plus (or Partner) licenses. This might be structured as the ability to convert licenses with pricing adjusted to the higher or lower tier. The key is to avoid double-paying. If you already paid for 10k Community users and you want to make 1k of them Plus users, you could aim for a model where you pay the difference for those 1k instead of buying 1k brand new Plus licenses on top. Likewise, if some partners no longer need Partner licenses, you could downgrade them to Community Plus and pay less going forward. Having a cohort reclassification option each year ensures your license mix stays efficient.
In essence, treat your Salesforce community agreement as a living framework that can adapt. Staged adoption and true-down/true-across provisions protect you from both over-paying and under-provisioning. It acknowledges that forecasting 100k users is an educated guess and gives you room to maneuver.
When negotiating, frame it as aligning incentives: you commit to growth, but Salesforce commits to flexibility, so you grow together sustainably.
Benchmarking & Leverage — How to Strengthen Your Position
Negotiation is not just about what you ask for, but also about the leverage you have. To negotiate from a position of strength, do your homework and consider these tactics:
- Use Data and Metrics: Bring in metrics from similar portals or your own pilot to justify your licensing model and pricing ask. For example, calculate the monthly active users (MAU) and daily active users (DAU) you expect, or the average number of logins per user per month. Suppose you can demonstrate that, on average, only 20% of your 100k registered users will be active in a given month. In that case, that supports a login-based approach and bulk discount (since effective usage is lower than total users). If you have an existing community, audit its usage: “We have 10k users today with an average of 2 logins each per month.” These numbers help counter any one-size-fits-all pricing. Also, gather benchmarks from industry peers if available (even anonymized). Showing Salesforce that you know what similar customers are paying or doing can pressure them to stay competitive in your deal.
- Set a Competitive Anchor: Salesforce isn’t the only way to build an external portal. Even if you prefer Salesforce, research alternative solutions (or internal build costs) and use them as leverage in negotiations. For instance, estimate the cost of using another portal software or a combination of identity management + a custom web portal. If that alternative comes out to, say, $X per year, use that as an anchor: make clear your budget has a ceiling based on alternatives. You don’t necessarily have to name the competitor (though you can mention considering a “custom solution” or other major platform). The idea is to signal, “We have options; we’re not obliged to take a blank check from Salesforce.” This gives you leverage – Salesforce sales reps know they must come back with a compelling offer if there’s a risk you walk away. In some cases, even obtaining a quote from an alternative and (subtly) letting Salesforce know can be effective.
- Highlight Mutual Success: Position your portal project as a success story that Salesforce will want. If this portal drives significant business or if you’re a marquee customer in your industry, Salesforce may have non-monetary reasons to partner closely (e.g., future case studies, references, etc.). Use this to ask for a “success investment” from them. This can take the form of credits or free services. E.g. “We’d like Salesforce to contribute 100 hours of a success architect’s time to ensure we onboard these 50k users efficiently,” or free training for your admins and community managers, or perhaps partner enablement funds if it’s a partner community (Salesforce sometimes co-funds events or materials for partner enablement). These asks show Salesforce that you plan to grow usage (which they ultimately benefit from), and in return, you want them to have some skin in the game beyond just selling licenses. It’s a bit like asking for an onboarding package – if they invest in your success, the project is more likely to succeed, which means you’ll likely buy even more from Salesforce later.
- Be Prepared to Walk (or Simulate It): In any negotiation, your leverage is strongest if you can walk away. Even if, realistically, you’ve decided on Salesforce, maintain a stance that the deal needs to make financial sense or you have alternatives. For instance, you might say, “At that price point, it might be more feasible for us to develop a limited solution in-house or use a simpler external user portal and integrate it.” This doesn’t need to be a threat, but a factual budget consideration. It often encourages Salesforce to come back with a more palatable proposal, especially if the deal is large. They have quarterly targets too, and they’d rather discount than lose a big opportunity entirely.
Remember, knowledge is power in negotiation. Knowing your numbers and the market context will prevent you from agreeing to terms that aren’t favorable.
Salesforce reps negotiate deals every day – come to the table as an informed buyer with a clear idea of what you want. Use the fact that this is a significant, high-volume deployment to your advantage; Salesforce will compete hard to win (or keep) such a large footprint.
Governance & Operating Cadence for Large Portals
After you’ve negotiated the deal and launched the portal, the work isn’t over. Large communities require active management to ensure compliance and maximize value. Establish a governance and review cadence:
- Quarterly License Mix Reviews: Establish a process (such as a quarterly meeting with your Salesforce account team or an internal review) to assess your license usage. Check how many logins are being used vs. how many were contracted, and whether the mix of login-based vs member-based licenses is still optimal. Analyze each cohort’s behavior: Did some group start logging in more frequently than expected? Maybe those should be converted to member licenses next cycle. Or vice versa, maybe a chunk of named users aren’t active anymore – could you reduce or switch them to logins? Regular reviews allow you to adjust before it becomes a budget problem. Bring these findings to Salesforce proactively; they may help adjust your allocation within the contract terms if needed, especially if it means avoiding an overage scenario.
- Track Run Rate and Seasonality: Monitor month-to-month usage trends. A large portal may experience slow, steady growth or sudden spikes around specific events (for example, the open enrollment period for a customer portal or end-of-quarter surges for a partner portal). By tracking your run-rate (e.g., average logins per month, peak vs off-peak variations), you can anticipate when you’ll need to invoke those buffers or additional options you negotiated. For instance, if you see a steady 5% growth in active users each month, you can predict when you’ll outgrow your current allotment and plan a true-up well in advance (potentially negotiating more favorable terms for the expansion, rather than a last-minute buy). Also, if you know a marketing campaign will drive a wave of new community sign-ups next quarter, plan for how to allocate licenses or logins for that period (and inform Salesforce if you might need a temporary bump).
- Renewal Preparation: Treat each renewal (or annual contract anniversary in a multi-year agreement) as an opportunity, not a formality. A few months before renewal, review and update your forecasts and performance data. How accurate were your original predictions? Perhaps you overshot and paid for 20,000 users but only used 15,000 – use that as leverage to get credits or better terms moving forward. Or if you blew past 50k users much faster than expected, you now have an even larger scale to negotiate with – push for deeper discounts on the next tier. Also, re-evaluate license tiers: perhaps over the year, Salesforce introduced a new license type, or you discovered that certain users could be just as effective with a lower license. Adjust your license mix for the next term accordingly. In renewal talks, revisit and renegotiate buffers and add-ons as well. If you didn’t end up needing as much extra storage as you thought but ran into API limits, rebalance your asks (maybe reduce the pre-paid storage, increase the API capacity in the package). Essentially, use the data from the past term to fine-tune the next term’s agreement. Salesforce wants renewals to go smoothly, so come with a clear list of changes you want – they may accommodate many to keep you happy.
- Operational Governance: Internally, ensure someone is tasked with community license governance. This might be the Salesforce admin team or a licensing specialist. They should be familiar with the contract details and closely monitor usage. For example, if the contract says you have 1,000 API calls/day per 100 members, someone should be monitoring API usage dashboards to make sure you don’t exceed that regularly. Governance also means training your internal stakeholders: if a business unit suddenly wants to add 10,000 new users to the portal, there should be a process in place to evaluate the licensing impact and possibly involve Salesforce early. By instilling this discipline, you prevent unpleasant surprises and maximize the return on your investment.
Large portals can yield significant business benefits – including customer satisfaction, partner growth, and self-service cost savings – but they must be actively managed. By continually reviewing and adjusting, you ensure that your Salesforce Experience Cloud deployment remains cost-efficient and scalable over time, not just at the time of contract signing.
FAQ
When should we switch from login-based to member-based licenses?
Switch when a cohort of users starts logging in so frequently that the monthly login costs would exceed a flat per-user cost. In practical terms, if a user is accessing the portal on a weekly or daily basis, a member-based license becomes more economical than counting logins. Recalculate this trade-off quarterly using actual usage data. As soon as a group’s login frequency crosses the threshold, convert them to named members for cost savings.
How do we get bulk pricing beyond Salesforce’s list tiers?
By negotiating a custom deal directly with Salesforce. Prepare a multi-year adoption plan that shows how your user count (or logins) is expected to grow, and use it to request volume-based discounts above the standard tiers. Request custom pricing tiers at milestones (e.g., 25,000, 50,000, 100,000 users) with step-down unit costs. In short, you present your large-scale forecast and commit to growth, and Salesforce, in return, extends bulk discounts and rate locks that aren’t advertised on the public price list.
How do we avoid overage bill shocks?
Contractual protections. Negotiate an overage buffer (small overruns don’t bill), grace periods for seasonal spikes, and the ability to pre-purchase additional usage at a discount if needed. Also, cap any overage fees at a known rate. Essentially, ensure the contract clearly outlines what happens if you exceed your limits – ideally with forgiving terms that allow you time to adjust. Internally, set up usage alerts so you catch any surge early. These steps ensure you never receive a surprise invoice, even if your community is a bit more popular than expected in a given month.
Is Community Plus worth it for large portals?
Yes – when you need some advanced features for external users but want to avoid the cost of full Partner licenses. Community Plus is worth considering if your customers or partners require features such as roles/hierarchies, the ability to view or report on data across an account, or other elevated permissions that the standard Community license doesn’t provide. It gives you many “premium” features at a mid-tier price. For large portals, this means you can cover a wide range of user needs with Plus licenses instead of the far more expensive Partner licenses. It’s all about matching capabilities to users: if a user doesn’t need the full sales objects (leads/opps) or advanced partner features, don’t put them on a Partner license. Community Plus often covers high-volume use cases sufficiently, thereby lowering your average cost per user.
What non-license items should we negotiate upfront?
Include all the necessary extras for a successful large portal in your initial deal. This means additional data storage and file storage (to handle the load of cases, documents, etc.), higher API call limits or concurrency allowances (since thousands of users or integrations can hit org limits), and sufficient sandbox environments (full or partial copies for testing and development work). Also, iron out anything related to user access and performance: ensure SSO and identity features for external users are included, and consider asking about CDN or caching services if you expect heavy global traffic or public pages. Negotiating these upfront as part of a bundle usually gets you better pricing (or free allowances) compared to adding them later. Essentially, anticipate the operational needs of a 100k-user community and bake those line items into the contract so you’re fully covered from day one.
Read more about our Salesforce Contract Negotiation Service.
