The request usually arrives the same way. A commercial team wins a new customer, or an existing customer moves volume to a new division, and somebody forwards a specification document with a go-live date already on it. The date was agreed by people who assumed the connection was a formality.
It is not a formality, and the reason it does not have extraordinarily little to do with technical difficulty. Electronic data interchange – the structured document exchange behind purchase orders, shipping notices, and invoices moving between companies – is a mature, well-documented practice. The maps are not hard to build. EDI partner onboarding takes as long as it takes because of what sits in front of the map in the queue.
That distinction matters because the two problems have completely different solutions. If onboarding is slow because the work is hard, you buy expertise. If onboarding is slow because the work is queued behind other work, buying expertise makes the queue longer.
Break a single partner's connection into its real stages, and the shape of the problem becomes obvious.
Specification exchange. The partner sends their implementation guide. You read it, find the gaps, and ask questions. Their answer time is not your answer time.
Mapping. The actual translation between their document structure and yours is correct. For a standard transaction set with a competent resource, this is frequently the shortest stage in the sequence.
Test cycle. You send test documents, the partner validates, something fails, you correct, you resend. This runs on the partner calendar, and large partners run onboarding windows rather than continuous availability.
Certification and sign-off. Some partners require formal approval before production of traffic. Some require it from a team that is not the team you have been testing with.
Go-live and the first month. Exceptions surface at volume that never surfaced in test – an unexpected field, a rounding difference, a document arriving out of sequence.
Add these up honestly and mapping is rarely the long pole. The long poles are waiting for answers, waiting for a test window, and waiting for your own internal resource to become available. Only one of those three is inside your control, and it is the one most organizations never examine.
Implementation guides are written by people who already know the system. Ambiguity that is obvious to them is invisible to you until the first rejected document. Every round trip to clarify a field costs days, not hours, because it crosses a company boundary.
This is the one that decides most timelines. If the only people who can build or change a map are a small specialist team – internal developers, or a ticket queue at your provider – then every new partner joins a line behind every other request in flight. The connection is not slow. The line is.
You are ready in week two. Their onboarding team can test in week six. There is no software fix for this, but there is a planning fix: know the partner window before you commit to the commercial date, not after.
A partner is not onboarded when the first document succeeds. A partner is onboarded when the exceptions are being handled by someone who is not the person who built the map. Skipping this step is how organizations accumulate connections that technically work and quietly consume a person.
Speed claims are the standard currency in this category, and they are close to unfalsifiable as usually stated. Fast under what conditions? A standard transaction set with a cooperative mid-size partner, or a custom document with a retailer who runs quarterly certification windows? Fast for the first partner, or fast for the two hundredths?
Three questions make a speed claim testable:
None of this means fast onboarding is not real. It means the number on its own tells you nothing until you know which of your constraints it addresses.
If the queue is the constraint, then the evaluation criteria change. These are the five separate platforms in practice.
Reuse. Can a map build one partner become the starting point for the next, or does every partner start from an empty canvas? These compounds. It is the single largest driver of onboarding time at scale.
Who can build a map? Not "is it low-code" as a marketing term, but a concrete test: can the person who understands the business process – the one who knows why that customer needs a different unit of measure – make the change themselves? Ask to watch someone non-technical does it.
Test environment fidelity. Can you run a partner to test traffic against a genuine mirror of production, including the downstream ERP behavior, before you commit to a go-live date?
Visibility into failures. When a document fails, does the person handling it see what failed and why, in business terms, without opening a support ticket or reading a log?
What happens on a spec change? Onboarding is not a one-time event. Partners change their requirements. If a change costs the same as onboarding, you have not solved the problem; you have just moved it.
This is the part that rarely reaches the people who set the commercial date. A partner you cannot onboard on schedule is a customer commitment you cannot meet, a shipment that moves on manual process, or a volume ramp that slips a quarter. The cost does not appear in the integration budget. It appears in the commercial conversation, some distance from anyone who could have shortened the queue.
The Lobster Data Platform is built around the second of those five criteria: the people who run the business process make the change themselves, without writing code and without opening a ticket. Electronic data interchange in its common formats, SAP IDocs, flat files, and APIs is handled in one environment – every format your partners send, rather than one system per format – with mapping and monitoring designed for operations users rather than for specialists.
That is a narrower claim than most integration marketing makes. It also changes the queue because it changes how many people can work on it.
One practical consideration usually comes up late and should come up early: where the platform runs and who supports it. Lobster is a European-proven integration platform now delivered in North America by Bosch Mobility Platform & Solutions – with a Bosch-operated cloud footprint in the U.S. AWS region, Level 1 and Level 2 support staffed on this continent, and a dedicated North American professional services team. Cloud or on-premises deployment is both supported.