Por que este guia é diferente
A maioria dos guias sobre como mudar de fornecedor de assinatura eletrónica é escrita por um único fornecedor que quer que você escolha a sua plataforma.
Este foi criado para lhe dizer o que realmente acontece quando faz a transição, incluindo as partes que são lentas e irritantes, para que se possa antecipar a elas em vez de as descobrir a meio da migração.
Porque é que a migração é a parte mais arriscada
A migração é o momento no ciclo de vida da assinatura eletrónica onde mais coisas correm mal.
Está a executar fluxos de contratos ativos, por vezes com prazos legais associados, e qualquer lacuna na cobertura traduz-se num signatário que não consegue concluir um documento.
O objetivo aqui é uma transição limpa, sem qualquer janela temporal onde a assinatura deixe de funcionar.
Abaixo apresenta-se a versão sincera: por que razão as equipas saem, o que se transfere e o que não se transfere, uma lista de verificação que pode realmente seguir, cronogramas realistas, as armadilhas que causam atrasos e como construir um caso de custos real.
Equipas de SaaS
Para as equipas de SaaS que integram a assinatura no seu próprio produto, o limite é normalmente o modelo de preços e a API.
As taxas por utilizador não fazem sentido quando os seus subscritores são os clientes dos seus clientes,
e os níveis de envelope tornam cada surto de crescimento numa renegociação.
A API ou suporta uma separação multi-tenant limpa e assinatura incorporada ou vai criar-lhe dificuldades ao longo de todo o caminho.
agências
Para agências que enviam contratos para dezenas de clientes não relacionados, o custo é o problema que se agrava.
Cada nova colaboração com um cliente adiciona volume,
e a faturação por utilizador ou escalões significa que a sua fatura cresce mais rápido do que a sua margem.
Também precisa que a experiência de assinatura de cada cliente pareça limpa e individual, e não como se todos estivessem a partilhar a mesma conta.
negócio interno
Para as equipas de negócios internas que utilizam a assinatura eletrónica para a sua própria papelada, a frustração é pagar preços empresariais para uma utilização ocasional.
Envia um punhado de contratos, cartas de oferta e NDAs por mês…
no entanto, está num plano com mínimos de lugares e um compromisso que pressupõe um grande volume diário.
Deseja escapar aos mínimos sem ter de configurar um projeto de programador para o fazer.
Se o seu motivo de saída for especificamente o custo, os custos ocultos das plataformas de assinatura eletrónica corporativas e a análise de preços da API do DocuSign vão mais fundo do que podemos ir aqui.
O que realmente é transferido e o que não é
Esta é a secção que todos os guias escritos por fornecedores saltam, porque a resposta honesta não é lisonjeira para ninguém.
A migração não é uma exportação e importação de base de dados. Algumas coisas transitam conceptualmente, e outras coisas são reconstruídas.
Os Modelos Quase Nunca São Importados de Forma Limpa
As coordenadas dos campos, a lógica condicional e a atribuição de funções são armazenadas em formatos específicos do fornecedor, pelo que, na prática, recria os modelos na nova plataforma em vez de transferir um ficheiro.
Essa é a tarefa mais subestimada em qualquer migração, sendo que cerca de 40 por cento dos atrasos na transição se devem a problemas de exportação, normalmente dados incompletos ou metadados perdidos, como os detalhes de verificação do signatário.
Os seus acordos concluídos são uma questão separada
Os seus acordos concluídos são uma questão à parte, e esta é a parte que causa mais ansiedade.
Os documentos que já assinou com o seu antigo fornecedor permanecem legalmente válidos ao abrigo do enquadramento em que foram executados. Não volta a assinar nada.
O ESIGN, a UETA e o eIDAS vinculam a validade ao momento da assinatura, e não ao fornecedor que guarda o ficheiro posteriormente.
Ainda assim, deve exportar e arquivar os seus documentos assinados e as respetivas pistas de auditoria antes de fechar a conta antiga, porque o acesso geralmente termina quando o contrato acaba.
Eis a repartição prática do que muda de sítio e do que é reconstruído:
Reconstruir na nova plataforma
Modelos, layouts de campos, lógica condicional, encaminhamento de aprovações e quaisquer páginas de assinatura personalizadas com a marca.
Volte a ligar, não copie
Integrações de API, webhooks e pontos de contacto de CRM ou ERP. A lógica é a mesma, os endpoints e payloads mudam.
Exportar e arquivar, não migrar
Acordos concluídos e pistas de auditoria. Guarde-os, mas eles passam a viver como registos e não como dados ativos no novo sistema.
Recriar do zero
Funções de utilizador, permissões e grupos de signatários.
Equipas de SaaS
As equipas de SaaS devem focar-se nas fases técnicas: aprovisionar as chaves de API logo de início, ligar o editor de templates incorporável e a assinatura incorporada, e utilizar as Customer Workspaces para que cada um dos seus clientes fique claramente separado. Coloque os seus webhooks em paridade antes de encaminhar qualquer tráfego real.
Agências
As agências devem concentrar-se na separação de clientes e no envio em lote. Configure um espaço de trabalho limpo por cliente para que a assinatura permaneça personalizada e isolada, e depois teste um envio em lote com um lote real antes de migrar toda a gente.
Negócios internos
As equipas de negócio internas podem ignorar a maioria dos passos técnicos. O fluxo de envio sem código significa que não precisa de um programador, pelo que a sua lista de verificação foca-se principalmente na reconstrução de modelos e na confirmação das suas definições de identidade do signatário.
Quanto tempo demora realmente a migração da assinatura eletrónica
A Gama Realista
O prazo realista é de quatro a oito semanas para a maioria das organizações, impulsionado pelo tamanho e pela complexidade da integração e não pela plataforma em si.
Uma simples troca de API com um punhado de modelos pode demorar de duas a quatro semanas.
Estruturas maiores demoram mais tempo devido à reconstrução de modelos e ao período de execução paralela, e não porque a integração técnica seja difícil.
O que as Migrações Reais Mostram
Os pontos de prova de migrações reais são encorajadores do lado técnico. Uma empresa moveu cerca de 13.000 modelos e 85.000 utilizadores em cerca de um mês.
Uma equipa do mercado médio entrou em funcionamento em duas semanas. O que esses números escondem é o planeamento que aconteceu primeiro.
As equipas que se movem rapidamente são as que concluíram a auditoria e o mapeamento de dependências antes de tocarem no novo sistema.
Como Planear o Orçamento do Cronograma
Planeie o seu cronograma em duas fases sobrepostas. A fase de execução paralela, geralmente de uma a três semanas, é onde ambos os sistemas estão ativos e valida o novo em relação ao tráfego real.
A fase de transição faseada, mais uma a três semanas, é onde transfere o volume de produção em lotes controlados. Só depois disso é que desativa o fornecedor antigo.
Erros comuns de migração
Cada migração falhada ou dolorosa que vimos remete para uma pequena lista de erros evitáveis.
A transição direta
Mudar tudo de um dia para o outro sem uma execução paralela significa que qualquer dependência esquecida se tornará numa interrupção imediata. Execute primeiro ambos os sistemas em simultâneo, sempre.
Subestimar a reconstrução do modelo
As equipas veem "migração" e assumem importação, depois perdem uma semana a reconstruir modelos à mão porque nunca planearam isso. Conte os seus modelos durante a auditoria e trate a reconstrução como trabalho real.
A falta de paridade entre webhooks e registos de auditoria apanha as equipas técnicas de surpresa
A sua nova integração precisa de disparar os mesmos eventos e produzir um registo de auditoria equivalente antes de poder confiar nela. Teste isto com payloads reais, não com base em suposições.
Identidade do signatário em falta ou requisitos de conformidade regional
Isto pode causar documentos rejeitados. Se um tipo de documento necessitava de um nível de verificação específico no sistema antigo, necessita do equivalente no novo, correspondido por região.
Ignorar os períodos de aviso prévio é o mais silencioso
A maioria dos contratos empresariais exige um aviso prévio de 30 a 90 dias, e as taxas de rescisão antecipada podem atingir 50% do valor restante do contrato. Se cancelar demasiado tarde, pagará por dois sistemas; se cancelar demasiado cedo, perderá o acesso a documentos que ainda necessita de exportar. Planeie o encerramento com o mesmo cuidado com que planeia o lançamento.
O ROI da mudança
O objetivo desta secção não é prometer um número, mas sim dar-lhe os dados necessários para construir o seu próprio caso. O que importa é o custo total de propriedade, não o preço de tabela.
Os Custos Únicos da Mudança
Comece com os custos únicos da mudança. A migração de dados e a reconstrução de modelos exigem tempo de engenharia ou de operações. A nova formação exige um pouco mais.
Depois, há os custos de saída já mencionados: taxas de rescisão antecipada de até 50% do contrato restante e um período de aviso prévio de 30 a 90 dias durante o qual poderá estar a pagar a dois fornecedores ao mesmo tempo. Estes custos são reais e é por isso que um cronograma honesto inclui um período de transição.
Pesar o Modelo em Curso
Por outro lado, pondere o modelo contínuo. A Firma.dev funciona no sistema pós-pago a € 0,049 por envelope, cerca de 5 cêntimos de USD, sem mínimos mensais e sem taxas por utilizador. Compare isso com um modelo de assinatura mais excedentes, onde paga por um plano quer o utilize quer não, e depois paga novamente quando o excede.
Um Exemplo Prático Simples
Imagine que envia 2000 envelopes por ano…
Na Firma.dev, isso representa cerca de 58 € por ano em custos de envelopes, aproximadamente 62 USD, sem necessidade de adquirir licenças de utilizador.
Num plano de subscrição típico, poderá pagar por um escalão anual mais licenças, independentemente de atingir ou não o limite de envelopes, sendo aí que se abre a lacuna para remetentes de volume baixo a médio e para agências cujo volume por cliente é irregular.
Faça os Seus Próprios Cálculos
Faça a sua própria contagem de envelopes em ambos os modelos antes de decidir. Para uma análise detalhada dos custos, consulte como as equipas reduzem os custos de assinatura eletrónica ao mudarem para o preço por envelope e os preços atuais do Firma.dev.
Migrar do DocuSign
Geralmente é uma decisão sobre custo e flexibilidade de API. Enquanto isso, consulte DocuSign vs Firma.dev.
Migrar do Dropbox Sign
As equipas superam os planos escalonados e querem preços por envelope.
Migrar do PandaDoc
Muitas vezes sobre evitar custos baseados em utilizadores para uma utilização apenas de assinatura.
Migrar do Adobe Sign
Geralmente impulsionado pela complexidade de preços e pelo atrito de integração.
Migrar do SignNow
Entretanto, consulte SignNow vs Firma.dev.
Migrar de uma configuração personalizada
Para equipas que mantêm a assinatura interna e que querem deixar de ser responsáveis por esse código.
