Skip to main content

How we work

Start with what the program needs. Then decide what to build or change.

We start by defining the starting state. For an operating program, that means reading the signals already there. For a program being established, it means defining the requirements, ownership, and constraints before assumptions become the model.

The method

Diagnose / Decide / Support

The same method applies whether the program already exists or is being established. It does not assume anything is broken.

Diagnose

For an operating program, we read delivery, quality, cost, workflow, ownership, and governance together. The aim is to understand what is happening and what the records can actually support.

For a program being established, we start with the intended workflow, requirements, constraints, stakeholder needs, ownership decisions, provider assumptions, and unresolved dependencies. Those decisions are cheapest to make explicit before the operating model hardens around them.

Decide

We turn the starting state into a decision: what is known, what is inferred, and what remains unanswered.

That decision may be to build, improve, redesign, renew, renegotiate, run a selection, change how AI or machine translation is used, or move into ongoing support.

Support

Where the engagement calls for it, we help turn the decision into a working model through design, validation, documentation, working materials, and preparing the people who will own it.

When continuing help is useful, retained support covers mentoring, recurring analysis, governance, refinement, and stabilization after launch. Not every engagement needs it, and it is not folded into a fixed scope by default.

What we start with

Use what exists. Make the gaps explicit.

For an operating program, we work from the records, decisions, and provider inputs already available. For a new program, we work from requirements, constraints, ownership, and assumptions.

  • What you bring

    For an operating program: delivery records, quality results, cost and invoicing detail, workflow documentation, and governance records. For a new program: planned requirements, constraints, stakeholder access, and known assumptions.

  • What providers can add

    Where provider input is needed, that may include task-level performance data, quality methodology, and the commercial basis behind what is charged. We give you the exact request and, under retained support, may request the data on your behalf.

  • How we read it

    We read the sources together, test where they agree or conflict, and separate what is measured from what is assumed.

  • When something is missing

    For an operating program, missing information is a finding, not an automatic blocker. For a new program, missing history is normal; unresolved requirements become explicit assumptions and dependencies.

Possible outcome

No change is a valid conclusion.

The work may support building something new, changing what exists, replacing a provider, going to market, or leaving the current setup alone. We do not presume provider fault, and we do not treat an engagement as unsuccessful because the evidence supports staying where you are.

Independence

What independence means here

The standard we apply is built around what the localization program owner needs to establish, decide, and govern. These commitments protect that standard.

  • We accept no commissions, referral fees, revenue share, or other compensation tied to a provider recommendation, selection, renewal, commercial outcome, or the content of a finding.

  • We resell no software, tooling, or provider services.

  • You work with one named adviser as the single point of contact.

  • We draw on additional specialists where needed, covered by NDA and conflict screening.

Providers may engage JPK directly for work such as reporting, governance, transparency, or customer visibility. We do not alter a finding based on who commissioned the work.

Design accountability. Where we have helped design a localization system, you decide whether to adopt it. Later analysis evaluates the operating result against your objectives and available evidence, including whether the original design itself needs to change.

Operating boundary

We support the system without taking over day-to-day production.

Your team and providers keep day-to-day delivery ownership. We may take on limited hands-on work when it helps establish, test, validate, or improve the model, including targeted review or LQA. Recurring file handling, queue management, and routine daily production stay with the appointed operators.

See the engagement catalogue

Fit call

Start with the decision, not the diagnosis.

We will start with what is known, what is missing, and whether we can help.

Request a fit call

Prefer email? There is an email option on the fit call page.