Operações de Faturamento Financeiro
Use este skill quando o usuário quiser entender dinheiro, preços, reembolsos, lógica de assentos de equipe ou se o produto realmente se comporta como o site e o texto de vendas sugerem.
Este skill é mais abrangente que customer-billing-ops. Aquele skill é para remediação de clientes. Este skill é para a verdade do operador: estado da receita, decisões de precificação, faturamento de equipes e comportamento de faturamento baseado em código.
Pilha de Skills
Puxe estes skills nativos do ECC para o fluxo de trabalho quando relevante:
customer-billing-opspara remediação e acompanhamento específicos do clienteresearch-opsquando preços de concorrentes ou evidências de mercado atuais forem importantesmarket-researchquando a resposta deve terminar com uma recomendação de preçogithub-opsquando a verdade do faturamento depender de código, backlog ou estado de release em repositórios irmãosverification-loopquando a resposta depender da comprovação do comportamento de checkout, gerenciamento de assentos ou direitos
Quando Usar
- o usuário pergunta sobre vendas Stripe, reembolsos, MRR ou atividade recente de clientes
- o usuário pergunta se o faturamento de equipe, faturamento por assento ou empilhamento de cotas é real no código
- o usuário deseja comparações de preços de concorrentes ou benchmarks de modelos de precificação
- a pergunta mistura fatos de receita com a verdade da implementação do produto
Salvaguardas
- distinguir dados ao vivo de snapshots salvos
- separar:
- fato de receita
- impacto no cliente
- verdade do produto baseada em código
- recomendação
- não diga "por assento" a menos que o caminho real de direitos o imponha
- não assuma que assinaturas duplicadas implicam valor duplicado
Fluxo de Trabalho
1. Comece pela evidência de faturamento mais recente
Prefira dados de faturamento ao vivo. Se os dados não forem ao vivo, declare o timestamp do snapshot explicitamente.
Normalize o panorama:
- vendas pagas
- assinaturas ativas
- checkouts falhos ou incompletos
- reembolsos
- disputas
- assinaturas duplicadas
2. Separe incidentes de clientes da verdade do produto
Se a pergunta for específica do cliente, classifique primeiro:
- checkout duplicado
- intenção real de equipe
- controles de autoatendimento quebrados
- valor do produto não atendido
- pagamento falho ou configuração incompleta
Em seguida, separe isso da questão mais ampla do produto:
- o faturamento de equipe realmente existe?
- os assentos são realmente contados?
- a quantidade no checkout altera os direitos?
- o site exagera o comportamento atual?
3. Inspecione o comportamento de faturamento baseado em código
Se a resposta depender da verdade da implementação, inspecione o caminho do código:
- checkout
- página de preços
- cálculo de direitos
- tratamento de assentos ou cotas
- lógica de uso de instalação vs. usuário
- suporte a portal de faturamento ou gerenciamento de autoatendimento
4. Termine com uma decisão e lacuna de produto
Relate:
- resumo de vendas
- diagnóstico do problema
- verdade do produto
- ação operacional recomendada
- lacuna de produto ou backlog
Formato de Saída
SNAPSHOT
- timestamp
- receita / assinaturas / anomalias
IMPACTO NO CLIENTE
- quem é afetado
- o que aconteceu
VERDADE DO PRODUTO
- o que o código realmente faz
- o que o site ou texto de vendas alega
DECISÃO
- reembolsar / preservar / converter / no-op
LACUNA DE PRODUTO
- item exato de acompanhamento para construir ou corrigir
Armadilhas
- não confunda tentativas falhas com receita líquida
- não infira faturamento de equipe apenas a partir da linguagem de marketing
- não compare preços de concorrentes de memória quando evidências atuais estiverem disponíveis
- não pule do diagnóstico diretamente para o reembolso sem classificar o problema
Verificação
- a resposta inclui uma declaração de dados ao vivo ou timestamp de snapshot
- alegações de verdade do produto são baseadas em código
- impacto no cliente e conclusões mais amplas de precificação/produto são separadas claramente