Sistema interno de solicitações de compra: evite gargalos

Por que as solicitações de compra ficam paradas

A maioria dos atrasos em compras começa antes de alguém aprovar ou rejeitar uma solicitação. Um funcionário pede um laptop por e-mail, envia um preço no chat e depois adiciona uma linha em uma planilha para o financeiro. Cada lugar guarda uma parte da solicitação. Então, o comprador precisa reunir fornecedor, custo, motivo comercial, responsável pelo orçamento e prazo.

Isso gera trabalho duplicado. Um gestor pede informações que o funcionário já enviou ao financeiro. O financeiro verifica o orçamento, mas não consegue saber se o chefe do departamento aprovou a necessidade. O funcionário não sabe em que ponto está a solicitação nem quem precisa agir em seguida.

Informações ausentes causam atrasos

Um fluxo de aprovação de compras fica mais lento quando a solicitação não contém as informações de que cada pessoa precisa. As lacunas mais comuns incluem:

• Falta de descrição do item, quantidade ou orçamento do fornecedor
• Falta de departamento, centro de custo ou valor do orçamento
• Falta de motivo comercial ou data de entrega desejada
• Falta de um aprovador ou responsável por compras definido
• Falta de registro de comentários, alterações ou decisões anteriores

Uma única omissão pode fazer a solicitação voltar ao início. Um líder de equipe pode aprovar a renovação de um software de US$ 1.200, e então o financeiro descobrir que ninguém identificou o orçamento. Em vez de fazer o pedido, a equipe passa dias tentando encontrar a pessoa responsável pelo gasto.

Um registro e responsabilidades claras

Um sistema interno de solicitações de compra mantém a solicitação completa reunida desde o envio até o encaminhamento para o pedido de compra. O solicitante informa a necessidade uma única vez. Gestores, profissionais do financeiro e compradores veem os mesmos detalhes, adicionam comentários ao mesmo registro e deixam um histórico de decisões visível.

Rótulos de status claros reduzem acompanhamentos desnecessários. Uma solicitação pode mostrar se precisa de análise de orçamento, aprovação do gestor, ação do comprador ou informações do fornecedor. Cada etapa precisa de uma pessoa ou função definida, além de uma regra de substituição para ausências.

Um aplicativo de compras sem programação torna isso possível sem deixar as equipes de operações responsáveis por gerenciar formulários e planilhas. O AppMaster pode oferecer formulários de solicitação, campos de orçamento, lógica de aprovação e uma fila de compradores em um único aplicativo. Toda solicitação deve ter um único local, um responsável atual e informações suficientes para avançar até o pedido.

Decida o que cada solicitação deve incluir

Um formulário de solicitação deve dar aos gestores e compradores informações suficientes para tomar uma decisão rápida. Se os funcionários precisam explicar fatos básicos em mensagens posteriores, o formulário é incompleto. Se ele pede detalhes financeiros que eles não podem saber, as pessoas vão chutar ou desistir.

Toda solicitação precisa de nome do item, quantidade, fornecedor, custo unitário estimado, custo total e motivo comercial. Acrescente departamento, centro de custo, solicitante e data necessária quando esses dados afetarem o orçamento ou a entrega. Depois que o funcionário entrar no sistema, o aplicativo pode preencher automaticamente o nome e o departamento.

Um motivo curto funciona melhor do que uma caixa de texto grande e vazia. Por exemplo: «Cinco licenças extras de atendimento ao cliente para o novo turno da noite». Isso dá ao aprovador um motivo prático, uma quantidade e uma ligação com o trabalho atual.

Use dois tipos de solicitação

Compras de catálogo e compras avulsas precisam de formulários diferentes. Um item de catálogo já tem descrição, fornecedor, preço aprovados e, às vezes, uma referência contratual. O funcionário pode selecioná-lo, informar a quantidade e explicar a necessidade. Isso mantém as solicitações comuns consistentes.

Uma compra avulsa precisa de mais contexto, porque o setor de compras deve avaliá-la antes de fazer o pedido. Peça a descrição do item ou serviço, o fornecedor preferido e o contato, se conhecidos, o orçamento ou custo estimado, a quantidade e a frequência de cobrança, o motivo comercial e a data de entrega desejada.

Não obrigue os funcionários a encontrar um fornecedor antes de solicitar algo. Eles podem saber que precisam de uma mesa com altura ajustável sem saber qual fornecedor atende às regras da empresa. O setor de compras pode concluir essa parte depois.

Faça com que os campos obrigatórios tenham uma razão

Exija um campo apenas quando alguém precisar dele para aprovar, orçar ou comprar o item. Item, quantidade, custo estimado, centro de custo e motivo normalmente fazem parte desse grupo. Anexos só devem ser obrigatórios acima de um limite de gasto ou em categorias como assinaturas de software.

Campos condicionais deixam o formulário mais fácil de usar. Uma solicitação de software pode perguntar o número de usuários, a data de renovação e se o sistema tratará dados de clientes. Um item físico pode pedir um endereço de entrega. Cada fluxo de aprovação de compras recebe as informações necessárias sem obrigar todos os funcionários a preencher um formulário longo.

Antes do lançamento, envie três solicitações de teste: um item de catálogo, uma compra de novo fornecedor e um serviço recorrente. Se um aprovador ainda fizer uma pergunta óbvia, acrescente um campo ou torne um campo existente mais claro.

Crie um catálogo que acelere as solicitações

Um catálogo elimina trabalho repetitivo. Em vez de pedir a cada funcionário que descreva um laptop, uma licença de software ou uma cadeira de escritório do zero, ofereça uma lista curta de opções aprovadas.

Cada item do catálogo deve incluir uma descrição simples, o preço unitário habitual e o fornecedor preferido. Acrescente detalhes que evitem mensagens posteriores, como código do item, prazo contratual, tamanhos disponíveis ou a necessidade de confirmação do gestor.

Uma entrada chamada «Laptop padrão», por exemplo, pode informar o modelo, o fornecedor aprovado, o preço de US$ 1.200 e a garantia de três anos. O solicitante escolhe uma quantidade e explica quem usará o equipamento. O setor de compras recebe as mesmas informações úteis todas as vezes.

Mantenha as opções simples

Não transforme o catálogo em uma cópia de cada site de fornecedor. Comece com os itens que os funcionários pedem com frequência e acrescente entradas quando a mesma solicitação livre aparecer repetidamente. Um catálogo extenso e mal organizado cria outro atraso.

Agrupe os itens em categorias conhecidas, como software, equipamentos, materiais de escritório e serviços profissionais. Use busca e nomes curtos para que as pessoas encontrem um item antes de começar a digitar uma descrição.

Uma entrada de catálogo geralmente precisa do nome do item, descrição, preço unitário ou faixa esperada, fornecedor preferido, unidade de cobrança e eventuais restrições. Por exemplo, uma assinatura pode indicar «por usuário, por mês» e informar que um gestor deve aprová-la.

Deixe espaço para exceções

Às vezes, os funcionários precisarão de algo que não está listado. Mantenha uma opção de formulário livre, mas peça informações suficientes para tornar possível o próximo passo: necessidade, custo estimado, fornecedor, se conhecido, e motivo comercial.

Trate as solicitações livres como uma fila de análise, não como uma falha do catálogo. O setor de compras pode comparar orçamentos, aprovar um fornecedor ou decidir adicionar o item ao catálogo para solicitações futuras.

Em um aplicativo de compras sem programação criado com o AppMaster, a seleção de um item de catálogo pode preencher o preço, o fornecedor e os campos da solicitação. Isso fornece dados mais limpos ao processo de aprovação de orçamento e reduz o trabalho de correção antes do encaminhamento para o pedido de compra.

Adicione verificações de orçamento antes da aprovação

Uma solicitação deve mostrar seu contexto financeiro antes que alguém comece uma tarefa de aprovação. Peça ao solicitante que selecione um departamento e um centro de custo e registre o valor e a moeda. O sistema pode usar esses campos para encontrar o orçamento relevante.

Mantenha a verificação simples para quem solicita. A pessoa deve ver o total da solicitação, o orçamento disponível e o valor que restará após a aprovação. Uma mensagem como «Esta solicitação ultrapassa o orçamento restante em US$ 420» evita que o gestor descubra o problema depois, em uma sequência de e-mails.

O financeiro deve ser responsável pelos valores do orçamento. A equipe pode atualizar o valor aprovado para cada departamento ou centro de custo no início de um período e revisá-lo quando os planos mudarem. O sistema interno de solicitações de compra também deve acompanhar solicitações aprovadas que ainda não se transformaram em faturas. Caso contrário, uma equipe pode parecer ter dinheiro disponível depois de já ter comprometido esses recursos.

Verifique o total completo da solicitação

Calcule o que o setor de compras realmente pagará. Inclua quantidades, preços unitários, impostos, frete, taxas de configuração e cobranças recorrentes quando aplicável. Uma assinatura de software de US$ 900 com uma taxa de implementação de US$ 150 corresponde a uma solicitação de US$ 1.050.

Execute o processo de aprovação de orçamento quando o solicitante enviar o formulário, antes de o sistema encaminhá-lo a um aprovador. Isso evita tempo perdido em análises e permite que o solicitante corrija o centro de custo, reduza o pedido ou explique uma exceção.

Em um aplicativo de compras sem programação, isso pode ser uma regra visual: ler o centro de custo selecionado, comparar o total da solicitação com o orçamento restante e salvar o resultado na solicitação. O AppMaster pode modelar os dados da solicitação, criar a lógica no Business Process Editor e mostrar o resultado em um formulário interno.

Defina como as solicitações acima do orçamento avançam

Não deixe uma solicitação acima do orçamento em um status indefinido. Dê a ela um caminho determinado, de acordo com a política de gastos. Você pode devolvê-la ao solicitante mostrando a diferença, enviá-la ao responsável pelo orçamento para uma exceção, encaminhar uma necessidade urgente ao financeiro ou mantê-la até o próximo período orçamentário, com data e motivo.

Registre o resultado do orçamento e qualquer decisão sobre a exceção. Quando o setor de compras iniciar o pedido, a equipe poderá ver se o gasto cabe no orçamento original e quem aprovou qualquer valor adicional. O financeiro também poderá explicar por que um centro de custo ultrapassou o plano.

Defina rotas de aprovação que as pessoas consigam seguir

Um sistema interno de solicitações de compra precisa de regras de encaminhamento antes que alguém envie uma solicitação. Envie cada solicitação às pessoas capazes de avaliar o gasto, em vez de encaminhá-la a uma caixa de entrada genérica que alguém verifica ocasionalmente.

Baseie a rota nas informações já registradas no formulário. Departamento, centro de custo, categoria de compra e valor total normalmente fornecem contexto suficiente. Uma solicitação de US$ 40 para materiais de escritório pode precisar apenas do gestor da equipe. Um novo contrato de software pode exigir a análise do responsável pelo orçamento, de TI, da segurança e de compras.

Mantenha as rotas curtas quando o risco for baixo. Adicionar aprovadores «por garantia» transforma um fluxo simples de aprovação de compras em uma sequência de atrasos. Cada aprovador deve ter um motivo claro para aprovar, rejeitar ou pedir mais informações.

Use regras previsíveis

Os funcionários devem saber para onde a solicitação irá antes de enviá-la. Regras previsíveis também reduzem discussões quando uma solicitação fica parada.

Por exemplo, uma empresa poderia usar regras como estas:

• Solicitações abaixo de US$ 500 vão para o gestor do departamento.
• Solicitações de US$ 500 a US$ 5.000 vão para o gestor e o responsável pelo centro de custo.
• Solicitações de software e serviços em nuvem também vão para TI ou segurança.
• Solicitações acima de US$ 5.000 vão para compras após a aprovação do orçamento.
• Compras de capital vão para o responsável pelo financeiro, independentemente do valor.

As regras não precisam ser iguais em todos os departamentos. Vendas pode exigir aprovação para ferramentas voltadas a clientes, enquanto operações pode precisar de uma verificação adicional de equipamentos. Use a mesma lógica básica em toda a empresa para que a equipe não precise reaprender o processo a cada solicitação.

Planeje as ausências e mantenha o registro completo

Todo aprovador precisa de um substituto. Se um gestor estiver de licença, o sistema deve enviar novas solicitações a uma pessoa substituta definida ou permitir que um administrador reatribua tarefas pendentes. Os solicitantes não devem precisar procurar alguém por e-mail ou chat.

Defina uma meta de resposta. Por exemplo, notifique o aprovador depois de dois dias úteis e envie a solicitação a um substituto depois de cinco. A escalada deve fazer a solicitação avançar, mantendo a rota original e o histórico de decisões.

Mantenha todas as decisões no registro da solicitação. Mostre quem aprovou ou rejeitou, quando agiu e quais comentários deixou. Uma rejeição como «Use a licença existente da equipe até a renovação» dá ao solicitante um próximo passo prático e fornece contexto ao setor de compras.

O AppMaster permite que as equipes modelem campos de solicitação, criem a lógica de aprovação em um processo comercial visual e mostrem aos solicitantes o status atual. A responsabilidade permanece visível, em vez de desaparecer em sequências de e-mails.

Crie o fluxo de solicitação passo a passo

Um fluxo claro evita que compras simples desapareçam em e-mails. Cada status deve descrever o estado atual, e cada pessoa deve saber quando precisa agir.

Comece com um pequeno conjunto de status: Rascunho, Enviada, Aprovada, Rejeitada, Pedida e Recebida. Evite rótulos com significados quase iguais, como «em análise» e «aguardando aprovação». As pessoas os usarão de forma inconsistente, prejudicando os relatórios.

A solicitação começa como rascunho. O solicitante pode salvá-la, alterar o item ou a quantidade ou excluí-la. Nessa etapa, o sistema não deve enviar notificações nem reservar orçamento.

Quando o solicitante envia o formulário, o status muda para Enviada. Bloqueie o preço, os dados do fornecedor e o valor solicitado, a menos que alguém devolva a solicitação para alterações. O aprovador pode aprovar, rejeitar ou devolvê-la com um comentário curto.

Depois da aprovação, encaminhe a solicitação ao setor de compras. A equipe só deve marcar o status como Pedida depois de criar ou fazer o pedido de compra. A autorização para gastar não prova que alguém comprou o item.

Quando os produtos chegam, o acesso ao serviço começa ou uma assinatura é confirmada, a pessoa responsável pelo recebimento marca a solicitação como Recebida. Isso fornece ao financeiro e aos solicitantes um registro confiável do que chegou.

Dê ações claras a cada função

Um sistema interno simples de solicitações de compra funciona melhor quando cada mudança de status tem um responsável. Não permita que todos os usuários editem todas as solicitações enviadas.

• Solicitantes criam rascunhos, enviam solicitações e corrigem solicitações devolvidas.
• Gestores e responsáveis pelo orçamento aprovam, rejeitam ou devolvem solicitações com um motivo.
• Profissionais de compras registram informações do fornecedor, detalhes do pedido e o status Pedida.
• Responsáveis pelo recebimento confirmam a entrega e marcam as solicitações como Recebidas.
• Profissionais do financeiro veem o histórico completo e corrigem campos limitados, como uma referência contábil.

Um administrador deve cuidar de exceções, como a saída de um aprovador da empresa ou uma solicitação duplicada. Mantenha um registro de auditoria de toda mudança de status, incluindo quem a fez, quando e qualquer comentário.

Notifique as pessoas quando elas precisarem agir

Envie uma notificação quando uma solicitação enviada chegar a um aprovador. Inclua o título da solicitação, o valor, o departamento e a decisão necessária. Uma mensagem vaga como «Você tem uma nova tarefa» atrasa a ação, pois a pessoa precisa procurar o contexto.

Notifique o solicitante quando alguém aprovar, rejeitar ou devolver a solicitação. Exija um comentário para uma rejeição ou devolução. «Orçamento indisponível neste trimestre» orienta o solicitante. «Não» não orienta.

O setor de compras deve receber uma notificação depois da aprovação final. O solicitante deve receber atualizações quando o setor de compras marcar a solicitação como Pedida e Recebida. Se ninguém agir após um período definido, lembre o responsável atual e copie o aprovador substituto.

Com o AppMaster, um aplicativo de compras sem programação pode modelar status no Data Designer e exigir mudanças permitidas no Business Process Editor. Cada encaminhamento permanece no registro, em vez de depender da memória de alguém.

Exemplo: uma solicitação de assinatura de software

Maya, uma gestora de marketing, precisa de 15 assinaturas de uma ferramenta de planejamento de redes sociais. Ela abre o sistema interno de solicitações de compra e seleciona a ferramenta no catálogo de software, em vez de criar uma solicitação livre.

A entrada do catálogo contém o fornecedor, o tipo de plano, o preço por usuário, o ciclo de cobrança e a equipe responsável pelo contrato. Maya informa 15 licenças, seleciona o centro de custo de Marketing e acrescenta o motivo: a equipe precisa de agendamento compartilhado e aprovação das publicações das campanhas.

O aplicativo calcula o custo anual antes do envio. O marketing tem orçamento de software suficiente, então a solicitação passa pela verificação. Se o orçamento fosse insuficiente, o aplicativo poderia interromper a solicitação e pedir que Maya escolhesse outro centro de custo ou solicitasse financiamento adicional. Isso impede que um gestor aprove uma compra que o financeiro não pode pagar.

O chefe do departamento de Maya recebe a solicitação porque ela está dentro do limite de gastos do gestor. A tela de aprovação mostra o custo, o número de usuários, o motivo comercial e o saldo do orçamento. O gestor aprova.

O setor de compras recebe um registro completo com fornecedor e plano, total anual e data de renovação, centro de custo e resultado do orçamento, o motivo de Maya e a aprovação do gestor com data e hora. Um coordenador de compras verifica se a empresa já tem um acordo com o fornecedor. Se tiver, cria o pedido de compra usando os detalhes salvos. Se não tiver, inicia a análise do fornecedor antes de fazer o pedido.

O coordenador registra o número do pedido de compra e marca a solicitação como Pedida. Maya pode ver a atualização sem perguntar ao setor de compras. Quando o fornecedor confirma as 15 licenças, o coordenador marca a solicitação como Recebida e registra quem administrará a conta.

Esse fluxo mantém cada decisão ligada à solicitação. O financeiro consegue ver por que a equipe comprou o software, qual orçamento pagou por ele e quem aprovou o gasto.

Erros que atrasam as compras

Um processo de compras pode parecer simples em um fluxograma e ainda frustrar seus usuários. Os problemas geralmente aparecem quando o sistema trata toda solicitação como incomum ou perde o controle das alterações após a aprovação.

Enviar todas as solicitações para níveis superiores

Muitas equipes enviam todas as solicitações a um único gestor sênior. Essa pessoa se torna o ponto de espera para itens rotineiros, como um teclado substituto, a renovação mensal de um software ou materiais abaixo de um limite pequeno. Se o gestor ficar ausente por dois dias, todos esperam.

Relacione as rotas de aprovação ao custo, ao departamento e ao tipo de solicitação. Um líder de equipe pode aprovar um item de catálogo padrão abaixo de determinado limite. Um responsável pelo departamento pode analisar compras maiores. O financeiro pode participar quando a solicitação afetar um orçamento ou ultrapassar um limite. Os líderes seniores devem receber exceções, não solicitações comuns.

Permitir alterações silenciosas em solicitações aprovadas

A aprovação final se aplica a um item, quantidade, fornecedor e preço específicos. Se alguém alterar esses detalhes depois, a aprovação pode deixar de corresponder ao gasto.

Defina regras para edições relevantes. Uma mudança de 10 para 12 licenças, ou de US$ 500 para US$ 1.200, deve devolver a solicitação ao responsável pela análise. Pequenas observações, como um contato de entrega, podem continuar editáveis sem reiniciar o fluxo de aprovação de compras.

Um aplicativo de compras sem programação pode manter um histórico de edições e reabrir a aprovação quando campos controlados forem alterados. Isso evita surpresas quando o financeiro comparar o valor aprovado com uma fatura.

Encerrar a solicitação cedo demais

A aprovação não é o fim das compras. O setor ainda precisa registrar o fornecedor, o número do pedido de compra, o preço final, a data do pedido e o status da entrega. Se alguém encerrar uma solicitação antes que esses detalhes existam, a equipe terá de procurar informações em e-mails e planilhas depois.

Use status claros, como Aprovada, Pedida, Recebida e Encerrada. Só mude uma solicitação para Encerrada depois que o setor de compras registrar os detalhes do pedido e confirmar o encaminhamento. Uma assinatura anual aprovada deve continuar como Aprovada até que o comprador registre o pedido do fornecedor ou a referência da renovação.

Essa distinção torna os relatórios mais confiáveis. As equipes podem ver quais solicitações aprovadas ainda precisam de ação, quais pedidos aguardam entrega e quais compras foram concluídas.

Verificações rápidas antes do lançamento

Um teste curto identifica a maioria dos problemas antes que os funcionários dependam do sistema interno de solicitações de compra. Peça a um grupo pequeno que envie solicitações realistas, como materiais de escritório, uma renovação de software e um contrato de serviço. Inclua solicitantes, aprovadores e profissionais que criam pedidos de compra.

Cada solicitação precisa de um responsável claro e de um status visível. O responsável deve mudar quando a tarefa passar do solicitante para um gestor ou comprador. Os rótulos devem explicar o que aconteceu, como Rascunho, Enviada, Aprovada, Rejeitada ou Encaminhada para compras.

Antes de abrir o aplicativo para todos, confirme que cada solicitação mostra o responsável, o status atual, o valor e o próximo aprovador. Compare as regras de aprovação com os limites reais de gastos e as regras de cada departamento. Verifique se o setor de compras consegue ver o fornecedor, o preço cotado, a quantidade aprovada e a data de entrega solicitada.

Teste uma solicitação acima do orçamento e confirme que o aplicativo a interrompe ou a envia à pessoa certa. Rejeite outra solicitação com um motivo claro e confirme que o solicitante recebe esse motivo e pode atualizar o formulário.

Use valores reais nos testes de orçamento. Dê a uma equipe um orçamento mensal restante de US$ 2.000 e envie uma solicitação de US$ 2.400. Decida se o sistema deve bloqueá-la, pedir aprovação ao financeiro ou permitir que o responsável pelo orçamento transfira recursos. Todos os envolvidos devem ver o mesmo resultado.

Teste também as alterações após a aprovação. Um solicitante pode aumentar um pedido de 10 para 15 monitores, ou um fornecedor pode aumentar o preço cotado. O fluxo de aprovação de compras deve enviar a solicitação novamente para aprovação ou identificar claramente as alterações que não precisam de nova análise. Alterações silenciosas criam discussões depois.

Por fim, teste o encaminhamento para o pedido de compra. O setor de compras deve receber os detalhes aprovados em um só lugar, sem redigitá-los a partir de e-mails ou chats. No AppMaster, as equipes podem testar esses caminhos com registros de exemplo e ajustar as regras visuais antes de publicar o aplicativo. Mantenha um registro curto dos testes que falharam, corrija a regra por trás de cada problema e teste novamente.

Escolha os próximos passos

Comece com um departamento que faça compras recorrentes e tenha uma cadeia de aprovação administrável. Softwares de TI, materiais de escritório ou assinaturas de marketing são bons pontos de partida. Dê ao grupo um catálogo curto com itens comuns, preços estimados e as informações de que o setor de compras precisa.

Mantenha a primeira versão focada. O solicitante deve enviar uma necessidade clara, o aprovador deve ver o custo e o status do orçamento, e o setor de compras deve receber uma solicitação completa após a aprovação. Adicione tipos incomuns de solicitação depois que o caminho básico funcionar de forma confiável.

Peça opiniões às pessoas que usam cada parte do sistema interno de solicitações de compra depois das primeiras semanas. Os solicitantes podem identificar campos confusos. Os aprovadores podem explicar onde precisam de mais contexto. Os profissionais de compras podem apontar dados de fornecedores ausentes ou solicitações que ainda chegam fora do aplicativo.

Use esse retorno para remover campos que ninguém usa, adicionar entradas ao catálogo para compras recorrentes, esclarecer limites de aprovação, mostrar a próxima pessoa responsável e registrar por que alguém devolveu ou rejeitou uma solicitação.

O AppMaster pode ajudar as equipes a criar um aplicativo de compras sem programação, sem começar com um projeto técnico vazio. As equipes podem criar formulários de solicitação para funcionários, usar o Business Process Editor para verificações de orçamento e rotas de aprovação e criar telas separadas para gestores e profissionais de compras. O Data Designer pode manter itens de catálogo, departamentos, fornecedores, orçamentos e solicitações em um único lugar.

Um piloto pequeno revela rapidamente problemas práticos. Se os funcionários continuarem enviando solicitações por e-mail, descubra o motivo antes de adicionar mais regras. Crie um caminho que as pessoas escolham porque é mais claro e rápido do que a alternativa. Quando o piloto funcionar bem, adapte a estrutura ao próximo departamento, mantendo o catálogo e as regras de aprovação ligados à forma como essa equipe gasta o dinheiro.