灵活用工平台

项目概览

灵活用工平台是一个面向酒店、医院、工厂等用工场景的 B2B2C 产品。

在这个项目中，我负责产品经理与交互设计相关工作，参与从前期调研、需求梳理、竞品分析，到平台架构、信息架构、用户流程和原型设计的完整过程。

这个项目的核心不是做一个“招工工具”，而是把原本依赖电话、微信群、表格和人工对账的用工流程，转化成一套可协作、可追踪、可持续迭代的平台系统。

背景：这个项目涉及企业、劳务、灵工和平台运营四类角色，需要先说明整体业务关系。

设计判断：用一张总览图先建立角色关系和主流程，再进入具体研究、架构和原型。

影响：帮助招聘者快速理解项目复杂度，不把项目误解成单一招聘工具。

背景

酒店、医院、工厂等行业都有明显的临时用工需求。尤其在酒店行业，客房清洁、厨师、保安、水电工等基础岗位占比较高，用工波动大、人员流动快。

在前期调研中，我们发现企业面对的并不是单一的“招聘难”。真正影响业务运转的是一整条链路：岗位发布、人员报名、到岗确认、工时记录、薪资结算、发薪和评价，每一步都可能因为信息不清、状态不同步或责任不明确而产生问题。

劳务公司也面临类似情况。他们需要同时管理客户需求、灵工人员、考勤记录、结算对账和服务质量。如果所有信息都分散在聊天记录、Excel 和人工沟通里，规模一大，管理成本会迅速增加。

背景：该图用于说明酒店基础岗位占比、行业用工压力和政策背景。

设计判断：在案例开头先解释为什么这个问题值得做，而不是直接进入界面展示。

影响：建立项目的业务合理性，让读者理解平台不是凭空产生的产品想法。

我的角色

我在项目中承担产品经理 / 交互设计师角色，主要负责：

• 前期需求调研与利益相关者访谈；
• 同类产品和市场竞品分析；
• 产品范围与功能优先级梳理；
• 平台架构和信息架构设计；
• 多角色用户流程设计；
• 关键状态与异常路径梳理；
• 原型设计与上线协作。

研究与发现

为了快速进入这个行业，我们采用了三种方式理解问题。

第一是利益相关者访谈。我们访谈了酒店业主、酒店人事经理、劳务公司负责人和专职灵工，从不同视角理解他们在招聘、到岗、考勤和发薪中的实际问题。

第二是参加行业展会。展会让我们可以直接接触劳务公司、酒店和相关服务商，观察他们对灵活用工平台的关注点，也更快判断市场中的真实需求。

第三是竞品分析。我们分析了蓝鸟云、智工云、智鸟灵工、青团社等同类产品，重点看它们如何处理岗位发布、人员管理、考勤、结算和平台服务。

这些研究帮助我确认：这个产品不能只做成一个“岗位信息发布平台”，而需要围绕多角色协作建立完整的业务系统。

利益相关者访谈

从酒店业主、人事经理、劳务公司负责人和专职灵工四类视角理解真实业务问题。

背景：访谈了约 10 位相关者，包括酒店业主、人事经理、劳务公司负责人和专职灵工。

设计判断：先通过访谈确定各角色的核心诉求，再进入平台结构和功能设计。

影响：避免产品从内部想象出发，把复杂平台建立在真实角色和真实问题上。

展会调研

展会调研：在行业现场观察酒店和劳务公司的真实关注点。

背景：展会图片用于展示团队参加迈点文旅节，与酒店和劳务公司直接接触。

设计判断：通过行业现场快速补充一手市场信息，减少只看线上竞品的片面性。

影响：帮助团队更快判断客户真实需求和市场接受度。

同类产品分析

对比蓝鸟云、智工云、智鸟灵工和青团社等产品的功能结构、用户体验和产品定位。

背景：该部分用于说明如何理解市场现有解决方案。

设计判断：不只看视觉表现，而是重点分析岗位、人员、考勤、结算等核心业务能力。

影响：为后续平台功能边界和差异化定位提供参考。

关键洞察

洞察一：企业需要的不是单点招聘，而是连续管理

用工企业真正关心的是：人能不能按时到岗、工时是否准确、薪资是否按时发放、后续服务是否可评价。只解决“找人”并不能真正降低企业的管理成本。

这让我在设计时把重点放在完整履约链路上，而不是单独强化招聘入口。

洞察二：不同角色需要不同的信息视角

用工企业、劳务公司、灵工和平台运营看到的是同一件事，但关心的不是同一层信息。

企业关心岗位和用工结果；劳务公司关心派单和人员管理；灵工关心报名、到岗和收入；平台运营关心审核、异常和服务质量。

因此，系统不能用一个统一后台塞给所有人，而要按角色拆分任务和权限。

洞察三：状态清晰是平台信任的基础

灵活用工中最容易产生争议的地方，往往不是页面不好看，而是状态不清楚。

谁已经报名？谁确认到岗？工时是否确认？薪资是否结算？异常由谁处理？

这些状态如果无法被系统记录和追踪，平台就很难建立信任。

背景：该图集中展示了前期调研后得到的用户痛点。

设计判断：将痛点从单点问题归纳为连续业务链路中的断点。

影响：为后续主链路设计提供明确依据。

设计挑战

这个项目最大的挑战，是把一个线下强依赖人工沟通的复杂业务，转化为线上可执行的流程。

它涉及企业、劳务公司、灵工、平台运营等多个角色，也涉及招聘、考勤、结算、发薪、保险、税务、众包、评价等多个业务模块。任何一个环节没有设计清楚，都会影响后续业务推进。

设计决策

决策一：按角色组织产品，而不是按功能堆模块

我没有直接把所有功能放进一个后台，而是先梳理不同角色的任务边界，再决定他们应该看到什么、能操作什么、对哪些状态负责。

这样可以降低每个角色的学习成本，也能避免平台运营、企业和劳务公司之间的责任混乱。

平台架构

平台架构：围绕企业、劳务公司、灵工与平台运营组织系统能力。

背景：包含整体解决方案与平台架构图，可与角色总览图组合展示。

设计判断：先定义角色与模块边界，再展开具体界面。

影响：帮助复杂系统形成清晰的协作结构，降低后续设计和开发返工。

决策二：用统一状态串起核心链路

围绕“岗位发布—报名—到岗—考勤—结算—发薪—评价”这条主线，我把每个关键节点都设计为可追踪状态。

这样做的目的，是让每个角色都知道当前任务走到了哪一步、下一步该由谁处理、出现异常时应该如何介入。

状态定义

分别定义灵工、用工计划、客户与班组状态，并明确每次状态变化的触发条件。

背景：灵活用工中很多争议来自状态不清，例如是否到岗、工时是否确认、薪资是否结算。

设计判断：用统一状态连接多角色任务，并明确接单、考勤确认、结算和异常分支的转换条件。

影响：提升平台可追踪性，为后续对账、异常处理和服务质量评估提供依据。

决策三：先跑通主链路，再扩展更多商业能力

灵活用工涉及很多可扩展模块，例如保险、税务、保理、众包和评价。但在 0 到 1 阶段，如果把所有能力一次性放进首版，很容易拖慢交付，也会增加验证难度。

所以首版更聚焦招聘、到岗、考勤、结算和发薪这条主链路。只有主链路跑通，后续模块才有继续叠加的基础。

信息架构

先把不同角色看到的结构整理清楚，再展开流程和界面。

角色级信息架构

灵工端和企业端的模块边界不同，信息结构也不同。

背景：包含整体解决方案与平台架构图，可与角色级信息架构组合展示。

设计判断：先定义角色与模块边界，再展开具体界面。

影响：帮助复杂系统形成清晰的协作结构，降低后续设计和开发返工。

用户流程图

把关键业务路径、状态变化和异常处理放在同一组里看，才更容易发现流程断点。

流程证据图组

从角色协作、跨端状态到支付与考勤等关键流程，整理成一组可阅读的流程图。

背景：这组图用于串起岗位发布、报名、到岗、考勤、结算和发薪等核心链路。

设计判断：用流程图暴露角色、状态和异常路径之间的关系。

影响：帮助团队更早发现流程断点，并降低原型阶段返工。

原型与设计图组

这一组收纳最能说明界面结构、任务组织和页面落地的图片。

原型设计图组

完整展示平台在不同业务任务下的 Web 端原型页面。

背景：这些图片来自项目原型设计阶段，覆盖平台 Web 端的核心业务页面。

设计判断：按原型序列集中展示，让任务组织、信息层级和页面结构可以连续阅读。

影响：更完整地呈现复杂业务如何从平台架构落实到具体页面。

验证

原型与流程通过业务评审、开发走查和上线后的真实接入持续验证。这里不声称具体任务成功率提升。

结果

以下数据来自公开项目记录，反映产品上线后的业务进展；融资是公司层面结果，不作为单一设计决策的直接成果。

反思

0→1 平台最容易把“业务完整”误解为“首版功能越多越好”。这次工作让我更明确：先定义角色、状态和资金相关的关键路径，再扩展模块，比先画完整功能地图更能降低产品风险。

Background

Hotels, hospitals, and factories rely on flexible labor for volatile frontline demand. The product challenge extended beyond recruitment: job publishing, worker assignment, arrival, attendance, settlement, payroll, and evaluation all needed to remain connected and traceable.

My Role

I worked as Product Manager and Interaction Designer across stakeholder interviews, competitor analysis, product scope, platform and information architecture, multi-role flows, prototypes, and launch collaboration.

Research & Discovery

We interviewed approximately ten stakeholders across hotel owners, HR, labor agencies, and flexible workers. Industry-event observation and competitor analysis then helped us test market assumptions and define the product boundary.

Stakeholder interviews

Industry observation

Competitor analysis

Key Insights

Platform & Information Architecture

We defined role and module boundaries before designing screens, keeping shared business objects consistent across employer, agency, worker, and operations surfaces.

Platform architecture

Role-level information architecture

User & Business Flows

The flow set covers the cross-role operating model, funding alternatives, advance payment, payroll, attendance, settlement, and fund transfer.

Flow evidence

State Definitions

Worker, staffing-plan, client, and shift states define ownership and transition conditions across attendance, confirmation, settlement, and exceptions.

Prototype Gallery

Eight web prototypes show how platform architecture and role responsibilities became task-level interfaces.

Validation & Impact

Business and engineering reviews checked workflows, states, and permissions before launch. In the first month, the platform onboarded 5 hotels, 2 hospitals, 8 labor agencies, and more than 100 workers, with RMB 100K+ payroll volume. After three months, it reached 18 hotels, 6 hospitals, 22 agencies, more than 1,000 workers, and RMB 1M+ payroll volume. The company later received RMB 11M+ in angel investment; this is a company-level outcome rather than a direct design metric.

Reflection

A 0-to-1 platform can easily confuse business completeness with putting more features into the first release. This project reinforced a better sequence: define roles, states, and money-related critical paths first, then expand the product.