Skip to content
Governance and change

External requesters, and a permission model that expects them.

Customer Service Management applies service management practice to external customers rather than internal employees, with a portal and a support model built for people outside the organization. Our work is external requester models, portal design, and the identity work that external access requires.

Customer Service Management extends service management to people outside your organization. That changes the identity question, because the requester is no longer in your directory.

What it is

Customer Service Management applies service management practice to external customers rather than internal employees, with a portal and a support model built for people outside the organization.

It is for organizations already running internal service management well who are being asked to do the same for customers, usually by a team that has been managing it in a shared mailbox.

request review approve change record who decides, and on what evidence the gate is defined before anything is automated L1 L2 L3 L4

What it does

A portal for people outside the directory

External requesters get an account model of their own, which is a deliberate design rather than a group exception.

Service practice applied externally

The same queues, SLAs, and knowledge structure, with a different audience and different expectations.

Where it fits

L3, governance and change, with an unusual demand on L1. Every other product assumes the person is in your directory. This one does not, which makes the external identity model a design decision rather than an inherited default.

Where it earns its place

A support function living in a shared mailbox

The move is not the hard part. Deciding what a customer may see about their own account is.

An organization with contractual response times

Where SLAs are written into agreements, the reporting matters as much as the queue.

Questions we get

Can this share configuration with our internal desk?
Some, deliberately not all. Shared schemes keep it maintainable; separate portals and permissions keep external requesters from seeing internal work.
How do external users authenticate?
That is the design question, and it is worth answering before the portal is built rather than after a customer sees something they should not have.

Licensing

External requesters are not licensed like agents, so the count that matters is who works the queue rather than who submits to it. That reconciliation sits with the rest of the estate in licensing and renewals.

Find out what your controls would survive.

Fixed scope. The assessment looks at permission architecture, change control, and every place audit evidence is still assembled by hand. You get the findings, the ownership gaps, and the order to close them in.