Lar

Skill

Produtividade e fluxo de trabalho

finance-billing-ops

affaan-m/ECC

Oferece fluxos de trabalho baseados em evidências para receitas, preços, reembolsos, faturamento por equipe e verificação da exatidão dos modelos de faturamento, destinados a análises instantâneas de vendas, comparações de preços, diagnóstico de cobranças duplicadas ou verificação da conformidade do faturamento com base em códigos.

...Expandir tudo

Tempo atualizado 12 de Outubro de 2026

# pricing # stripe # billing # revenue # subscriptions # entitlement # refunds # team billing

Operações de Faturamento Financeiro

Utilize esta habilidade quando o usuário quiser entender questões financeiras, preços, reembolsos, lógica de licenças por equipe ou se o produto realmente funciona da maneira que o site e o texto de vendas sugerem.

Este tema é mais abrangente do que as operações de faturamento de clientes. Aquela habilidade é voltada para a resolução de problemas dos clientes. Esta habilidade é voltada para a verdade operacional: situação da receita, decisões de preços, faturamento de equipes e comportamento de faturamento baseado no código.

Conjunto de competências

Incorpore essas habilidades nativas do ECC ao fluxo de trabalho quando for relevante:

operações de faturamento de clientes para resolução de problemas específicos do cliente e acompanhamento
operações de pesquisa quando os preços da concorrência ou evidências atuais do mercado forem relevantes
pesquisa-de-mercado quando a resposta deve resultar em uma recomendação de preços
github-ops quando a precisão do faturamento depende de código, backlog ou estado de lançamento em repositórios relacionados
verification-loop quando a resposta depende da comprovação do checkout, do gerenciamento de licenças ou do comportamento dos direitos de uso

Quando usar

o usuário solicita informações sobre vendas, reembolsos, MRR ou atividades recentes do cliente no Stripe
o usuário pergunta se o faturamento por equipe, por licença ou o acúmulo de cotas é efetivamente implementado no código
o usuário deseja comparações de preços com a concorrência ou referências de modelos de preços
a pergunta mistura fatos sobre receita com a realidade da implementação do produto

Pautas

distinguir dados em tempo real de instantâneos salvos
separar:
- dados de receita
- impacto no cliente
- verdade do produto baseada no código
- recomendação
não diga “por licença” a menos que a estrutura de direitos efetiva exija isso
não presuma que assinaturas duplicadas impliquem valor duplicado

Fluxo de trabalho

1. Comece com os dados de faturamento mais recentes

Dê preferência a dados de faturamento em tempo real. Se os dados não forem em tempo real, indique explicitamente o carimbo de data e hora do instantâneo.

Normalize o quadro:

vendas pagas
assinaturas ativas
compras com falha ou incompletas
reembolsos
contestações
assinaturas duplicadas

2. Separe os incidentes relacionados a clientes das informações sobre o produto

Se a questão for específica do cliente, classifique primeiro:

compra duplicada
intenção real da equipe
controles de autoatendimento com falha
valor do produto não atendido
pagamento com falha ou configuração incompleta

Em seguida, separe isso da questão mais ampla sobre o produto:

o faturamento por equipe realmente existe?
As licenças são realmente contabilizadas?
a quantidade no checkout altera o direito de uso?
O site exagera o comportamento atual?

3. Analise o comportamento de cobrança baseado no código

Se a resposta depender da realidade da implementação, verifique o fluxo do código:

finalização da compra
página de preços
cálculo de direitos
gestão de licenças ou cotas
lógica de instalação versus uso do usuário
portal de faturamento ou suporte à gestão autônoma

4. Conclua com uma decisão e a lacuna do produto

Relatório:

resumo de vendas
diagnóstico de problemas
realidade do produto
ação recomendada para a operadora
lacuna no produto ou no backlog

Formato de saída

RESUMO
- data e hora
- receita / assinaturas / anomalias

IMPACTO NO CLIENTE
- quem foi afetado
- o que aconteceu

INFORMAÇÕES SOBRE O PRODUTO
- o que o código realmente faz
- o que o site ou o texto de vendas afirma

DECISÃO
- reembolsar / manter / converter / não tomar nenhuma ação

LACUNA DO PRODUTO
- item exato a ser desenvolvido ou corrigido

Armadilhas

não confunda tentativas malsucedidas com receita líquida
não deduza o faturamento da equipe apenas com base na linguagem de marketing
não compare os preços dos concorrentes de memória quando houver evidências atuais disponíveis
não passe diretamente do diagnóstico para o reembolso sem classificar o problema

Verificação

a resposta inclui uma declaração com dados em tempo real ou um carimbo de data/hora de um instantâneo
as afirmações sobre as características do produto são respaldadas por código
o impacto no cliente e as conclusões mais amplas sobre preços/produtos estão claramente separados

Ver no GitHub

---
name: finance-billing-ops
description: Provides evidence-first revenue, pricing, refunds, team-billing, and billing-model truth workflows for sales snapshots, pricing comparisons, duplicate-charge diagnosis, or code-backed billing reality.
---

# Finance Billing Ops

Use this when the user wants to understand money, pricing, refunds, team-seat logic, or whether the product actually behaves the way the website and sales copy imply.

This is broader than `customer-billing-ops`. That skill is for customer remediation. This skill is for operator truth: revenue state, pricing decisions, team billing, and code-backed billing behavior.

## Skill Stack

Pull these ECC-native skills into the workflow when relevant:

- `customer-billing-ops` for customer-specific remediation and follow-up
- `research-ops` when competitor pricing or current market evidence matters
- `market-research` when the answer should end in a pricing recommendation
- `github-ops` when the billing truth depends on code, backlog, or release state in sibling repos
- `verification-loop` when the answer depends on proving checkout, seat handling, or entitlement behavior

## When to Use

- user asks for Stripe sales, refunds, MRR, or recent customer activity
- user asks whether team billing, per-seat billing, or quota stacking is real in code
- user wants competitor pricing comparisons or pricing-model benchmarks
- the question mixes revenue facts with product implementation truth

## Guardrails

- distinguish live data from saved snapshots
- separate:
  - revenue fact
  - customer impact
  - code-backed product truth
  - recommendation
- do not say "per seat" unless the actual entitlement path enforces it
- do not assume duplicate subscriptions imply duplicate value

## Workflow

### 1. Start from the freshest billing evidence

Prefer live billing data. If the data is not live, state the snapshot timestamp explicitly.

Normalize the picture:

- paid sales
- active subscriptions
- failed or incomplete checkouts
- refunds
- disputes
- duplicate subscriptions

### 2. Separate customer incidents from product truth

If the question is customer-specific, classify first:

- duplicate checkout
- real team intent
- broken self-serve controls
- unmet product value
- failed payment or incomplete setup

Then separate that from the broader product question:

- does team billing really exist?
- are seats actually counted?
- does checkout quantity change entitlement?
- does the site overstate current behavior?

### 3. Inspect code-backed billing behavior

If the answer depends on implementation truth, inspect the code path:

- checkout
- pricing page
- entitlement calculation
- seat or quota handling
- installation vs user usage logic
- billing portal or self-serve management support

### 4. End with a decision and product gap

Report:

- sales snapshot
- issue diagnosis
- product truth
- recommended operator action
- product or backlog gap

## Output Format

```text
SNAPSHOT
- timestamp
- revenue / subscriptions / anomalies

CUSTOMER IMPACT
- who is affected
- what happened

PRODUCT TRUTH
- what the code actually does
- what the website or sales copy claims

DECISION
- refund / preserve / convert / no-op

PRODUCT GAP
- exact follow-up item to build or fix
```

## Pitfalls

- do not conflate failed attempts with net revenue
- do not infer team billing from marketing language alone
- do not compare competitor pricing from memory when current evidence is available
- do not jump from diagnosis straight to refund without classifying the issue

## Verification

- the answer includes a live-data statement or snapshot timestamp
- product-truth claims are code-backed
- customer-impact and broader pricing/product conclusions are separated cleanly