Skip to content

Workforce staffing for multi-team organizations

Build the right project team with the people you already have.

Potriv connects project requirements with your organization's people, skills, roles and real availability — then keeps staffing decisions explicit and reviewable.

Start with one department · Invite your team later

A worked example, not a screenshot
  1. Requirement
  2. Evidence
  3. Ranked candidates
  4. Department review
  5. Accepted allocation

Project Orion needs a Backend Engineer for 20 h / week, with Java and PostgreSQL. Team Finder ranks Mert Aydoğan at 80, Ana Popescu at 72 and Ioana Marin at 68. The top candidate is put forward as a proposal — drawn as a dashed line, because nobody is on the team yet — and Platform Engineering accepts it, which is the solid line that makes it an allocation.

00.1 EVIDENCE

Staffing decisions need evidence, an owner, and a record

A project needs particular skills for a particular number of hours. The people who could meet that need belong to departments that answer for their capacity. Potriv is built for the four things that decision needs in order to be made well.

Without one, two people describing the same ability do not match — and neither does a search for it.
A shared vocabulary for skillsVocabulary
What a project still needs is what it asked for minus who is already on it. Both have to be written down before the gap is a fact.
A gap, not just a requirementWritten down
The manager who knows what someone's week already contains is not the manager asking for their hours.
Availability from the people who own itOwned
When the approval has a named owner, there is something to look back at when the question is why somebody joined a team.
A decision somebody ownsOn record

00.2 THE RULE

Proposed and accepted are not the same thing

The sequence is above. This is the rule that governs it, and the one distinction the whole product turns on.

One request, before and after the department answers

Mert Aydoğan is put forward for 20 h / week on Project Orion. Until Platform Engineering accepts it, the connection is drawn as a dashed line and the mark is hollow: it is a proposal, and nobody is on the team. After acceptance the same connection is solid and the mark is filled.

  • An accepted allocation is the only thing drawn as a solid line.
  • A proposal stays dashed until the owning department accepts it.
  • ProposalPending department reviewNobody is on a team yet.
  • Accepted allocationAccepted by Platform EngineeringThis is the only state that puts somebody on a team.

00.3 THE PLAN

The plan, in four chapters

Each answers one question. They are meant to be read in order, but they do not have to be.

  1. ProductWhat information and decisions does the product keep straight?
  2. How it worksHow does work move from a requirement to an accepted allocation?
  3. For teamsWho owns each action, review, and hand-off?
  4. SecurityWhich controls and boundaries can be stated truthfully today?

Start with one department and one project.

Create a workspace, invite your team, and staff the work you already have. Nothing else has to be in place first.

A department, a project, and the first allocation that follows