White label ou motor de reservas próprio: a conta real
O orçamento chega e parece suportável. Um programador em quem confia deu preço a um motor de reservas — pesquisa, resultados, checkout, um ecrã de administração, três meses — e o número não é absurdo. Há dois anos que quer um sistema seu. É neste momento que a escolha entre white label ou desenvolver o seu próprio motor de reservas é realmente decidida, e costuma ser decidida com as provas erradas: o preço do primeiro mês em vez da forma do segundo ano.
O orçamento é honesto. Só que é apenas da parte do trabalho que consegue ver.
O que uma estimativa de desenvolvimento está mesmo a orçamentar
Quase todas as estimativas que lhe vão entregar orçamentam superfícies: um formulário de pesquisa, uma lista de resultados, uma página de dados dos passageiros, um passo de pagamento, uma tabela de reservas no painel. Esse trabalho é real, e uma equipa competente fá-lo bem. É também a metade indiferenciada — aquela em que duas agências que vendem a mesma rota nunca competem. Nunca ninguém escolheu uma agência porque o ecrã de availability tinha melhor espaçamento.
A outra metade é o lado da ligação que não se vê a partir do browser. É aí que vão os anos.
O custo é o número de integrações, não a interface
Peça acesso a um fornecedor e não recebe uma chave de API por email de volta. Recebe um ambiente de testes, um processo de certificação, credentials emitidas por entidade legal, um documento de regras e um contacto que responde ao ritmo dele. Depois conhece o dialecto próprio desse fornecedor: static rates num sítio e live availability noutro, allotment com release period ao lado de free-sale, um cut-off que o seu motor tem de respeitar, fare rules que decidem se uma alteração é cobrada, um catálogo de ancillaries que não encaixa no de mais ninguém. Agora multiplique pelo número de fornecedores que os seus clientes esperam que tenha.
Uma integração é um projecto. Seis são um departamento, e nunca termina, porque nenhum desses seis concordou em parar de mudar.
A mesma armadilha está por trás de cada ecrã que o orçamento lista. A pesquisa parece uma funcionalidade até ter duas companhias a devolver o mesmo itinerário a preços diferentes e ter de decidir, em código, qual delas o cliente vê. Um reembolso parece um botão até a fare rule dizer penalização, o fornecedor dizer voucher e o cliente dizer cartão. O markup parece um número numa página de definições até ao dia em que quer uma regra para clientes corporate, outra para um sub-agente no Porto e uma terceira para o balcão na mesma tarifa.
É esta aritmética que o orçamento deixa de fora, e face ao interface não é um erro de arredondamento — é o produto. Numa plataforma white label o trabalho já está feito e já tem equipa: o conteúdo dos fornecedores chega à montra através de supplier groups em vez de contratos assinados um a um, e cada site liga voos, hotéis, pacotes ou attractions consoante o que realmente vende.
A comparação que sobrevive ao segundo ano
Leia a tabela como operador, não como comprador. A pergunta em cada linha é a mesma: de quem é a responsabilidade?
| Desenvolver de raiz | White label | |
|---|---|---|
| Tempo até à primeira reserva real | Um ciclo de desenvolvimento, depois certificação com cada fornecedor | No próprio dia, num subdomínio da plataforma — o assistente de registo trata disso sem pedir cartão |
| Ligações a fornecedores | Suas para obter, certificar e manter, uma de cada vez | Incluídas; activa as que vende |
| Idiomas e moedas no arranque | Os que especificou e pagou | 40 idiomas, right-to-left incluído; cada site escolhe a moeda por omissão e a lista que oferece |
| Um fornecedor muda a API | O seu backlog, com o prazo deles | Problema da plataforma, resolvido uma vez para todos |
| A emissão falha às 02:00 | Você, ou o programador que atender | A equipa de piquete da plataforma |
| Mudar o aspecto do site | Uma release | Uma definição — tema, cores, tipos de letra e logótipo mudam no painel sem novo deploy |
| Um fluxo que mais ninguém vende | Dá para construir, exactamente como trabalha | Só se a plataforma já o modelar |
| De quem é o código | Seu | Não é seu — seus são a marca, os clientes e as condições comerciais |
Duas dessas linhas jogam a favor de desenvolver. Não são prémios de consolação. Se o que vende for suficientemente invulgar, pesam mais do que tudo o que está acima.
O que custa errar nisto
O modo de falhar de um motor feito em casa não é o projecto que desaba. Esses vêem-se, doem e ultrapassam-se. A versão cara é um sistema que funciona — e depois lentamente deixa de funcionar.
O programador que o escreveu segue caminho, e o seguinte orça cada pequena alteração como risco porque ninguém vivo leu aquele código. Um fornecedor descontinua um endpoint no calendário dele e as reservas começam a falhar de um modo que os clientes notam antes da sua monitorização. Uma fare rule bem codificada no primeiro ano nunca mais é revista, e o ADM que se segue é debitado ao seu número IATA, não ao do prestador. As credentials de pagamento expiram. Os certificados expiram. Uma framework duas versões atrasada transforma-se numa conversa de segurança para a qual não tinha uma semana prevista.
Nada disto chega como fatura, e é por isso que nunca aparece na comparação que as pessoas de facto fazem. Chega como atenção. Um dono que passa a terça-feira num PNR partido não está a vender nessa terça, e as agências que emudecem depois de construírem o seu sistema raramente o fazem porque o software falhou — emudecem porque a pessoa que trazia negócio é agora a pessoa que o mantém.
Quando desenvolver é mesmo a decisão certa
Às vezes é, e os casos são específicos o suficiente para se medir contra eles.
- O software é o factor de diferenciação. Se vende tecnologia a outras empresas de turismo em vez de vender viagens, não pode subcontratar aquilo por que cobra.
- Já tem engenheiros e orçamentou o segundo. Não o programador que constrói — o que assume a manutenção depois de o primeiro sair. Um desenvolvimento sem plano de sucessão é um aluguer com passos extra.
- Tem um fluxo que ninguém modela. Um operador de peregrinações que detém as próprias camas e cose PNR de grupo aos prazos de visto está a fazer algo em que um motor genérico nunca vai encaixar bem.
Há ainda um caminho que não é nenhum dos dois: comprar a montra e desenvolver só a peça que é genuinamente sua. A plataforma expõe APIs de voos e hotéis exactamente para isso, embora o acesso comece por uma conversa e não por uma chave self-service. Avalie o híbrido antes de se comprometer com o desenvolvimento inteiro, porque a parte que queria mesmo controlar costuma ser um fluxo, não um motor completo.
E se o seu modelo assenta em sub-agentes, ponha-lhe preço a sério. Aqui os credit limits e a facturação de settlement são conceitos de primeira classe e não uma folha de cálculo que alguém reconcilia ao domingo; num desenvolvimento próprio são um segundo projecto que ninguém pôs no primeiro orçamento.
Uma pergunta, feita aos dois lados
Antes de assinar o que quer que seja, faça a mesma pergunta ao programador e à plataforma: em Março um fornecedor muda a certificação — quem faz o trabalho, com o prazo de quem, e como é que eu fico a saber? As respostas não vão ser parecidas, e a diferença entre elas é aquilo entre que está realmente a escolher.
Comparar uma montra a funcionar com um orçamento é um teste mais honesto do que comparar dois documentos, por isso se quiser ver o que fica provisionado antes de se comprometer, abra um site no assistente — não pede cartão, e o subdomínio que lhe dá fica para sempre, mesmo depois de ligar o seu próprio domínio.