Supplier portals: when to configure, when to build
Ariba already gives suppliers a network. A custom portal earns its cost only for journeys the platform does not serve well. Here is the honest decision frame.
Nexolve TechnologiesDelivery team
The two wrong defaults
Default one: build a portal because the platform UI feels dated, then spend the budget re-implementing registration, onboarding and document exchange the platform already does. Default two: force every supplier journey through the network UI, including the ones it genuinely handles poorly — guided onboarding for low-digital-readiness suppliers, status visibility for logistics partners, brand-sensitive experiences.
Both waste money. The question is not build or buy; it is which journeys justify custom software.
A decision frame that holds
Configure when the journey maps to a platform capability: registration, sourcing events, PO flip, invoice status. The network already does these at scale, and your suppliers' other customers use the same flows.
Build when the journey is yours alone: a branded onboarding experience for a fragmented supplier base, a status portal combining Ariba data with your logistics feeds, an internal intake tool shaped to your operating model. Custom software earns its cost when it combines platform APIs with context the platform does not have.
If you build, build on the APIs
A supplier portal should sit on top of the platform, never beside it. Ariba APIs carry the transaction; the portal carries the experience. That way the portal can be replaced, reskinned or extended without touching the system of record.
And plan the support model before build starts: who owns the portal after go-live, under what service level, with what release discipline. An unmaintained portal is worse than none — suppliers remember the one that stopped working.
