Resumo

  • A transferência de aplicativo mantém direitos dos jogadores, avaliações e histórico das listas de desejos. Os relatórios mensais de pagamentos do antigo parceiro não são transferidos automaticamente.
  • Compartilhar a gestão não altera quem recebe os pagamentos. Acesso financeiro é opcional e também depende da permissão do usuário que consultará os dados.
  • Data de vigência, aprovação da Valve, chaves de servidor e restrições promocionais existentes são partes distintas da transição.

Marketing já pode comemorar. O financeiro ainda pede um arquivo

Imagine o primeiro dia de uma publicadora à frente de um jogo comprado de outra empresa. O pessoal de marketing abre a Steam e encontra as avaliações, os seguidores e o histórico completo das listas de desejos. Há uma plateia pronta para receber a próxima campanha. Na área financeira, alguém tenta conferir os pagamentos antigos. Os relatórios mensais não vieram.

No mesmo escritório, a aquisição parece concluída e incompleta. Depende de quem olha para a tela.

A cena é inventada, mas o descompasso está previsto nas regras. A Steam preserva a relação do jogo com os jogadores e deixa os relatórios mensais de pagamentos vinculados ao parceiro anterior. O novo operador recebe uma loja que sabe quem a desejou. Para saber quanto a antiga empresa efetivamente tinha a receber, precisa de outros documentos.

Pense no trabalho que isso deixa para quem assumiu a conciliação. A curva de vendas pode estar bonita; a previsão de caixa, aprovada. Ainda assim, faltam os arquivos que permitem ligar receita, reembolsos, contestações de pagamento, impostos e o valor apurado para pagamento. A pessoa encarregada de explicar essa diferença não resolve o problema trocando a imagem principal da loja. Precisa que alguém do outro lado entregue os registros e explique as linhas.

A transferência cria uma situação comercial curiosa: a memória dos jogadores acompanha o ativo com mais facilidade do que a memória de quem recebia o dinheiro. O comprador deve organizar essa segunda mudança enquanto o vendedor ainda tem motivo para atender ao telefone.

Quem se lembra de uma dedução depois da despedida?

Na situação imaginada, a pergunta do financeiro pode ser simples: por que o valor daquele mês ficou abaixo da receita mostrada na tela? A resposta talvez esteja distribuída entre o relatório mensal e a explicação de uma pessoa na antiga empresa. O arquivo e a disponibilidade dessa pessoa são duas entregas diferentes.

Por padrão, o novo parceiro vê as informações financeiras a partir da transferência. O anterior pode conceder acesso ao histórico completo de vendas pelo compartilhamento do aplicativo. Isso abre uma janela para o passado; não transfere os relatórios mensais que pertenciam ao antigo recebedor.

Vale resolver a entrega antes da despedida. Depois, a mesma solicitação compete com o próximo lançamento, outra aquisição e o fechamento do mês de quem já vendeu. O incentivo do comprador continua inteiro. O do vendedor mudou de assunto.

A relação com o jogador fica ligada ao jogo

Essa continuidade tem valor. A transferência não interrompe nem altera os direitos dos clientes sobre o jogo adquirido. Avaliações, fóruns e outros conteúdos da comunidade permanecem. Seguidores e listas de desejos também ficam vinculados ao jogo, e todo o histórico destas listas fica acessível ao novo parceiro.

Depois da conclusão, o novo responsável pode mudar a página, o campo de publicadora, as imagens, as versões do jogo e o preço. Até que faça alterações, a página mantém seu conteúdo. Não é preciso reconstruir a reputação pública em uma ficha nova ou pedir ao jogador que compre outra vez por causa da troca de empresa.

Há, porém, uma vitrine que recebe tratamento diferente. Ao iniciar a transferência, o aplicativo é retirado das páginas de desenvolvedora ou publicadora em que estava listado. Depois da conclusão, pode ser colocado na nova página. A ficha do jogo e a prateleira de uma empresa não são a mesma superfície.

Por isso, a página principal funcionando é uma boa notícia para os clientes, mas uma evidência limitada para quem conduz a aquisição. O público pode não perceber nada enquanto as empresas ainda acertam documentos, acessos e caminhos de divulgação.

A receita pode estar certa e ainda não responder à pergunta

A Steam oferece uma visão quase em tempo real de vendas e ativações, com receita, unidades e outros indicadores. A receita exibida ali vem antes das deduções por reembolsos, contestações de pagamento e impostos. O relatório mensal inclui essas deduções detalhadas, reflete o valor a pagar e pode ser baixado como CSV.

Voltemos à pessoa que precisa fechar a conciliação. Mostrar-lhe uma curva de receita não entrega os termos que faltam à conta. Ela precisa ligar períodos e valores, conferir deduções e saber qual documento explica qual número. É trabalho de reconstrução quando deveria ser apenas uma passagem organizada de arquivos.

Há ainda uma porta dentro da porta. Ao compartilhar a gestão do aplicativo, o parceiro pode permitir separadamente a visualização financeira. No destinatário, o usuário que consultará os dados precisa de View Financials. Duas empresas podem ter apertado as mãos enquanto o empregado encarregado de conferir o negócio continua diante de uma tela fechada.

Combinar os períodos, os arquivos e a pessoa que receberá o acesso evita esse desencontro. A autorização deve chegar a quem faz o trabalho. Os relatórios devem chegar a quem precisa explicar a diferença entre vendas e pagamento. A boa vontade dos diretores não baixa um CSV.

Os documentos públicos não quantificam atrasos ou mudanças no preço de aquisições causados por esses desencontros; registros combinados de transferência, suporte e pagamentos permitiriam medi-los. O problema documentado já basta para uma decisão: os comprovantes antigos entram na lista de entregas antes de a página nova virar motivo de comemoração.

Editar a loja não transfere a conta a receber

O compartilhamento de gestão permite que outros parceiros trabalhem no aplicativo, enviando versões e editando dados da loja. As regras de pagamento permanecem iguais. Somente o parceiro que tem direito aos pagamentos pode estabelecer preços e descontos; o usuário que faz isso precisa das permissões correspondentes.

Uma equipe nova pode, portanto, preparar imagens e descrições enquanto a empresa antiga ainda é a recebedora. Isso serve à transição. Também pode criar confusão se marketing interpretar acesso ao editor da página como autorização para executar qualquer campanha de preço.

Para mudar a empresa que recebe pagamentos é necessário transferir a aplicação. O parceiro atual informa destinatário, data de vigência e motivo. O destinatário aceita, o remetente confirma novamente e a Valve analisa. Os usuários dos dois lados precisam de Actual Authority, e a conta do parceiro destinatário deve estar completamente cadastrada e verificada.

O compartilhamento comum é aprovado entre os parceiros, sem aprovação da Valve. A transferência acrescenta essa análise da plataforma. Não é a mesma tarefa com um botão de nome diferente: muda quem a plataforma reconhece como parte recebedora do negócio.

A vigência não deposita dinheiro naquela manhã

Por padrão, o sistema propõe vigência sete dias depois do início da transferência. A data define quando os pagamentos passam a corresponder ao novo parceiro. A gestão muda nesse dia ou, se a aprovação vier depois, imediatamente após a aprovação.

A Valve informa um prazo usual de dois a sete dias úteis depois de ambas as partes aprovarem completamente o pedido. Esse intervalo não inclui como garantia todo o tempo que comprador e vendedor levam para fazer suas confirmações.

Também não transforma a data de vigência em data de crédito bancário imediato. A documentação de pagamentos usa o exemplo de vendas de fevereiro pagas no final de março. A competência das vendas atribuídas ao novo parceiro e o ciclo efetivo de pagamento precisam ocupar linhas diferentes na previsão de caixa.

Uma promessa vaga de concluir tudo no fim do mês pode significar a assinatura para uma pessoa, a aprovação para outra e uma entrada de dinheiro para uma terceira. O calendário da transferência fica mais útil quando cada uma dessas coisas tem nome.

A nova publicadora herda limites que já estavam rodando

Se o jogo integra um pacote promocional existente, a administração desse pacote não acompanha automaticamente a transferência. O parceiro anterior pode retirar o jogo quando necessário ou converter o pacote em colaborativo. A Steam também indica o suporte como caminho para ajudar na retirada depois da transferência.

Os intervalos entre descontos igualmente permanecem. A transferência não os reinicia nem encurta. A espera normal de trinta dias entre descontos tem exceções para as quatro promoções sazonais da Steam, mas os trinta dias ligados a lançamento ou aumento de preço continuam valendo nessas promoções. Uma festa de boas-vindas planejada pelo comprador ainda precisa caber no calendário do jogo.

As chaves de API da publicadora também não são transferidas. Se o servidor do jogo as utiliza para microtransações ou verificações de direitos, o novo parceiro precisa criar suas próprias chaves. A sequência oficial mantém o compartilhamento necessário durante a transição, troca a configuração do servidor, verifica o funcionamento e depois encerra o acesso compartilhado do antigo parceiro. Não é preciso conceder acesso financeiro para sustentar essa continuidade técnica.

Para o jogador, um dia comum é um bom resultado. Para quem comprou o jogo, o trabalho só fica completo quando a operação continua e os números fazem sentido. A Steam mantém as opiniões de quem jogou, inclusive as que a nova publicadora preferia esquecer. Já a explicação de quem recebeu o dinheiro precisa ser combinada. Melhor pedi-la enquanto a despedida ainda não terminou.

Documentos originais

Transferência de aplicações na Steam; gestão compartilhada e acesso financeiro; relatórios e pagamentos; permissões e intervalos de desconto.