For organisations
Contribute a problem, or build your team's capability using problems you already own.
Praxora Lab runs two engagement types for organisations. An operations or transformation function with a scoped problem and no spare capacity can submit that problem into the pipeline, where a supervised cohort works it. Separately, an L&D lead or a COO can commission a cohort to build capability inside an internal team, working that team's own problems under a practitioner mentor. Both are described below, and both are priorities for this phase.
Which applies to you
| Segment | Who it is for | What you determine here | Principal objection |
|---|---|---|---|
| Problem contributor | An operations or transformation function with a scoped, non-critical problem and no internal capacity to work it. | What is required of you, what you retain, and what is exposed once a cohort sees the problem. | Confidentiality and intellectual property in the output. |
| Upskilling client | An L&D lead or a COO building capability in an internal team, using that team's own problems rather than a partner's. | Format fit, cohort size, time commitment, and evidence of prior delivery before committing budget. | Justifying the spend without a documented outcome to point to. |
Both sides of this engagement pay. Organisations pay for supervised delivery capacity or for capability building; participants pay to work a real problem toward a portfolio artefact. Praxora Lab may receive payment from each side of a single engagement. The full arrangement is set out on how we are paid.
Priority engagement, this phase
Upskill your team
An L&D lead or a COO nominates an internal team, typically one moving through change, and Praxora Lab structures a cohort around problems that team already owns. The problems are not sourced from another organisation. They come from the buyer's own backlog, so the confidentiality question that applies to contributing a problem does not arise in the same way here.
A practitioner mentor runs the cohort against the same review structure used across the pipeline: a stated quality gate, a defined contact-time allocation, and accountability for what the cohort produces. Cohort size, duration and weekly time commitment are agreed at the scoping call rather than fixed in a catalogue, because the format is set against the team's actual workload, not a standard curriculum.
What you get at the end is not a training completion record. It is a team that has worked its own problems once under supervision, with a mentor accountable for the review, and a record of what was produced that can be checked against what the team already knew before the engagement started.
A second path, not yet bookable
Supervised delivery of your own problem to a completed outcome by a cohort is a second engagement type we expect to offer. It requires our professional liability position to be finalised before we can take it on as a paid, bookable service, so it is not offered from this site at present. If that is closer to what you need, submit the problem regardless. We record the interest and will contact you directly once that path opens.
How we protect your information
Every problem submitted carries a disclosure tier, set before a cohort sees it and fixed by agreement rather than by default.
| Disclosure tier | What is published | Who approves it |
|---|---|---|
| Anonymised, public | Sector, organisation size band, domain and problem class. No organisation name and no detail that could identify it. | Set automatically at this tier once you select it at submission. No separate approval step. |
| Named | Everything at the anonymised tier, plus identifying detail up to and including the organisation's name. | Your written approval, given per instance, before anything at this tier is published. |
Submission data is encrypted at rest. Access is restricted to named individuals working on your problem, not held in a shared inbox. A retention and deletion schedule is stated on the submission form itself, at the point you submit, rather than left for you to request separately.
The intellectual property terms that apply to what a cohort produces from your problem are set out in the confidentiality and IP statement. Read it before you submit: it governs what the cohort keeps and what you keep.
The sequence, in order
What happens after you submit
- 01
Submit the problem
The intake form captures domain, problem statement, desired outcome, constraints and your confidentiality posture. It routes to the partner pipeline, not a general enquiry inbox.
- 02
Scoping call
A call confirms the disclosure tier and the access requirements before anything is shared with a cohort. Nothing about the problem is visible to participants before this step is complete.
- 03
Cohort match
The problem is assigned to a cohort with mentor capacity and relevant domain experience. Availability depends on the current pipeline, which we will state plainly if it affects timing.
- 04
Supervised delivery
The cohort works the problem for its stated duration. The mentor reviews the work against the quality gate agreed at scoping and is accountable for what the cohort produces.
- 05
Reviewed outcome
Findings are delivered within the confidentiality terms agreed at scoping. Nothing about the engagement is published beyond the disclosure tier you selected at submission.