Vale a pena ter app próprio para clientes? Como decidir

A conversa costuma começar numa reunião de diretoria. Um concorrente lançou aplicativo, o comercial ouviu de dois clientes que "seria bom ter um app", e alguém sai da sala com a missão de orçar. Meses depois, o app está nas lojas, foi baixado por uma parte pequena da carteira e quase ninguém abre depois da primeira semana. Enquanto isso, o atendimento continua respondendo pelo WhatsApp a mesma pergunta sobre segunda via de boleto.

O problema raramente é técnico. O app funciona. O que faltou foi responder antes se o cliente tem motivo para manter um ícone da sua empresa na tela do celular. Instalar um aplicativo é um pedido grande: ocupa espaço, exige login, pede permissões. O cliente só aceita esse pedido quando o retorno é frequente e claro.

Resposta direta: vale a pena ter aplicativo próprio quando o cliente usa o seu serviço toda semana ou mais, quando os avisos em tempo real fazem parte do serviço e quando há quem cuide do app depois do lançamento. Fora desse cenário, um portal web responsivo costuma entregar o mesmo autoatendimento sem a barreira da instalação. Abaixo, os critérios para decidir, o esforço de manter um app nas lojas e um caminho em etapas para não apostar tudo de uma vez.

A resposta curta: quando vale ter um app próprio

Vale ter aplicativo próprio para clientes quando pelo menos duas destas condições são verdadeiras:

• O cliente usa o serviço com frequência, toda semana ou mais. Pedido recorrente, agendamento, acompanhamento de entrega, consulta de saldo ou de pontos.
• A notificação é parte do serviço, não propaganda. "Seu pedido saiu para entrega", "seu técnico chega em 20 minutos", "seu laudo está pronto".
• O app precisa de recursos do celular que a web entrega mal: câmera usada o tempo todo, localização, leitura de código, biometria para entrar rápido, uso sem internet.
• O cliente espera encontrar você na loja de aplicativos, porque o seu setor já se acostumou com isso e a ausência passa a impressão de empresa menor.

Se nenhuma ou só uma dessas condições aparece, um portal web responsivo quase sempre resolve, com menos esforço de manutenção e sem a barreira da instalação. E existe um meio-termo, o PWA, explicado mais abaixo.

A pergunta certa: com que frequência o cliente usa

Frequência de uso é o critério que mais pesa, e o mais ignorado. Um jeito simples de olhar para ela:

Olhe para os dados que você já tem: quantas vezes por mês um cliente típico liga, manda mensagem ou acessa o site para resolver algo com você. Se a resposta é "uma vez quando chega o boleto", um app vai competir pelo espaço do celular com aplicativos que a pessoa abre todo dia, e vai perder.

Outro ponto: quem é o cliente. Na venda para empresas, o usuário costuma ser um comprador ou um analista que trabalha no computador. Ele prefere acessar pelo navegador, ao lado do ERP dele. Na venda para pessoa física, o celular é o canal principal. Isso muda bastante a resposta.

O que um app faz que um site não faz

Um aplicativo instalado tem vantagens reais, e vale conhecê-las para não pagar por um app que não usa nenhuma delas:

• Presença na tela inicial. O ícone lembra o cliente da sua empresa sem você precisar mandar mensagem.
• Notificações confiáveis em Android e iPhone, com controle fino de categorias.
• Acesso amplo ao hardware: câmera com mais controle, localização em segundo plano, Bluetooth, NFC, leitura de documentos.
• Login persistente e biometria, que tiram o atrito de digitar senha toda vez.
• Funcionamento offline mais robusto, com banco de dados local.
• Presença nas lojas, o que ajuda na descoberta e transmite confiança para parte do público.

Se nenhum desses itens é central para o que o cliente faz com você, o app vira um site dentro de uma moldura, com custo de app.

Quando um portal web responsivo resolve

Um portal web bem construído atende a maior parte das necessidades de autoatendimento: consultar pedidos, baixar notas e boletos, abrir chamado, acompanhar status, atualizar cadastro, ver contratos. Ele abre em qualquer navegador, no computador e no celular, e não precisa de instalação nem de aprovação de loja.

O portal resolve bem quando:

• O uso é mensal ou esporádico.
• O cliente é empresa e trabalha no computador.
• As funções são consulta e documentos, sem dependência de câmera, localização ou uso offline.
• A empresa quer atualizar com frequência sem depender de revisão de loja nem esperar o cliente atualizar o app.

Detalhamos o que um portal desse tipo deve oferecer no texto sobre portal do cliente B2B. E, se o objetivo é tirar o cliente do telefone, a página de portal do cliente mostra como esse tipo de sistema costuma ser organizado.

Notificações, câmera, localização e offline

Esses quatro recursos são os que normalmente decidem a favor do app. Vale olhar cada um com honestidade.

Notificações

Notificação é a principal razão para ter app, e também a mais mal usada. Ela vale quando informa algo que o cliente quer saber naquele momento: o pedido saiu, o horário foi confirmado, o pagamento foi recebido. Se a ideia é usar notificações para promoções semanais, o cliente desliga a permissão ou desinstala.

Antes de decidir, liste os avisos que o seu cliente realmente gostaria de receber. Se a lista tem dois itens por mês, e-mail ou WhatsApp resolvem. Se tem eventos diários e sensíveis a tempo, o app ganha força.

Câmera

Enviar foto de um documento, de um produto com defeito ou de um comprovante funciona pelo navegador do celular. O app faz diferença quando a câmera é usada o tempo todo: leitura de código de barras em sequência, captura guiada de documento com recorte automático, fotos em lote para uma vistoria.

Localização

Mostrar uma loja próxima funciona na web. Acompanhar o cliente a caminho de uma retirada ou usar a localização com o app fechado exige app instalado.

Offline

Se o cliente usa o serviço em lugar sem sinal (área rural, galpão, obra) e precisa registrar algo ali, o app com banco local é o caminho. Para um cliente que consulta pedidos em casa ou no escritório, offline não pesa.

A comparação técnica entre app nativo, multiplataforma e PWA, com os limites de cada um no iPhone, está no texto app nativo, híbrido ou PWA. Se a escolha for multiplataforma, compare React Native ou Flutter para o app da empresa.

O meio-termo: PWA

PWA (aplicativo web progressivo) é um site construído para se comportar como aplicativo. O cliente abre pelo navegador e, se quiser, adiciona um ícone à tela inicial. A partir daí o sistema abre em tela cheia, sem a barra do navegador, e pode guardar parte das informações para funcionar com conexão instável.

Para quem está decidindo, o PWA tem três vantagens claras: não passa por revisão de loja, chega ao cliente atualizado no momento em que você publica e reaproveita o mesmo código do portal web. O preço é uma experiência menos completa em alguns pontos:

• Instalação manual no iPhone. Lá o cliente precisa usar a opção "Adicionar à Tela de Início" do menu de compartilhar. Muita gente não conhece o caminho, e é preciso ensinar.
• Notificações com mais restrições no iPhone. Elas existem nas versões mais recentes do iOS, mas só depois que o PWA é adicionado à tela inicial e o cliente autoriza.
• Acesso ao celular mais limitado, sobretudo para localização com o app fechado, Bluetooth e uso offline mais pesado.
• Ausência nas lojas por padrão, o que pesa para o público que procura a empresa por lá.

Por isso o PWA funciona bem como etapa intermediária: dá um ícone na tela a quem usa com frequência e ajuda a medir se existe demanda real para um app nas lojas.

O esforço de manter o app nas lojas

Esta é a parte que costuma ficar fora da conta na hora de decidir. Ter um app para clientes não é um projeto com fim; é um produto que precisa de cuidado contínuo:

• Duas lojas, duas revisões. Cada versão passa pela análise da App Store e da Google Play antes de chegar ao cliente. Uma rejeição pode atrasar uma correção urgente.
• Atualizações obrigatórias. As lojas e os sistemas operacionais mudam regras e versões todo ano. Um app em que ninguém mexe por um tempo pode deixar de funcionar direito em aparelhos novos ou ser barrado de publicar atualizações.
• Versões antigas em circulação. Parte dos clientes não atualiza. O sistema por trás precisa conviver com versões diferentes do app ao mesmo tempo, ou forçar a atualização.
• Contas, certificados e políticas. Contas de desenvolvedor da empresa (não de um fornecedor), política de privacidade, declaração de dados coletados nas lojas e, em geral, a opção de o próprio usuário excluir a conta pelo app.
• Suporte ao cliente. "Não consigo entrar", "o app travou no meu celular antigo". Alguém precisa atender e reproduzir.
• LGPD. Dados pessoais coletados pelo app (localização, fotos, documentos) precisam de finalidade clara, consentimento quando aplicável e controle de acesso. Vale validar a política com o jurídico.

Nada disso impede ter um app. Mas, se a empresa não tem quem cuide do produto depois do lançamento, um portal web é mais honesto com a capacidade da casa.

Critérios de decisão: checklist para o gestor

Responda com sim ou não, pensando no cliente típico e não no mais entusiasmado:

1. O cliente interage com a empresa pelo menos uma vez por semana?
2. Existem avisos sensíveis a tempo que ele quer receber?
3. Ele precisa usar câmera, localização, Bluetooth ou leitura de código com frequência?
4. Ele precisa usar o serviço sem internet?
5. O cliente é pessoa física e usa principalmente o celular?
6. O setor já tem apps de referência que o cliente usa e com os quais vai comparar?
7. Existe alguém na empresa que será dono do app depois do lançamento, olhando métricas, avaliações e prioridades?
8. Existe um sistema por trás (ERP, sistema de gestão, API) com os dados que o app vai mostrar, ou isso também precisa ser construído? Nesse caso, decida entre Firebase ou back-end próprio.

Se as respostas 1 a 6 tiverem pelo menos três "sim", o app próprio merece estudo sério. Se a 7 for "não", resolva isso antes de qualquer código. Se a 8 for "não", o primeiro projeto provavelmente é o sistema, e o app vem depois.

Como medir se o app está dando resultado

Downloads são a métrica menos útil. Um app baixado e esquecido não reduziu nenhum custo nem aumentou nenhuma venda. Defina antes de lançar o que vai acompanhar:

• Usuários ativos por semana ou por mês, comparados com o total de clientes ativos.
• Retenção: quantos dos que instalaram ainda usam depois de 30 e de 90 dias.
• Tarefas resolvidas no app que antes passavam pelo atendimento: segunda via, status de pedido, reagendamento.
• Volume de atendimento humano nesses mesmos assuntos, antes e depois.
• Pedidos ou recompras originados no app, quando ele tem função de venda.
• Taxa de aceite de notificações e quantos desligam depois.
• Avaliações nas lojas, que dizem rápido o que está irritando o cliente.

Se a meta é reduzir atendimento, meça atendimento. Se é aumentar recompra, meça recompra. Um app sem meta de negócio definida não tem como provar que valeu a pena.

Começar pela web e evoluir para app

Para a maioria das empresas que ainda não sabem como o cliente vai usar o autoatendimento, o caminho mais seguro é em etapas:

1. Construa a base de dados e as APIs que vão alimentar qualquer canal. Pedidos, documentos, status, cadastro. Essa camada é reaproveitada pelo portal e pelo app.
2. Lance um portal web responsivo com as funções de maior demanda no atendimento. Ele chega a todos os clientes sem instalação.
3. Meça o uso. Veja quem acessa pelo celular, com que frequência e quais funções usa.
4. Torne o portal instalável como PWA, se fizer sentido, para dar um ícone na tela inicial a quem usa com frequência.
5. Construa o app nativo ou multiplataforma quando os dados mostrarem uso frequente pelo celular e necessidade de recursos que a web não entrega bem.

Esse caminho evita o cenário do início do texto: um app trabalhoso de manter e usado por poucos. E, como o app reaproveita as APIs do portal, a segunda etapa sai mais rápida do que começar do zero.

Para recortar a primeira versão sem tentar resolver tudo de uma vez, o texto sobre como definir o escopo de um MVP traz um método prático.

Quanto ao prazo, ele depende muito do escopo e de quanto da base já existe. Como referência genérica, um portal com poucas funções costuma levar algumas semanas a poucos meses; um app com notificações, login e integração a um sistema existente, alguns meses. Só o diagnóstico permite estimar com responsabilidade.

Perguntas frequentes

Quanto tempo leva para desenvolver um app para clientes?

O prazo de um app para clientes depende do escopo e de quanto da base já existe. Como referência genérica, um portal web com poucas funções costuma levar de algumas semanas a poucos meses, e um app com login, notificações e integração a um sistema existente, alguns meses. Só um diagnóstico permite estimar com responsabilidade.

Um app para clientes precisa de um sistema por trás?

Sim. Um app para clientes mostra pedidos, documentos, status e cadastro que vêm de algum lugar, normalmente um ERP, um sistema de gestão ou uma API própria. Se esses dados ainda não estão acessíveis, o primeiro projeto costuma ser essa camada de APIs, que depois alimenta tanto o portal web quanto o aplicativo.

Um PWA aparece na App Store e na Google Play?

Por padrão, não. O PWA é aberto pelo navegador e o cliente adiciona o ícone à tela inicial, o que no iPhone exige usar a opção "Adicionar à Tela de Início" do menu de compartilhar. Quando a presença nas lojas pesa para o público da empresa, o caminho mais comum é um app nativo ou multiplataforma.

Em nome de quem deve ficar a conta do app nas lojas?

Em nome da própria empresa, nunca do fornecedor que desenvolveu o app. As contas de desenvolvedor na App Store e na Google Play controlam a publicação de cada versão, e uma conta em nome de terceiros pode impedir até uma correção simples se a relação com o fornecedor terminar. O mesmo vale para certificados e chaves de assinatura.

Notificação por WhatsApp substitui a notificação do app?

Depende da frequência e da urgência dos avisos. Se o cliente recebe poucos avisos por mês, como boleto disponível ou nota emitida, e-mail ou WhatsApp resolvem bem. Quando há eventos diários e sensíveis a tempo, como pedido saindo para entrega ou técnico a caminho, a notificação do app próprio ganha força e justifica a instalação.

Como a Pervian Tech trabalha apps para clientes

Na Pervian Tech, começamos pela pergunta deste texto, não pela tecnologia: com que frequência o seu cliente precisa de você, o que ele resolve hoje pelo telefone ou pelo WhatsApp e quais dados sua empresa já tem disponíveis. A partir daí recomendamos o canal certo, seja portal web, PWA ou app nas lojas, e desenhamos a camada de APIs para que nenhum trabalho se perca se a decisão evoluir depois.

Quando o app faz sentido, o desenvolvimento mobile inclui publicação nas lojas em contas da sua empresa, notificações, métricas de uso definidas desde o início e o plano de manutenção depois do lançamento. Veja também como organizamos o desenvolvimento de aplicativos para empresas e outros textos da categoria aplicativos.

Cada projeto é sob medida, e o investimento é definido sob consulta, depois de um diagnóstico inicial gratuito. Se a sua empresa está discutindo se precisa de um app, conte como seus clientes falam com vocês hoje.