Give Occasional Users a Door, Not a Full Seat

When a new system goes live, the default pattern is to give everyone who might need access the same seat type as the core users — it's faster to configure, and nobody wants to be the reason a stakeholder is locked out. That default is where license spend quietly balloons.

• Full internal seats are built for people who work inside the platform every day: case queues, dashboards, reporting, admin tools.
• Occasional and external users — the employee submitting a facilities request, the customer checking a shipment, the reseller updating a deal — typically need a handful of specific actions, not the whole platform.
• Most major platforms already publish lower-cost, purpose-built tiers for exactly this pattern — Experience or Community licenses, portal licenses, self-service tiers — but they only pay off if something is actually built for people to use.

Our Discovery and User Utilization agents map who is actually touching a platform, how often, and for what, so the portal decision is based on observed usage rather than guesswork.

Not everyone who needs to submit an IT ticket, check a benefits question, or request purchase approval needs a full seat in the underlying system of record. An employee service portal gives the rest of the company — the people who touch the platform a handful of times a month, not daily — a simple front door: submit a request, track its status, search a knowledge base, escalate if needed.

• A single intake surface for HR, IT, facilities, or finance requests, routed into whichever platform already owns the workflow — ServiceNow, Salesforce Service Cloud, Jira Service Management, and similar tools.
• Status visibility and self-service without exposing the full case queue, admin configuration, or reporting layer underneath.
• Built on the platform's own approved external or self-service license tier where one exists, instead of provisioning a full internal seat for every employee who might one day file a request.

Customers and partners need to see order status, open a support case, track a shipment, register a deal, or pull an invoice — not administer your CRM. A dedicated portal exposes exactly that slice of data and workflow, authenticated and scoped correctly, while keeping the underlying platform's internal seats reserved for internal users.

• Customer portals — order tracking, case submission and status, self-service knowledge base, account and invoice visibility.
• Partner portals — deal registration, lead routing, co-sell workflows, partner-tier reporting.
• Built on approved external experiences — such as Salesforce Experience Cloud, ServiceNow Service Portal, or Microsoft Power Pages — matched to the platform's own external-user licensing, so you're not paying for internal-seat capability an external user never touches.

A dedicated Forward Deployed Engineer owns the engagement end to end, supported by the same specialized AI agents used across every implementation:

• Discovery and Architecture agents map current user types, workflows, and data-access requirements before a single screen is designed.
• Configuration and Integration agents build the portal's authentication, data model, and connections back into the system of record.
• Workflow agents implement the request, approval, and routing logic so the portal is functional, not just a static form.
• Testing and Documentation agents validate access boundaries — exactly what an external or occasional user can and can't see — and document the configuration.
• Monitoring and Savings Verification agents confirm the portal is absorbing the traffic it was built for, and that license counts move accordingly after go-live.

Portal patterns differ by platform, and getting the license mapping right matters as much as the build itself:

• Salesforce — Experience Cloud sites for customer and partner portals, matched against Customer Community, Partner Community, or login-based external license types.
• ServiceNow — Service Portal widgets for employee self-service, scoped to the fulfiller vs. requester license distinction.
• Microsoft Dynamics — Power Pages for external-facing self-service tied to Dynamics data, outside of full Dynamics user licensing.
• Jira, Zendesk, Slack & Teams — lightweight request and status surfaces for employees who need visibility, not a full seat in the underlying tool.

Every recommendation is checked against the specific license SKUs and terms in play — portal and community license rules vary by platform and by contract, so the final mix is validated before anything is provisioned.

Portal projects run alongside existing implementation work, not as a separate multi-month initiative:

• Discovery — usage and role mapping across current and planned users: occasional vs. daily, internal vs. external.
• Design and configuration — the portal surface, authentication, and workflow logic, built on the platform's approved external-user tier.
• Integration and testing — connecting back to the system of record and validating access boundaries.
• License right-sizing — moving occasional and external users off full seats and onto the portal, with the license mix re-checked against actual usage after go-live.

Because PartnerMCP isn't billing by the hour, there's no incentive to keep the scope open-ended — the goal is a working, right-sized access layer, not a project that grows to fill the calendar.