Carry the context
No retyping the same roles, dates, and capacity after a tender is won.
ENTERPRISE SOFTWARE / WORKFORCE OPERATIONS / 2026
RelayA tender won.
A tender won.
A team ready.
Connecting the moment a company wins a project to the people who will bring it to life.
One workspace for tender handoffs, team formation, capacity planning, and the evidence behind every staffing decision.
01 /
Winning is only the first handoff.
The business problem is the gap between commercial commitment and delivery readiness.
The starting hypothesis
Award information, staffing spreadsheets, and people’s project history can live in different places. A resource manager may know who is available today without knowing who is available for the entire project—or why that person fits the work.
The product opportunity
Turn the award into a structured request, preserve the scope, and make staffing evidence visible at the decision point. The intended business value is less handoff effort, fewer avoidable conflicts, and clearer accountability for delivery readiness.
How might we turn a tender win into a team that is available, capable, and ready to deliver?
Make fit explainable
Show the capability evidence and constraints behind a recommendation.
Keep decisions human
Suggest a team, then ask a resource manager to review and commit.
02 /
Design around the handoffs between people.
Role-based task models define what needs to be learned before validating the solution with users.
| Role / job to be done | Decision they need to make | Evidence the interface provides |
|---|---|---|
| Bid owner | When a tender is won, hand over its delivery needs without losing scope. | Client, domain, delivery window, staffing deadline and role demand. |
| Resource manager | Assemble a team I can justify, within real availability. | Position requirements, fit breakdown, profile context and capacity checks. |
| Delivery lead | Understand who is assigned and what support the team may need. | Confirmed allocations, capability gaps and project-specific feedback. |
| Practice lead | Spot scarce capabilities and coaching opportunities. | Discipline capacity, domain exposure and feedback with sample size. |
| Team member · future role | Understand and correct the evidence used in my profile. | Planned self-service review and correction workflow; not yet implemented. |
Discovery plan / test the riskiest assumptions first
Contextual interviews
Recruit 2 bid owners, 3 resource managers and 2 delivery leads. Walk through the last real tender handoff, using redacted artifacts. Ask where scope changed, who reconciled capacity, and what evidence informed selection.
Artifact walkthrough
Inspect a redacted demand sheet, allocation plan and project review. Map field ownership, update cadence, missing data and the places where people re-enter the same information.
Assumption checks
Test whether percentage capacity is the planning unit, how often skills are reviewed, and whether one staffing request per tender fits the organization. Change the model if work packages need separate ownership.
Synthesis method
Group observed breakdowns by handoff, evidence, capacity and accountability. Separate an observed behavior from an interpretation; link each prioritized requirement to its evidence.
What would change the design?
If staffing is managed in hours, introduce calendars and working patterns. If tender scope changes after award, add versioned work packages and change approval. If capabilities are self-reported, show their source and review date before using them for matching.
03 /
A system, not a collection of screens.
The request links commercial intent to individual positions. The allocation links a position to a person, a time window, and a capacity commitment.
Service blueprint / where responsibility changes
LayerWinForm the teamCommitManage
User actionBid owner confirms the awardManager compares people and saves a proposalManager reviews the team and rationaleManager adjusts an allocation or records feedback
Visible responseLinked request appears in the staffing queueRequirements, evidence and availability stay in contextConfirmed positions and remaining demand are visiblePlanner, coverage and profile context update
System actionCreate request and audit event in one saveCompute fit and overlapping commitmentsValidate the whole proposal and persist atomicallyRecalculate request status and append the audit event
RecoveryRepeated award creates no duplicateNo eligible candidates? Inspect constraintsConflict or stale revision? Keep previous commitmentsA release reopens the position instead of losing demand
04 /
Follow one tender all the way through.
A connected award-to-allocation journey. The working prototype uses sample records and persistent data.
WORKING MODEL / TWO DIFFERENT DECISIONS
A strong match is not necessarily an available person.
01 / Review the evidence
02 / Check the commitment
What the evidence shows
The staffing view explains why a person fits a position. The planner shows whether commitments fit in time. Keeping these views connected avoids treating a recommendation as permission to allocate.
The design tradeoff
A separate capacity check adds friction at confirmation. That friction prevents a persuasive fit score from hiding an infeasible commitment.
Screens use sample project and resource data. Fit is a transparent design rubric, not a validated prediction of employee success.
01
Capture demand while the opportunity is still a tender.
Create a draft with the client, domain, value, delivery window, staffing deadline and required roles. Each role has a headcount, allocation percentage and capability standard. Submit the bid, record its outcome, and open the linked request when it is won.
02
Build the team one position at a time.
For the Unified citizen services tender, the request carries seven positions. Select a position to compare people in the same discipline. The candidate panel explains skill alignment, domain evidence, relevant history, and available capacity across the delivery window.
“Suggest available team” assembles a reviewable proposal. It does not commit anyone. A manager can change candidates, inspect a profile, confirm a partial team, or document why a lower-fit candidate is appropriate.
03
Understand the person behind the match.
Profiles connect capabilities, existing commitments, past project contributions and written feedback. Capability reviews update matching inputs. Feedback must be linked to a project associated with that person; the interface shows the reviewer, date, strengths and growth area.
04
Manage the commitment after the team is formed.
The weekly planner exposes peaks in committed capacity. Adjust percentage and dates with a reason, or release an allocation and reopen its position. Insights show capacity by discipline, domain exposure in full-time equivalents, and feedback patterns that lead back to the underlying profile.
05 /
The decisions that make the product trustworthy.
The difficult parts are the meaning of a recommendation, the timing of a capacity check, and what happens when a plan changes.
01 / Replace “likelihood of success” with an explainable fit score.
The brief asked for a likelihood of succeeding on the tender. Without labeled delivery outcomes or a validated predictive model, a percentage would imply more certainty than the evidence supports. Relay instead shows a deterministic evidence score and keeps availability as a separate constraint.
Why this matters
A person with a perfect skill match can still be unavailable. A person without prior domain experience can still be a reasonable choice with support. A low score is an invitation to inspect evidence, not a verdict about someone’s potential.
The tradeoff
The 70/20/10 weights and threshold of 70 are design assumptions. They prioritize task capability and give domain history a supporting role. They need calibration with resource managers; no predictive accuracy is claimed.
02 / Check the entire delivery window.
The confirmation step checks the maximum overlapping load for every proposed allocation. It also checks the other people and positions in the same proposal. One failing position rejects the entire confirmation, preserving the last saved plan.
03 / Treat performance as context, not a league table.
Workforce insights surface consistent strengths, development areas, and limited evidence. Written feedback remains tied to a project and review date. Ratings are displayed with the number of reviews; they are not used in the fit score. This keeps a coaching signal separate from staffing eligibility.
04 / Use progressive disclosure for operational density.
The dashboard answers “what needs attention?” The request builder answers “who should fill this position?” Profiles and match explanations open only when they support the current decision. A persistent navigation rail keeps the operational context stable.
Muted surfaces support long scanning sessions. Teal identifies primary actions, amber indicates a constraint, and text labels accompany status colors. Tables retain horizontal scrolling on small screens; the team builder stacks into a single column.
Ink / hierarchyTeal / actionMint / selectionAmber / attention
06 /
What works, and what comes next.
Functional checks establish that the prototype behaves as designed. Research with real users must establish whether it solves the right problem.
Implemented acceptance criteria
- A submitted tender can be won and creates one linked request.
- Suggestions remain proposals until a manager confirms.
- Capacity conflicts block confirmation without partially saving the team.
- Releasing an allocation reopens its position.
- Changes persist after refresh, with stale updates rejected.
- Profiles connect skills, project history and project-specific feedback.
Usability study / planned
Run moderated sessions with five resource managers and two delivery leads using anonymized scenarios. Ask participants to think aloud; record task completion, time, errors, confidence and unexpected workarounds.
Do not explain the recommendation before asking the participant to interpret it. The key question is whether they understand both the evidence and the constraints.
| Scenario | What to observe | Design response if it fails |
|---|---|---|
| Award a tender and locate its request | Can the participant find the handoff without help? | Strengthen the linked request confirmation and queue entry. |
| Choose between a strong match and an available match | Can they distinguish fit from eligibility? | Separate the two labels further and expose the capacity window earlier. |
| Confirm a partial team with one capability gap | Do they understand remaining demand and rationale? | Clarify coverage, explain the gap and make the unresolved positions explicit. |
| Move an allocation into a conflicting week | Can they understand the rejection and recover? | Show the conflicting commitment and guide them back to an editable field. |
| Explain a development signal to a delivery lead | Do they inspect review context rather than infer a permanent ranking? | Revise labels, recency cues and the path into the underlying feedback. |
Measurement plan / targets need a baseline
Handoff latency
Award recorded → request available. Track failures and duplicates separately.
Time to staffing
Request created → first allocation and complete team. Segment by demand size.
Decision quality
Track rejected conflicts, staffing reversals, rationale use and user confidence.
07 /
Designed through to the working model.
The implementation connects a versioned database, validated commands, and a traceable activity log.
Delivered in the prototype
Seven connected product areas, tender creation and award, automatic request creation, editable team proposals, explainable matching, confirmed allocations, capacity adjustments and releases, resource creation, capability reviews, project feedback, and derived workforce insights.
What production would need next
Authentication and role-based permissions, tenant isolation, approved data sources, time-off calendars, feedback access rules, employee correction rights, scope-change workflows, and a notification service. These are the next steps for operational rollout.
The next design iteration
Validate the planning unit and matching rubric first. Then prototype the highest-risk exceptions: tender scope changes, project extensions, leave, and employee review of capability evidence. Those questions determine whether the next iteration should support day-to-day resource planning.