vertical-professional-services
О программе
Этот навык предоставляет ключевые знания в предметной области для разработки программного обеспечения профессиональных услуг, обеспечивая точное моделирование таких сущностей, как SOW и ретейнеры. Он снабжает архитекторов и проект-менеджеров специальной терминологией, правилами биллинга и конкурентными инсайтами, необходимыми для спецификации продуктов, таких как инструменты для создания предложений или учёта времени. Используйте его на этапе проектирования, чтобы избежать наивных допущений и корректно учитывать ключевые требования вертикали.
Быстрая установка
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 репозиторий
Часто задаваемые вопросы
Что такое Skill vertical-professional-services?
vertical-professional-services — это Claude Skill от avelikiy. Skills объединяют инструкции и ресурсы, которые Claude загружает по мере необходимости, чтобы выполнять задачи, связанные с vertical-professional-services, без дополнительных запросов.
Как установить vertical-professional-services?
Используйте команды установки на этой странице: добавьте vertical-professional-services в Claude Code как плагин или клонируйте репозиторий в каталог skills, затем перезапустите Claude, чтобы загрузить Skill.
К какой категории относится vertical-professional-services?
vertical-professional-services относится к категории Мета.
Можно ли использовать vertical-professional-services бесплатно?
Да. vertical-professional-services размещён на AIMCP и доступен для бесплатной установки.
Похожие навыки
Этот навык предоставляет проверенную в продакшене настройку для Content Collections — TypeScript-ориентированного инструмента, который преобразует файлы Markdown/MDX в типобезопасные коллекции данных с валидацией Zod. Используйте его при создании блогов, сайтов документации или контентных приложений на Vite + React для обеспечения типобезопасности и автоматической проверки содержимого. Он охватывает всё: от настройки плагина Vite и компиляции MDX до оптимизации развертывания и валидации схем.
Этот навык позволяет разработчикам создавать приложения на платформе прогнозных рынков Polymarket, включая интеграцию с API для торговли и получения рыночных данных. Он также обеспечивает потоковую передачу данных в реальном времени через WebSocket для отслеживания текущих сделок и рыночной активности. Используйте его для реализации торговых стратегий или создания инструментов, обрабатывающих обновления рынка в реальном времени.
Этот навык помогает разработчикам создавать плагины OpenCode, которые подключаются к более чем 25 типам событий, таким как команды, файлы и операции LSP. Он предоставляет структуру плагина, спецификации API событий и шаблоны реализации для модулей на JavaScript/TypeScript. Используйте его, когда вам нужно перехватывать, отслеживать или расширять жизненный цикл ассистента OpenCode AI с помощью пользовательской событийно-ориентированной логики.
SGLang — это высокопроизводительный фреймворк для обслуживания больших языковых моделей (LLM), специализирующийся на быстрой структурированной генерации JSON, regex и рабочих процессов агентов с использованием кэширования префиксов RadixAttention. Он обеспечивает значительно более высокую скорость вывода, особенно для задач с повторяющимися префиксами, что делает его идеальным для сложных структурированных результатов и многократных диалогов. Выбирайте SGLang вместо альтернатив, таких как vLLM, когда вам требуется ограниченное декодирование или вы создаете приложения с интенсивным совместным использованием префиксов.
