PDS Consulting / Bundles / Customer Self-Service
Customer Self-Service Bundle
One bundled program that lands a Service Cloud foundation, a branded Salesforce Experience Cloud customer portal, and the integrations that surface the data customers actually want — not a CRM project, a separate portal project, and an integration scope nobody owns at the seams. Support volume deflection is a coherence outcome, not a portal feature. PDS sells the bundle because deflection only happens when all three components line up.
At a glance
- Includes
- CRM (Service Cloud) + Experience Cloud customer portal + Systems Integration — as one program
- Best for
- SaaS, B2B software, and professional services companies with active support volume and a customer base ready for self-service
- Two flavors
- Foundation (simpler motion, decided identity strategy) · Enterprise (multi-product, multi-language, federated identity)
- Sponsors
- VP CX / VP Service / Head of Customer Success as primary; COO where ops is in play
- Pricing
- Quote, on scope — with a transparent multi-engagement discount
Support volume deflection is a coherence outcome, not a portal feature.
The most common customer-portal pattern: the portal launches with case visibility, customers complain they can't see orders, billing, or contracts, the team scrambles to add integration scope, and integration goes live twelve months later — when customers have already stopped using the portal. The post-mortem is almost always the same: Service Cloud was configured against one view of support workflow, the portal was designed against another, and the data customers actually wanted was sitting in an ERP or billing system the portal couldn't reach. The bundle exists so that integration is in scope from day one, replacement mapping drives scope discipline, and one architect owns the handoffs across all three.
Does any of this sound familiar?
- Your support team is fielding routine cases — "where's my invoice," "how do I change my password," "what's my contract status" — that customers could handle themselves with a working portal.
- Customers ask where their order is every day. The data is in your ERP. They can't see it.
- A customer portal was launched once. Adoption was under 10%. It was turned off.
- Your renewal team can't show customers their own contract terms without manually pulling them — and that friction is showing up in renewal conversations.
- There's a CRM project, a portal project, and an integration project — three workstreams, no shared design, no agreement on what data lives where.
Three engagements, one design language.
Each component produces what the next one consumes — designed once, against the real support workflows and data flows, not three separate guesses that meet at launch.
Foundation
CRM Implementation
The Service Cloud foundation — cases, accounts, contacts, knowledge base, support workflows, and role-based dashboards. The data model and case management structure the portal depends on.
Customer-facing layer
Salesforce Experience Cloud (customer portal)
A branded customer portal — account and case visibility, knowledge base surface, self-service flows, and identity / SSO configuration. Built against a replacement-mapping discipline: every portal use case names what it replaces, or it's not in scope.
Connect it all
Systems Integration
The 3–5 flows that turn the portal from "case visibility" into genuine account self-service — order data from ERP, billing and invoice history, contract and entitlement data, asset visibility. In scope from day one, not a Phase 12 emergency.
This bundle is built on Salesforce. PDS is independent — not a reseller, with no platform partner tier — so the recommendation always serves the outcome, not a licensing margin.
How it runs — value at every go-live.
Phased delivery, with hard handoff rules that keep the three components coherent across the whole program.
01 · Joint kickoff
One discovery sprint across all three. A single executive sponsor cadence, the Experience Cloud Readiness Sprint, and a shared data model are locked before any build begins.
02 · Service Cloud live
The CRM Service Cloud foundation — cases, knowledge base, support workflows — stabilizes first. Portal design starts once the Service Cloud data model is firm. Integration design runs in parallel.
03 · Portal beta launch
Portal build follows the locked design phase. Beta launch with 10–30 real customers is a hard non-negotiable before broad rollout — this is what surfaces adoption problems before they're baked in.
04 · Broad launch + retainer
Phased customer rollout — early adopters first, broader audience second. Integration flows live. Content publishing cadence established. Hypercare, then transition to managed operations.
Two flavors, same discipline. The Foundation flavor (single-product, single-language, decided identity strategy, standard branding) uses Quick Start variants on each engagement. The Enterprise flavor (multi-product complexity, multi-language portals, federated identity across multiple IdPs, heavy custom branding, or significant data-surfacing scope) uses Full Implementation variants. Both share the same replacement-mapping and beta-launch non-negotiables — the theatre of launching a portal that nobody will use isn't on the table in either flavor. Branch point: if replacement mapping in Phase 1 reveals the portal isn't justified yet, that portion of the bundle pauses or downscopes rather than proceeding.
What the bundle delivers that separate engagements don't.
- Real support volume deflection — because the portal has the actual data customers need (via integration), built on a Service Cloud foundation that's coherent with it.
- Replacement-mapping discipline applied to the whole bundle — every portal use case names what it replaces, filtering away the 60% of typical portal features that get built and then sit unused.
- One executive narrative — VP CX or VP Service owns one program covering Service Cloud, customer portal, and the integrations that make the portal useful.
- Integration in scope from day one — portal-to-ERP, portal-to-billing, portal-to-contracts. Not a Phase 12 emergency after customers stop using the portal.
- A single content and knowledge strategy — knowledge base content audit and authoring runway are part of the bundle scope, not someone else's problem.
What you're aiming at.
- Measurable deflection in routine case categories — customers self-serving the cases that currently occupy your support team.
- Strong portal active-user adoption within 90 days of launch — well above the typical single-digit adoption rate of portal-only deployments.
- Customer self-service for the top use cases: account info, case status, knowledge base, order and invoice history, contract and entitlement visibility.
- A customer-facing brand presence that feels like your product, not a default Salesforce template.
- A knowledge base maintained sustainably post-go-live — content cadence established, not allowed to rot.
- Clean federated customer identity — no credential friction at the portal login.
Outcomes are what this bundle is built to deliver, grounded in the constituent services' design disciplines and the integration coherence that ties them together. As PDS bundle engagements close, this section gets measured numbers.
Who it's for.
- SaaS, B2B software, professional services, or subscription / contract businesses with active support volume — typically 500+ cases per month with rising trajectory.
- A customer base of 100+ active accounts — below that, a full portal is over-tooling.
- On Salesforce already, or ready to build the Service Cloud foundation as part of the program.
- With a VP CX, VP Service, or Head of Customer Success as executive sponsor, and a named champion in Customer Success Ops or Support Ops with real bandwidth.
- Knowledge base content that exists (even if scattered), or a genuine willingness to develop it — content rot is the silent killer of self-service adoption.
- Common triggers: support team drowning in routine cases, a new VP CX mandate on customer experience, a move to SaaS creating ongoing self-service expectations, a failed prior portal being recovered, or compliance requiring customers have self-service access to their data records.
When it's not the bundle.
- Without a Service Cloud commitment — route to Vendor Evaluation to make the platform decision first.
- Low support volume (sub-100 cases per month) with a small customer base — the economics of a portal don't hold, and this is over-tooling.
- Field technicians in scope — that's the Service Operations Bundle, which adds Field Service on top of the same Service Cloud + Experience Cloud + Integration foundation.
- B2C / direct-to-consumer support at high volume — that's a different shape, typically Marketing Cloud and Commerce Cloud territory.
- When the real problem is support staffing, not deflection — a portal won't fix capacity if every case still needs a human to open it.
- Without content capacity for knowledge base authoring — the Experience Cloud Readiness Sprint surfaces this; the bundle pauses or downscopes rather than shipping a portal with nothing in it.
Already on Service Cloud with adoption? A short health check often surfaces whether a lighter "portal + integration only" path is the better first move, or whether the full bundle fits.
No pitch, no pressure
One self-service program, not three separate projects.
A 30-minute call is enough to tell whether your support motion is bundle-shaped — and whether Foundation or Enterprise scope fits your customer base and identity strategy.
Book a call →Or explore the other bundles or individual services.