关于
This skill provides essential domain knowledge for building professional-services software, ensuring accurate modeling of entities like SOWs and retainers. It equips architects and PMs with the specific vocabulary, billing rules, and competitive insights needed to spec products like proposal or time-tracking tools. Use it during design to avoid naive assumptions and correctly address the vertical's core requirements.
快速安装
Claude Code
推荐npx skills add avelikiy/great_cto -a claude-code/plugin add https://github.com/avelikiy/great_ctogit clone https://github.com/avelikiy/great_cto.git ~/.claude/skills/vertical-professional-services在 Claude Code 中复制并粘贴此命令以安装该技能
技能文档
Vertical: professional services — bill time, defend margin, sell the scope
Agencies, consulting firms, and creative studios sell hours and deliverables, not units. Their economics are unintuitive: revenue can rise while margin collapses, and the document that wins the work (the proposal/SOW) is also where margin leaks. Incumbents (Scoro, Productive, Accelo, Ruddr, BigTime — collectively "PSA", professional-services automation) model this correctly; a naive build does not. Spec against the real domain.
1. Domain vocabulary
- SOW (statement of work) — the binding scope: deliverables, timeline, price, terms. It IS the contract and the upsell surface.
- Engagement types: project (fixed scope/price), retainer (recurring fee for a capacity/hours bucket), T&M (time & materials — bill actuals).
- Utilization rate — billable hours ÷ available hours. The first lever of margin.
- Realization rate — billed amount ÷ standard value of hours worked (i.e. how much of what you could bill you actually invoiced and collected). The second lever.
- Billable vs non-billable — every time entry carries this flag; non-billable (admin, sales, rework) is pure cost.
- WIP (work in progress) — unbilled-but-delivered work; revenue earned, not yet invoiced. Agencies carry it for weeks.
- Blended rate — single effective $/hour across a mixed-seniority team on an engagement (vs per-person rate cards).
- Change order — a formal amendment when scope grows; the antidote to scope creep.
- Milestone billing — invoice tied to deliverable acceptance, not the calendar.
- Scope creep — uncompensated work beyond the SOW; the silent margin killer.
- Gross margin per project — (revenue − cost of delivered hours) ÷ revenue, per engagement — not company-wide, not revenue.
- e-signature — legally binding accept on the proposal (ESIGN/UETA, see §6).
- Net-30 terms — payment due 30 days after invoice; drives cash flow and reminders.
2. Non-obvious domain rules
- The proposal/SOW is the contract AND the upsell. It's not a marketing PDF — it's where price, scope, and acceptance live. Optional line items and tiers turn a quote into expansion revenue. Treat it as a revenue surface, not a document export.
- Margin is utilization × realization, not revenue. A firm can grow billings and lose money if people are busy on non-billable work or hours never get invoiced. Profitability must compute margin per engagement, never top-line revenue.
- Retainers need burn-down tracking. A retainer is a bucket of hours/fees that depletes through the month. Without burn-down you over-deliver (margin loss) or under-deliver (churn). Show consumed vs remaining, continuously.
- Agencies live and die on scope creep + change orders. The default human behavior is to "just do it" rather than raise a change order — which silently converts billable work into non-billable. The product must make raising a change order frictionless.
- Time tracking is hated but is the source of truth for billing. No time entry → no defensible invoice → realization drops. The constraint is adoption, not features.
3. What a naive build gets wrong
- Proposal as a static PDF instead of accept-to-pay — losing the e-sign + deposit/first-invoice moment where the deal actually closes and cash starts.
- No change-order flow — scope creep eats margin invisibly because over-delivery is never captured as a billable amendment.
- Time entry so tedious nobody uses it — a 12-field modal per entry kills adoption; with no entries, billing and profitability are both fiction. Timers + one-tap + defaults beat a perfect schema.
- Profitability that shows revenue, not margin — a dashboard of billings is vanity; the firm needs margin per project/retainer with cost-of-hours subtracted.
- Ignoring retainer burn-down — treating a retainer like a flat subscription instead of a depleting bucket misses the entire reason retainers are risky.
4. Must-model entities
Spec these explicitly; they recur across all four products. Build them [[migration-ready-schema]] (stable external IDs, soft-delete, audit timestamps) because agencies switch from incumbents mid-engagement and import open work.
- SOW / Proposal — header (client, engagement type, terms, net-N) + line items (description, qty, rate, optional/tiered flags) + e-signature state (sent → viewed → signed) + accept-to-pay link (deposit or first invoice on acceptance). Status machine: draft → sent → signed → active → closed.
- Retainer — period, committed hours/fee, burn-down (consumed vs remaining), rollover policy, renewal date.
- TimeEntry — who, project/task, duration, billable flag, rate (snapshot at entry time, not a live lookup), billed/unbilled (WIP) status.
- Project — budget (hours and/or fee), engagement type, rate card, computed margin (revenue − cost-of-delivered-hours), milestones.
- ChangeOrder — links to a Project/SOW, delta scope + delta price, its own e-sign/acceptance, and a reason — so scope growth becomes captured revenue.
5. Per-product notes (wedge vs incumbent + the one thing to nail)
- proposals (marketplace-lite) — the wedge. Revenue-adjacent and low switching cost: a firm can adopt it for the next proposal without migrating anything, and it touches money immediately. Incumbents bury proposals inside a heavy PSA suite. Must nail: accept-to-pay — e-sign that flows straight into a deposit/first invoice. See [[vertical-onboarding]]: first activation = first signed, paid proposal.
- client-portal (crud) — wedge: one clean client-facing surface for deliverables, approvals, status, and billing, vs incumbents' internal-ops focus. Must nail: approvals as billing triggers — an approved deliverable should be invoiceable (milestone billing), not just a checkbox.
- time-invoicing (crud) — wedge: timers → invoices → reminders with no spreadsheet in between; incumbents make time entry a chore. Must nail: frictionless capture + rate snapshot — adoption is the product; a wrong/stale rate corrupts every downstream invoice and the realization number.
- profitability (dashboard) — wedge: real-time margin, not month-end revenue reporting. Must nail: margin = utilization × realization per engagement, with cost-of-hours subtracted and retainer burn-down surfaced — not a billings chart.
6. Compliance (light)
Keep this proportionate — defer anything money-movement-shaped to the subscription-billing-engineer.
- e-signature validity — ESIGN Act + UETA (US): capture intent-to-sign, consent to electronic records, an audit trail (timestamp, IP, signer identity), and a tamper- evident copy. For EU clients, eIDAS levels apply. This is what makes accept-to-pay legally binding.
- Invoice / tax basics — sequential invoice numbers, required fields, sales-tax/VAT where applicable. Defer the engine (tax calc, payment rails, dunning) to the subscription-billing-engineer; the architecture doc only needs the contract with it.
- 1099 for contractors — agencies pay sub-contractors/freelancers; if the product touches contractor payouts, track payee tax info for 1099-NEC reporting (US). Note it; don't build a payroll system into a proposals tool.
Output
When applied, contribute a Domain model note to the architecture doc capturing: the engagement types in scope (project/retainer/T&M), the must-model entities above that this product owns, the margin definition (utilization × realization, per engagement) if profitability is in scope, and the e-sign/accept-to-pay contract if proposals is in scope.
GitHub 仓库
Frequently asked questions
What is the vertical-professional-services skill?
vertical-professional-services is a Claude Skill by avelikiy. Skills package instructions and resources that Claude loads on demand, so Claude can perform vertical-professional-services-related tasks without extra prompting.
How do I install vertical-professional-services?
Use the install commands on this page: add vertical-professional-services to Claude Code as a plugin, or clone its repository into your skills directory, then restart Claude so it picks up the skill.
What category does vertical-professional-services belong to?
vertical-professional-services is in the Meta category, tagged ai.
Is vertical-professional-services free to use?
Yes. vertical-professional-services is listed on AIMCP and free to install. It runs inside Claude, so no separate service account is required to use the skill itself.
相关推荐技能
Content Collections 是一个 TypeScript 优先的构建工具,可将本地 Markdown/MDX 文件转换为类型安全的数据集合。它专为构建博客、文档站和内容密集型 Vite+React 应用而设计,提供基于 Zod 的自动模式验证。该工具涵盖从 Vite 插件配置、MDX 编译到生产环境部署的完整工作流。
这个Claude Skill为开发者提供完整的Polymarket预测市场开发支持,涵盖API调用、交易执行和市场数据分析。关键特性包括实时WebSocket数据流,可监控实时交易、订单和市场动态。开发者可用它构建预测市场应用、实施交易策略并集成实时市场预测功能。
该Skill帮助开发者创建OpenCode插件,用于接入命令、文件、LSP等25+种事件。它提供了插件结构、事件API规范和JavaScript/TypeScript实现模式,适合需要拦截操作、扩展功能或自定义事件处理的场景。开发者可通过它快速构建响应式模块来增强OpenCode AI助手的能力。
SGLang是一个专为LLM设计的高性能推理框架,特别适用于需要结构化输出的场景。它通过RadixAttention前缀缓存技术,在处理JSON、正则表达式、工具调用等具有重复前缀的复杂工作流时,能实现极速生成。如果你正在构建智能体或多轮对话系统,并追求远超vLLM的推理性能,SGLang是理想选择。
