“There is nothing so useless as doing efficiently that which should not be done at all.”
— Peter Drucker
The enterprise has one tool for B2B: the login screen. A partner needs to transact with you, so you build a portal, hand them credentials, and tell them to fill in forms. It took eighteen months and a budget. Your annual report calls it “digital B2B enablement” or “partner connectivity” or “straight-through processing.” Your partners call it something else. They call it a burden: one more screen to operate, one more set of credentials to manage, one more cul-de-sac that connects to nothing except your back end.
In brief: Most of what enterprises call “B2B applications” are self-service apps, by which I mean systems designed to push the operational burden of integration onto the counterparty. They automate the provider’s half of the transaction and leave the user’s half manual. When partners push back, and the larger they are the harder they push, the whole edifice collapses into email attachments and manual processing, which is what it was pretending not to be. This is the onus to comply in its purest form: the provider built a portal and declared the integration problem solved, while the partner absorbed the cost of operating it.
The Conflation
I hear it in almost every enterprise conversation about B2B. The words change but the shape does not. “We already have B2B applications. Our clients and partners log into our apps to transact with us.” Sometimes there is genuine pride in it, the pride of having shepherded a portal through a steering committee and a budget cycle. Sometimes there is defensiveness, the subtext being we have already solved this, please stop talking about it. In both cases the claim rests on a conflation that the person making it has never examined: they are treating a self-service application as though it were a B2B application. The two are not the same thing, and the gap between them is wide enough to swallow an entire operations budget.
A self-service application enables a client, a partner, or an employee to connect remotely to an enterprise and perform pre-defined transactions through a screen. The user fills in forms, submits data, downloads reports. The data flows into the provider’s systems, encompassing the provider’s ERP, CRM, and compliance platform, where it integrates cleanly with the rest of the provider’s infrastructure. From the provider’s vantage point, the architecture is elegant. Structured data arrives, validated by the provider’s own logic. No re-keying. No human middleware.
A B2B application is a different thing entirely. B2B means systems transacting with systems, data flowing from one organisation’s applications to another organisation’s applications without a person sitting between them operating a screen. The transaction is digital from origin to destination, not digital on one side and manual on the other. The self-service app is not B2B. It is a user interface with a URL.
From the user’s side, the picture is different enough to warrant its own section. But before I get there, a distinction that matters, because without it, the argument sounds like it is against self-service apps in general. It is not.
Originating Transactions vs. Relay Transactions
When an individual books a flight on an airline’s website, they are creating an originating transaction. The data does not exist anywhere else. There is no upstream business system that already holds the passenger’s name, the preferred departure time, the seat preference. The person is the source. The self-service app is the right architecture for this, because the only way to capture the data is to have the person enter it. The same is true when an individual logs into their bank and transfers funds between accounts, or when a patient fills in a registration form at a clinic. These are root-level transactions, in which the human being is not copying data from one system to another, they are creating data that did not previously exist in digital form. The self-service model was designed for exactly this.
Now consider a cargo booking. A freight forwarder books a container on a shipping line. The forwarder’s transport management system already holds every field the shipping line needs: consignor, consignee, commodity description, HS codes, package dimensions, weight, pickup location, delivery address, requested sailing date. All of it structured, validated, and sitting in a database. The booking is not an originating transaction. It is a relay, in which the forwarder is transmitting data that already exists in their own system to the shipping line’s system. The same pattern holds for an insurance broker placing a risk with a carrier: the broker’s system already holds the submission data. For a trade finance analyst submitting a letter of credit application: the corporate’s ERP already holds the transaction details. In every case, the data exists before anyone opens the provider’s portal.
There is a way to make this distinction sharper, and it matters for what follows. Every transaction has two parts: intent and content. The intent is the decision: I need to book this shipment, I need to place this risk, I need to send this invoice. The content is the data required to fulfil that intent: the consignment details, the submission fields, the line items. In an originating transaction, both the intent and the content reside outside any software system. The person deciding to book a flight is the intent. The person’s name, passport number, travel dates: that is the content. Both live in the person’s head or on paper until the moment they sit down at the screen and enter them. The self-service app is the mechanism that captures both for the first time in digital form. There are partial exceptions, such as Singapore’s Singpass, for instance, can hold some of the content about a person and transmit it automatically when they register for a government-recognised service, much like a “sign in via Google” flow pre-fills identity fields. But even in those cases, the intent still originates outside any system. The person decided to register. No software generated that decision.
I should note that the decomposition of a transaction into intent and content is not new in itself. It has formal roots in speech act theory, specifically Searle’s distinction between illocutionary force (the act you are performing: requesting, committing, declaring) and propositional content (the data the act carries). Winograd and Flores applied this to business coordination in the 1980s with their Language/Action Perspective, modelling organisational workflows as networks of commitments where each speech act carries both a force and a content. Enterprise messaging architecture implements the same split at a technical level: every SOAP envelope separates the header (what action to take) from the payload (the business data). What has not been done, as far as I can find, is to use this decomposition to explain why self-service apps fail as B2B architecture. That is what I am doing here: the intent/content split is the diagnostic tool that exposes the category error. In originating transactions, both components start outside software. In relay transactions, both already reside inside software. The self-service app treats every transaction as though it were originating, and that is the mistake.
In a relay transaction, both the intent and the content already live inside a software system. The forwarder’s TMS generated the intent, that this consignment needs to be booked on a vessel, and holds every field of content needed to fulfil it. The broker’s placement system generated the intent, that this risk needs to be placed with a carrier, and holds the submission data. The corporate’s ERP generated the intent, that this invoice needs to be sent, and holds the line items. There is nothing left for a human being to originate. The self-service app is asking a person to read intent and content from one system and manually carry both into another. That is the architectural absurdity at the centre of the “we have B2B” claim.
When the provider hands the forwarder a login screen and says “book here,” they are asking a human being, or a bot, to perform that carry. It is not data entry. It is data relay performed manually, and Drucker’s line applies with full force: the self-service app makes it efficient to do something that should not be done at all. The data should flow from system to system. Instead it flows from screen to eyes to hands to screen.
I want to be careful about this distinction because it changes the nature of the critique. I am not arguing that self-service apps are a bad idea. For consumer-facing, originating transactions, where the person is the data source, they are the right tool. What I am arguing is that enterprises have taken a model designed for individual originating transactions and applied it to B2B relay transactions, where the data already exists in the partner’s systems. The result is an architecture that forces partners to manually re-enter data that is already digital, already structured, and already validated. That is the category error at the heart of the “we have B2B” claim.
There is one more layer to this, and it has to do with the maturity of the counterparty. Not every partner has a TMS or a placement system or an ERP with clean, structured data waiting to be transmitted. A small customs broker running on email, Excel files, and a SaaS app with no connectors does not have intent and content sitting in a system ready to relay. For that broker, the self-service app is genuinely useful, giving them a structured way to submit data they would otherwise send as a PDF attachment or a phone call. The self-service model is not wrong for them. It is the right tool for the maturity level they are at.
But this is where the story bends back on itself. That small broker does not deal with one provider. They deal with dozens of counterparties: carriers, insurers, port authorities, government agencies. The moment the volume of portal interactions crosses a threshold, the same broker who found the self-service app useful is now drowning in it. They max out. They cannot hire fast enough to walk all the bridges. So they turn to Box B automations, by which I mean bots, screen scrapers, browser plugins, and copy-paste macros, and the matrix reloads. The workaround layer grows on the partner’s side precisely because the self-service model scaled past the partner’s capacity to operate it manually. The portal that was helpful at low volume becomes the source of the problem at high volume. Meanwhile, the provider, looking at their adoption dashboard, sees only that more partners are logging in more often, which they interpret as success.
The maturity spectrum matters because it means the self-service fallacy is not absolute. It is conditional. At one end of the spectrum, where individuals are making originating transactions, self-service is the correct architecture. At the other end, where enterprises with mature systems are relaying structured data, self-service is architecturally wrong. In between sits a large population of counterparties for whom the portal starts as a crutch and ends as a cage.
The User’s Reality
The user does not deal with one provider. A logistics coordinator at a mid-size freight forwarder logs into the shipping line’s booking portal, the customs broker’s document portal, the warehouse operator’s scheduling app, the marine cargo insurer’s submission platform, and the consignee’s tracking system. Each provider built their own self-service app. Each one is convinced they have “B2B” covered. The logistics coordinator, the person sitting at the other end of all these portals, has data in her own transport management system. Structured, clean, sitting in a database. To book a shipment, she opens the shipping line’s portal in a browser tab, reads the data from her own screen, and types it into the shipping line’s screen. Twenty shipping lines means twenty portals. The same shipment data, typed into twenty screens, because each provider’s self-service app connects to nothing except the provider’s own back end.
I want to be precise about what is happening here, because it is the same architectural pattern I described in “Rethinking AI for Automation” as the de-digitise and re-digitise cycle. The data was digital. It was structured. It was sitting in a system that could have transmitted it directly. Instead, a person read it from one screen and typed it into another. The data was de-digitised, meaning it was turned from structured information into something a human being could read on a screen, and then re-digitised, turned back into structured data in the receiving system. Every step adds complexity, cost, and error risk. This is not an edge case. It is the dominant pattern of B2B interaction in every industry I have worked in across three decades.
What the logistics coordinator is doing has a name. It is software-driven labour, by which I mean the manual operation of software user interfaces to bridge gaps between systems that should be exchanging data directly. I coined the term because the work is not data entry in the traditional sense. The data already exists in digital form. The work exists only because the systems cannot interoperate, and a human being is serving as living middleware between them. When I described this work in “Rethinking AI for Automation,” I placed it in Box B, the workaround layer that exists because Box A’s applications cannot talk to each other. Every self-service portal generates Box B work on the partner’s side. That is its architectural function, whether the provider recognises it or not.
The self-service app does not solve this pattern. It creates it.
The Provider’s Blind Spot
Talk to the enterprise that built the portal and you hear a set of claims that are all true and all beside the point.
“No queuing: our partners can transact without depending on our staff.” The dependency moved to the partner’s staff instead, but nobody on the provider’s side counts that as a cost.
“Available 24×7: clients can use the service outside business hours.” They do. The partner’s operations people work evenings and weekends partly because their own business hours are consumed logging into everyone else’s portals during the day.
The data-quality claim is the one that rankles most. “Minimises data errors, because the user enters data directly into our system.” This is true for the provider. The re-keying errors now happen on the user’s side, invisible to the provider, where the same data gets typed into fifteen different portals with fifteen different field names and fifteen different validation rules. The errors did not disappear. They migrated.
Then there is the claim that gives the game away: “We can communicate directly with our users: cross-sell, upsell.” The self-service app is not a B2B solution. It is a customer acquisition channel dressed in B2B clothing. The provider wants the user inside their ecosystem, on their screen, looking at their cross-sell prompts. The partner just wants to book a shipment.
I have sat in meetings, in Singapore, in London, in Mumbai, where enterprise leaders say with genuine conviction: “Use the app if you wish to do business with us.” And then in the same meeting they wonder aloud why partner adoption is stalling, why data quality from partners is declining, why their largest clients refuse to use the portal at all. The connection between those two observations has never occurred to them.
The Provider’s Hubris
The blind spot is forgivable. Not everyone looks upstream. But there is something worse than not seeing, and I have encountered it often enough that it deserves its own section: seeing the problem and deciding it is someone else’s to carry.
I want to describe this carefully, because the instinct when reading it will be to assume I am exaggerating. I am not. In more meetings than I can count, across logistics, insurance, and trade finance, I have watched employees of large multinationals say, in plain language, that they do not care if the counterparty has to deploy headcount to get data into the provider’s system. They said it plainly, in rooms where the counterparty was sitting across the table. “That is their problem, not ours.” One programme manager at a large shipping line, when told that forwarders were hiring people just to operate his company’s portal, said: “Good. That means they are using it.” He was proud of the adoption metrics. The human cost on the other side of those metrics was not his KPI and therefore not his concern.
I don’t bring this up to be unkind. For many of these companies, providing the self-service app was all they could do given their technology stack and their integration budget. I have said so in those very meetings, that the portal was a reasonable first step given the constraints. But here is where it turns from a blind spot into something harder to excuse. When I have walked into those same rooms and said, “Look, there is a way to extend what you have built, to put an automation layer on top of the portal so that partners can connect their systems to yours without anyone logging in and typing”, and the response, more often than not, is indifference. Or hostility. “We have achieved our objectives.” “The portal does what it was designed to do.” “If the overall process is broken, that is not our department.”
That last phrase is the one that stays with me. Not our department. The provider knows, and has been told in detail and with diagrams, that the self-service app generates manual work on the partner’s side. They know that the partner has to hire staff or deploy bots to operate the portal. They know that the data being re-entered already exists in digital form. Yet they do not care, because by their own internal metrics, the system works. The data arrives. The portal is live. The project was delivered on time and under budget. What happens on the other side of the login screen is outside the scope of the business case that justified the portal.
This is not a blind spot. This is hubris, the specific hubris of large enterprises that have enough market gravity to push the cost of integration onto their counterparties and never feel the resistance. When you are the largest carrier in a trade lane, forwarders will log into your portal and re-key data from their TMS because the alternative is losing access to your capacity. When you are the dominant insurer in a class of business, brokers will fill in your submission form by hand because they cannot place the risk elsewhere. The portal works not because it is good architecture, but because the power asymmetry makes it work. The employees who built it mistake market leverage for architectural correctness.
The Onus to Comply
I need to dwell on this because the structural principle underneath it is one that recurs across every integration failure I have examined. In earlier articles I described the onus to comply, the architectural question of who bears the burden of making integration work. In conventional integration, every participating application bears the burden: each system exposes an API, adopts a standard, and allows itself to be modified. That is why the long tail of integration, meaning the vast number of small integration cases each individually too expensive to justify, never shrinks: the onus falls on both sides, and the economics do not work for the hundreds of smaller connections (see “Rethinking AI for Automation” for how this principle shapes the long tail).
The self-service portal is the onus to comply at its most brazen. The provider built a portal and declared: the burden of integration is now yours. Log into our system. Learn our interface. Enter data in our format. Reconcile discrepancies on your end. The provider digitised their half of the transaction and outsourced the other half to the partner’s operations team.
The self-service app places the entire onus to comply on the counterparty, and then has the temerity to call it B2B.
The asymmetry is not incidental. It is architectural. Look at the data flow. Everything the user enters flows into the provider’s systems, the ERP, CRM, and data warehouse, where it integrates seamlessly. No manual intervention on the provider’s side. When the self-service app generates data back, whether a confirmation, a policy document, or a shipping schedule, the user receives it on a screen. Their own ERP does not know what happened. Their compliance system does not know. Their management reporting does not know. The user copies, pastes, and re-enters, or, if they are fortunate enough to have an IT team with a free afternoon, bulk-loads it from a downloaded CSV using a script nobody has maintained since it was written.
The provider digitised their half. They left the user’s half analogue. They called it B2B.
The Logjam
Scale this across an industry and the structural damage becomes visible.
A mid-market insurance broker submits business to forty carriers. Each carrier has a submission portal. The broker’s account handler opens carrier portals one after another, copying placement data from the broker’s own system into each carrier’s screen. Forty portals. Same data. Forty times. Some carriers accept Accord submissions by email; most want their own format, in their own portal, with their own validation logic. The broker’s day is a tour of other people’s user interfaces. Multiply this across functions, given that the broker also accesses claims portals, bordereaux portals, and compliance portals, and the cumulative picture is a logjam of screens, each one generating software-driven labour on the broker’s side while the carrier reports “straight-through processing” to their board.
I have watched the re-key failures in real time. An HS code entered correctly in a forwarder’s TMS gets miskeyed into one carrier’s booking portal, and a container sits in a bonded warehouse while someone sorts the discrepancy. A treaty reference typed into three different reinsurer portals carries three slightly different formats, and the reconciliation takes a week. These are not hypothetical. The cost of each error falls entirely on the user’s organisation, because the provider’s data arrived clean, having been validated by the provider’s own UI logic. The provider sees structured data. The user sees rising operational headcount.
Rope Bridges
There is a metaphor I use when explaining this, and it tends to land harder than the architecture diagram.
A self-service app is a rope bridge. It connects your organisation to one partner, one bridge, and the partner has to walk across carrying all the data on their back. It may work for one bridge. But the partner does not have one bridge. They have fifty, a hundred, sometimes more. Each provider strung a rope bridge to the partner and declared the connectivity problem solved. From any single provider’s vantage point, it is solved. From the partner’s vantage point, they are standing in a canyon with a hundred rope bridges going in every direction and not enough people to walk across all of them.
Why did I say “rope-bridge” and not “six-lane highway”? That is because a self-service application is a rope-bridge. It is positioned precariously: it is specific to the provider of that app, it requires people on the other side to learn and know how to use it, the providing party decides how long and how much the counterparty can use it. A highway on the other hand connects many origins and destinations. If one destination is closed, another one can be discovered and reached.
The partner’s response is predictable: they hire more people to walk the bridges. Or they deploy bots, specifically RPA scripts that log into the portals and fill in the forms automatically. A point-to-point workaround layered on top of another point-to-point workaround. The bot fills in the shipping line’s form, but breaks when the shipping line redesigns the portal. The bot handles the carrier’s submission screen, but it cannot handle the exception a person routes in thirty seconds. Every rope bridge now has a small robot walking back and forth across it, and someone has to maintain every robot. This is Box B growing thicker on the partner’s side, the same workaround layer I have been writing about for years, now generated by the very “B2B solution” the provider claims to have built.
The Pushback
I have been building toward this section because it is where the self-service story always ends. The pattern is identical in insurance, logistics, and trade finance; I have watched it play out in each.
Partners refuse to use the portal. The larger they are, the more likely they refuse. A shipping line’s biggest forwarder does not log into a portal. They send an email with attachments and say: “Here is our data. Get it done.” A major broker with a large book at a carrier does not type submissions into a web form. They send a spreadsheet. “This is how we work. Accommodate us.” And the provider, because the revenue justifies it, complies. They hire business support staff to use their own self-service app on behalf of the client who will not use it.
The provider now employs people to enter data into a portal that was built to eliminate the need for people to enter data. The support staff are not scalable. They are expensive. They introduce the same transcription errors the portal was designed to prevent. The client, having successfully pushed back, now also wants a monthly summary report in Excel, which someone on the provider’s side exports, reformats, and emails. Every month.
When the partner pushes back, the self-service app does not fail gracefully. It collapses into the same manual processing it was built to replace, except now the provider is paying for it.
The provider cannot see this, because from their side, the portal still works for most users, the data still arrives, the systems still process it, and the annual report still says “digital B2B enablement.” The structural damage is on someone else’s balance sheet.
What This Means
Strip away the terminology and what remains is a category error about what B2B means, and a specific instance of a much older architectural failure.
Every self-service portal is a point-to-point connection that places the onus to comply on the counterparty. Each provider builds one. The counterparty faces dozens. The integration gap between organisations, the same gap that generated BPO centres in the 2000s, RPA bots in the 2010s, and AI agents today, is not closed by the portal. It is repackaged and relocated to the partner’s operations team, where it shows up as headcount, as bots, as reconciliation spreadsheets, and as the quiet resentment of experienced operations people who spend their days serving as living middleware between other people’s screens.
The self-service portal is not a B2B solution. It is the latest incarnation of the workaround, the same Box B I have been describing throughout this series, except this time the provider built it, branded it, and pushed the cost of operating it onto the counterparty. The architecture has not moved. Only the invoice has.
The next time someone in your organisation says “we have B2B covered because we built a portal,” ask them whose problem the portal solves. Ask them how many portals their partners log into every day. Ask them what happens when their largest client refuses. Then ask them why the data, structured and digital and sitting in a database, had to pass through a human being’s eyes and hands before it reached the other side.
This article is part of the Rethinking series. For the diagnostic foundation, specifically why AI is overwhelmingly aimed at the workaround layer rather than the integration layer, see “Rethinking AI for Automation: Where the Light Is.” For how the onus-to-comply principle shapes enterprise integration economics, see “Rethinking AI for Automation: Copilot Is Not the Architecture.” For why headquarters-driven transformation programmes never reach B2B, see “Rethinking Digital Transformation: The Centripetal Fallacy.” For what the right architecture looks like when it works, see “Rethinking B2B Transactions.”
Madhav Sivadas is an enterprise software integration architect with nearly thirty years in process integration, UI automation, and enterprise workflow. He founded Inventys (acquired 2012), holds multiple US patents in software integration, and is the founder and CEO of Telligro, building AI-driven intelligent transaction networks for insurance, logistics, and financial intermediaries.
