Where responsibility sits when technical detail carries regulatory weight

An intermediary asks an Australian OEM for access to repair procedures, diagnostic information and continuing updates.

The request sounds straightforward. Then the internal questions begin. What information is actually required, and what will the intermediary do with it? Which entity owns it, and can the existing platform deliver it? Does headquarters need to approve the arrangement, and who supports it once access begins?

Aftersales understands the market requirement. Legal needs accurate facts before assessing the position. Technical Information or Engineering knows what information exists. IT controls part of the delivery environment. Commercial and Finance weigh the cost and terms. Headquarters may control the information, policy or licence, and an external provider may operate the system.

Each function holds part of the answer. None necessarily holds all of it.

The answer is not to make one function responsible for everything. It is that one person or team should coordinate the request, while material decisions remain with the people who have the relevant authority and information.

WHAT MATTERS

• Coordinating a request is not the same as owning every decision.
• Technical facts should be complete enough for the authorised decision-maker to act, but technical teams should not be expected to make legal or commercial decisions outside their role.
• The critical chain is facts → decision → implementation → retained evidence.

Coordinating the work does not mean owning every decision

A cross-functional request needs someone to coordinate the work, but that person does not need authority over every decision. Depending on the organisation, coordination may sit in Aftersales, Technical Information, compliance, licensing or another relevant function.

The coordinating role is practical: clarify what decision is required, bring together the relevant technical and commercial facts, identify the right decision-makers, connect the outcome to implementation and keep the request moving where issues need to be resolved elsewhere.

A local Aftersales manager may coordinate the Australian request without being authorised to interpret legislation, change a global platform, commit headquarters resources or sign a licence. Legal may assess the organisation’s position without controlling the information source or delivery system, while Engineering may confirm what data exists without deciding whether a proposed use should be accepted.

The important distinction is between coordinating the process and making the individual decisions within it. That coordinating role should also keep internal complexity away from the intermediary: the recipient should not have to work out which headquarters team controls the platform or which entity owns an approval, and a single coordinating contact should provide a coherent route while the organisation manages its own internal interfaces.

Technical facts can change the decision

“Access to repair information” can describe very different arrangements. One request may concern workshop documents delivered through an existing portal. Another may involve structured files, diagnostic software, an application programming interface, security-related information or regular data transfers into an intermediary’s product.

Those differences affect what is actually within the request, which vehicles and systems it covers, whether it can be separated from other content, how access is provided, which security and authentication controls apply, and what the intermediary can practically do with the result. The legal or commercial answer may therefore depend on facts that sit with Engineering, Technical Information, IT or a provider rather than with the eventual decision-maker.

The practical requirement is straightforward: technical teams should establish the facts and their limitations clearly enough for the right decision-maker to act. A summary that removes a material limitation—such as a platform that cannot separate information categories or a delivery route that cannot support the proposed use—can change the question being decided.

Group responsibilities around the decision, not the organisation chart

In a global OEM environment, the market knowledge may sit locally while the platform, source data, licensing template, intermediary relationship or delivery capability sits with headquarters, a regional team or an external provider. A workable arrangement groups the work around what needs to happen:

• coordination, keeping the request moving and the internal interfaces connected;
• technical facts and delivery, establishing what information exists, how it can be supplied and what limitations apply;
• legal, compliance and commercial decisions, determining the organisation’s position within the relevant authority;
• implementation, configuring the approved arrangement so it matches the decision; and
• record keeping, preserving enough evidence to explain what was decided and what was actually implemented.

Several of these roles may sit with the same people, or they may span multiple entities and countries. The allocation should reflect who can decide, who knows and who can act—not simply who first received the request.

Most failures occur between the steps

A reliable arrangement follows a simple sequence: request → facts → decision → implementation → retained record. The value is not in naming the steps; it is in keeping the hand-offs between them intact.

From facts to decision

The authorised decision-maker needs an accurate account of the relevant facts and limitations. If a platform cannot currently separate certain information categories, that limitation should remain visible rather than being reduced to a general statement that “the information is available”.

From decision to implementation

The people configuring access need a clear statement of what was approved. An agreement may authorise one information scope while a standard platform package delivers another, or a temporary workaround may quietly become the permanent operating position. Implementation should therefore be checked against the actual decision, not against informal recollection.

From implementation to record

The organisation should be able to establish what was ultimately delivered, when it began, what exceptions remained and where the supporting records can be found. That does not require every email and file in one repository. It requires enough connection between the records that a successor can reconstruct the matter without relying on personal memory.

Escalate the decision, not the correspondence

Where an issue cannot be resolved within the established authority or operating process, escalation should identify the decision required, the relevant facts, the unresolved point, the available options and the required timing. Passing a senior executive a chain of correspondence and asking for “guidance” transfers the reading burden without clarifying what actually needs to be decided.

Scale the approach to the request

A routine request operating within established parameters may need only a known coordinating contact, established authorities, current technical contacts and a retained decision record. A request involving new information, a provider dependency or changed controls may need more explicit technical, legal and commercial input, followed by implementation verification. A novel or high-consequence arrangement crossing jurisdictions, systems or headquarters mandates may justify senior oversight and a defined review point.

The objective is not more meetings. It is enough structure to avoid delay, inconsistent commitments and repeated reconstruction.

The responsibility test

1. Who is coordinating the request?
2. What decisions are required?
3. Who has authority to make each one?
4. Who holds the relevant technical and operational facts?
5. Who will implement and support the approved arrangement?
6. Where will the decision, implementation and open issues be recorded?

Could someone new to the request follow it from the original facts, through the authorised decision, to what was actually implemented?

If not, naming one function as the owner has not closed the practical gap.

Effective responsibility does not mean putting every decision into one function. It means keeping the people who coordinate, decide, supply the facts, implement and record the arrangement connected.

The objective is simple: one coherent arrangement, even when the work behind it sits in many places.