Shared words for work that crosses from people to delivery
People operations and delivery operations need one status language when the same items pass between them often enough that misread statuses cause delays: new joiners waiting to start work, staff moving between sites, exits that leave tasks open. At that point, define a shared set of statuses for those handoffs and roll out both systems around it in one programme.
Each team has its own vocabulary for good reasons. HR talks about offers, probation and notice. Operations talks about jobs, exceptions and blocked work. Trouble starts when one word carries two meanings. To HR, pending might mean awaiting approval. To a delivery supervisor, pending might mean ready and waiting for a slot. A new joiner marked pending in one system and read as ready in the other gets assigned work before the paperwork is done.
Signs the two vocabularies are clashing
Listen for repeated questions. If supervisors keep asking HR whether someone can start, whether a transfer is final or whether a leaver's work has been picked up, HR's statuses are not answering them. If HR keeps asking operations whether a task tied to a person is finished, the reverse holds.
Look at the handoff points. Onboarding, transfers, long leave and exits all create work on the delivery side. When each produces status updates in one team that the other cannot interpret, the cost appears as idle new hires, unfilled shifts and orphaned tasks.
Reporting gives a third sign. If a leadership meeting cannot reconcile HR's headcount with operations' active workforce, the two are counting with different definitions.
Workarounds are the fourth clue. When supervisors keep a private spreadsheet of who is really ready, or HR types do not roster yet into a free-text notes field, people are compensating for statuses that fail to carry the meaning they need.
A status set for people-to-delivery handoffs
Limit it to the moments where the two teams meet. Each team keeps its detailed internal statuses, and these shared ones sit on top. Give each a one-line definition and agree who may set it, because a status anyone can change tells nobody anything.
- Requested: HR or operations has asked for a people change that affects delivery work
- Approved: the change is agreed but not yet in effect
- Preparing: the receiving team is setting up access, training, tools or work assignments
- Ready: the person or work can proceed, confirmed by the receiving team
- Blocked: something prevents progress, with the blocker and its owner named
- Completed: the change is in effect and both teams have confirmed it
- Withdrawn: the change will not happen, and any preparation should be reversed
Rolling out both systems around the shared statuses
Define the shared statuses before configuring either system. If HR's records go live with their own terms and operations later adopts different ones, retrofitting a common language means retraining both teams.
Then decide the order. Where people data is unreliable, start with HR records so operations has a trustworthy base for assignments. Where operations is losing track of work and exceptions, start there, using the shared statuses for people-related items from the first day. Either way, the second system adopts the same terms unchanged.
Map each team's existing statuses to the shared set before go-live. HR's offer accepted and onboarding in progress might both map to preparing; an operations status such as waiting for resource might map to blocked. The mapping exposes any status with no equivalent, and those orphans are usually the ones causing confusion today.
Pilot with one handoff type, usually new joiners, because both teams are heavily involved and the outcome is easy to judge: did the person start work on the planned day with everything they needed?
Stopping the shared language from drifting
Status sets drift. A team adds a status for a special case, then another, and soon the shared terms have local variants. Assign one owner from each side to approve changes to the shared statuses, and review them together whenever either team changes a process. At each review, pull a sample of recent handoffs and check whether the statuses were used as defined.
Teach the shared statuses to new supervisors and HR staff during their own onboarding. The definitions are short; using them correctly under pressure takes practice.
Scoping the people and delivery systems
BukuHR holds people records, approvals, onboarding and exit; BukuOP tracks work, status, exceptions and handoffs between teams. Fasttrade can help define the shared statuses and set the rollout order. Whether items move between the two systems is scoped in that conversation, and many teams find the shared language fixes much of the problem before any connection is built.
Frequently asked questions
Do HR and operations need identical statuses for everything?
No. Each team keeps its own detailed statuses for internal work. The shared set applies only to items passing between them, such as joiners, transfers, long leave and exits. Keeping the shared set small makes it easier to learn and less likely to drift as each team adjusts its own processes over time.
Who should own the shared status definitions?
Name one owner from HR and one from operations, with joint authority to approve changes. Neither should alter a shared status alone. Record the definitions somewhere both teams already work and review them whenever either side changes a process, opens a new site or introduces a new type of handoff.
Which handoff should we pilot first?
New joiners are usually the best starting point. Both teams are involved, the steps are well understood and the result is easy to check: the person either starts productive work on the planned day with access, training and assignments ready, or they do not. Lessons from that pilot carry over to transfers and exits.
Next step
Explore BukuHR or tell Fasttrade what your team needs.
These articles explain enterprise process design. Product availability and detailed scope are confirmed in conversation.