MCP HubMCP Hub
SKILL·0B6412

vertical-professional-services

avelikiy
Mis à jour 9 days ago
48
11
48
Voir sur GitHub
Métaai

À propos

Cette compétence fournit les connaissances essentielles du domaine pour concevoir des logiciels dédiés aux services professionnels, garantissant une modélisation précise d'entités telles que les déclarations de travail (SOW) et les contrats de forfait. Elle équipe les architectes et chefs de projet du vocabulaire spécifique, des règles de facturation et des insights concurrentiels nécessaires pour spécifier des produits tels que les outils de proposition ou de suivi du temps. Utilisez-la lors de la conception pour éviter des hypothèses naïves et répondre correctement aux exigences fondamentales du secteur.

Installation rapide

Claude Code

Recommandé
Principal
npx skills add avelikiy/great_cto -a claude-code
Commande PluginAlternatif
/plugin add https://github.com/avelikiy/great_cto
Git CloneAlternatif
git clone https://github.com/avelikiy/great_cto.git ~/.claude/skills/vertical-professional-services

Copiez et collez cette commande dans Claude Code pour installer cette compétence

Documentation

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.

Dépôt GitHub

avelikiy/great_cto
Chemin: skills/vertical-professional-services
0
agentic-codingclaude-code-pluginclaude-code-skillsclaude-code-subagentscode-reviewcto
FAQ

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.

Compétences associées

content-collections
Méta

Cette compétence propose une configuration éprouvée en production pour Content Collections, un outil axé sur TypeScript qui transforme des fichiers Markdown/MDX en collections de données typées de manière sûre avec une validation Zod. Utilisez-la lors de la création de blogs, de sites de documentation ou d'applications Vite + React riches en contenu pour garantir la sécurité de typage et la validation automatique du contenu. Elle couvre tout, de la configuration du plugin Vite et de la compilation MDX à l'optimisation des déploiements et la validation des schémas.

Voir la compétence
polymarket
Méta

Cette compétence permet aux développeurs de créer des applications avec la plateforme de marchés prédictifs Polymarket, incluant l'intégration d'API pour le trading et les données de marché. Elle fournit également une diffusion de données en temps réel via WebSocket pour surveiller les transactions en direct et l'activité du marché. Utilisez-la pour mettre en œuvre des stratégies de trading ou pour créer des outils traitant les mises à jour de marché en direct.

Voir la compétence
creating-opencode-plugins
Méta

Cette compétence aide les développeurs à créer des plugins OpenCode qui s'interconnectent avec plus de 25 types d'événements tels que les commandes, les fichiers et les opérations LSP. Elle fournit la structure du plugin, les spécifications de l'API événementielle et les modèles d'implémentation pour les modules JavaScript/TypeScript. Utilisez-la lorsque vous avez besoin d'intercepter, de surveiller ou d'étendre le cycle de vie de l'assistant IA OpenCode avec une logique personnalisée pilotée par les événements.

Voir la compétence
sglang
Méta

SGLang est un framework de service LLM haute performance spécialisé dans la génération rapide et structurée pour les workflows JSON, regex et agentiques grâce à son cache de préfixe RadixAttention. Il offre une inférence nettement plus rapide, particulièrement pour les tâches avec des préfixes répétés, ce qui le rend idéal pour les sorties complexes et structurées ainsi que les conversations multi-tours. Choisissez SGLang plutôt que des alternatives comme vLLM lorsque vous avez besoin d'un décodage contraint ou que vous construisez des applications avec un partage étendu de préfixes.

Voir la compétence