So many interactions are managed through the web today that it can be difficult to know where a website ends and a personalized portal begins.
In its most simplest definition, a portal is a website that you can login into. Often, in well designed portals, it is hard to differentiate between the main website and the portal. A logged-in user should be able to easily navigate between broadcast communications ("brochure-ware") and personalized, interactive pages. Often, dynamic websites will mix the two.
As always, whenever providing site visitors with self-service to information, it is critical to consider security first (Here's an in depth
white paper on portal security to further explain the core differences).
In the diagram above, interactions to the left-side of the pipeline do not require a visitor to self-identify. Personalized interactions to the right require the visitor to login. Points P1 and P2 identify where authenticated user experiences start and anonymous interactions end.
When engaging with customers and partners online, all organizations inevitably face the challenge of:
a) Defining which online applications to offer (the bubbles in the diagram)
b) Adjusting where in the user experience pipeline the application fits
c) Defining the rules that dictate P1 and P2
Do you allow site visitors to anonymously read discussion forums, but login to post? Do you require a login to access the knowledge base or publish the KB openly on the website?
There is no single, correct answer. Each organization has it's own ideas and requirements for determining who gets access to what.
Often times, online interactions are driven by role or tier, adding an additional variable to the enforcement of P1 and P2 per application/per role (such as supporting "Platinum" and "Gold" customers with varying levels of access).
As a Salesforce partner that provides both web content management and portal solutions, we sometimes get asked "either/or" questions regarding Salesforce Customer and Partner portals and how they fit into this mix. The answer varies depending on economic, quality, customization, and frequency of user access requirements.
i-Dialogue is capable of managing the user experience (UX) throughout the entire pipeline, but is generally weighted towards serving the left side interactions, which involve converting, cultivating, and nurturing Leads online. i-Dialogue tracks the conversion from Lead to Contact (while maintaining the same account name/password on the site) and maintains a consistent UX online, using Dialogue Script and role-based security to enable personalized interactions. These web/portal solutions are customized using DHTML and Dialogue Script. This model is licensed per website and the entire UX is managed within the website.
Alternatively, Salesforce Customer and Partner Portals start from the far right side of the UX pipeline. They assume the relationship already exists in Salesforce and leverage Salesforce native profiles for defining self-service access to applications. Leads are not supported and the transition from Lead to Contact/Portal User requires some planning and manual intervention. These portals are customized using Apex and VisualForce. This model is licensed per user and the UX is managed in Salesforce.
In recent implementations, a hybrid solution has worked extremely well for us where i-Dialogue is used to manage the online interactions for users that visit the site < 5 times per month and Salesforce Customer or Partner portal is offered to power users that have daily interaction requirements.
We've even developed some simple VisualForce user experiences and are looking forward the day Salesforce allows Developers to package and deploy Apex portal solutions to further evolve this hybrid concept.