A palavra suporte logo nos faz pensar em call center e todo o sofrimento habitual de conversar com pessoas que nunca conseguem resolver nosso problema. Ao criarmos o Be on the Net, passamos a ter que dar suporte também. A questão é como fazer isso de modo apropriado e economicamente viável.
A solução que encontramos foi investir pesadamente na criação de screencasts. Criamos um screencast para cada assunto que precisamos ensinar aos nossos usuários. Alguns tópicos nem têm a ver diretamente com o uso do Be on the Net, mas são questões que afetam a forma como nossos usuários apresentam seus trabalhos da internet. Então, nos interessa ajudar e orientar as pessoas, tanto quanto possível.
O investimento nos screencasts foi considerável. Foram meses de trabalho até alcançarmos a base de vídeos que temos hoje. São vídeos que tipicamente são vistos apenas por nossos clientes. Mas, resolvemos publicar um aqui, para que vocês possam ter uma ideia.
O vídeo abaixo mostra como colocar tags em fotos, usando o Lightroom. Na verdade é útil para qualquer fotógrafo, mesmo aqueles que não usam o Be on the Net. Por isso resolvemos publicá-lo.
O screencast permite que o cliente aprenda no seu próprio ritmo. Além disso, o cliente vê o que deve fazer, ao invés de apenas escutar as instruções por telefone e tentar interpretá-las.
Nós ainda atendemos algumas ligações de clientes, sobretudo quando ainda há algum assunto que não ficou suficientemente claro nos screencasts. Mas, sabemos que o volume seria muito maior se não tivéssemos investido na criação deles. De fato, esse investimento que fizemos é uma das coisas que tem possibilitado que continuemos tendo pouca gente cuidando do Be on the Net. Na maior parte do tempo, somos apenas eu e o Leandro cuidando de tudo. E a vida segue em paz, mesmo com a entrada de cada vez mais clientes.
Essa é uma estratégia que recomendo fortemente. Quanto ao software, usamos o ScreenFlow, no Mac. É excepcional e muito fácil de usar.
A palavra suporte logo nos faz pensar em call center e todo o sofrimento habitual de conversar com pessoas que nunca conseguem resolver nosso problema. Ao criarmos o Be on the Net, passamos a ter que dar suporte também. A questão é como fazer isso de modo apropriado e economicamente viável.
A solução que encontramos foi investir pesadamente na criação de screencasts. Criamos um screencast para cada assunto que precisamos ensinar aos nossos usuários. Alguns tópicos nem têm a ver diretamente com o uso do Be on the Net, mas são questões que afetam a forma como nossos usuários apresentam seus trabalhos da internet. Então, nos interessa ajudar e orientar as pessoas, tanto quanto possível.
O investimento nos screencasts foi considerável. Foram meses de trabalho até alcançarmos a base de vídeos que temos hoje. São vídeos que tipicamente são vistos apenas por nossos clientes. Mas, resolvemos publicar um aqui, para que vocês possam ter uma ideia.
O vídeo abaixo mostra como colocar tags em fotos, usando o Lightroom. Na verdade é útil para qualquer fotógrafo, mesmo aqueles que não usam o Be on the Net. Por isso resolvemos publicá-lo.
O screencast permite que o cliente aprenda no seu próprio ritmo. Além disso, o cliente vê o que deve fazer, ao invés de apenas escutar as instruções por telefone e tentar interpretá-las.
Nós ainda atendemos algumas ligações de clientes, sobretudo quando ainda há algum assunto que não ficou suficientemente claro nos screencasts. Mas, sabemos que o volume seria muito maior se não tivéssemos investido na criação deles. De fato, esse investimento que fizemos é uma das coisas que tem possibilitado que continuemos tendo pouca gente cuidando do Be on the Net. Na maior parte do tempo, somos apenas eu e o Leandro cuidando de tudo. E a vida segue em paz, mesmo com a entrada de cada vez mais clientes.
Essa é uma estratégia que recomendo fortemente. Quanto ao software, usamos o ScreenFlow, no Mac. É excepcional e muito fácil de usar.
Quando um novo cliente contratava nossos serviços, o que fazíamos era bastante simples. O cliente escolhia o template e a gente copiava os arquivos de CSS e de imagens para a conta dele. Pronto, problema resolvido. Era a abordagem mais simples e óbvia que poderíamos usar e foi a que usamos. Mas, naturalmente, não era nem de longe a mais adequada. Afinal, a palavra duplicação sempre vem acompanhada de dor e sofrimento. Ambos bateram em nossa porta logo depois de colocarmos os primeiros sites de clientes no ar.
Falhas
O uso real dos templates no dia-a-dia mostrou que cada um deles possuía pequenas falhas. Por mais que revisássemos cada template no momento da compra dele, sempre havia uma ou outra falha que nos escapava, mas ficava bem fácil de enxergar uma vez que o template estive em uso no site de um cliente.
Quando encontrávamos uma falha, corrigíamos, naturalmente. Mas, espere, estávamos duplicando os templates. Então, ao fazermos a correção no original, tínhamos que replicar em cada uma das cópias. Mas, não pense que bastava copiar e colar a correção.
Cada site tem um layout que usa, como base, o código CSS de um template. Mas, normalmente há pequenas alterações no CSS que são pertinentes exclusivamente àquele site. Portanto, não apenas tínhamos um código CSS duplicado, como também modificado.
Colocar as correções nestes arquivos CSS era um tormento. Foi nesse estágio que sofrimento e dor passaram a nos visitar diariamente. Também pudera, tanto tempo desenvolvendo software e caímos no mais básico de todos os erros: duplicar.
A solução
Durante o mês de janeiro, sofremos muito com essa questão, aprendemos bastante e fizemos o que precisava ser feito. Alteramos completamente o funcionamento do sistema para que ele passasse a ter uma forma de utilização de templates mais racional.
A partir daí, cada site passou a ter um parâmetro de configuração onde informávamos o nome do template adotado. Por sua vez, cada site poderia ter um conjunto de arquivos CSS e de imagens específicos para particularidades dele. Então, o HTML de cada página gerada para o site do cliente passava a ficar assim:
Primeiro carrega todos os arquivos CSS do template.
Em seguida, carrega todos os arquivos CSS específicos daquele site, os quais, eventualmente, alteram ligeiramente o funcionamento do template original.
No momento em que essa alteração foi feita, as coisas ficaram bem mais simples. Continuamos a corrigir eventuais falhas nos templates, mas agora, podíamos corrigir em um único ponto e todos os sites que usavam o template corrigido recebiam a correção automaticamente.
Lição do dia: não duplique! O "copiar e colar" de hoje realmente significará a dor e o sofrimento de amanhã. E o pior: este amanhã sempre chega muito mais rápido do que imaginamos.
Quando um novo cliente contratava nossos serviços, o que fazíamos era bastante simples. O cliente escolhia o template e a gente copiava os arquivos de CSS e de imagens para a conta dele. Pronto, problema resolvido. Era a abordagem mais simples e óbvia que poderíamos usar e foi a que usamos. Mas, naturalmente, não era nem de longe a mais adequada. Afinal, a palavra duplicação sempre vem acompanhada de dor e sofrimento. Ambos bateram em nossa porta logo depois de colocarmos os primeiros sites de clientes no ar.
Falhas
O uso real dos templates no dia-a-dia mostrou que cada um deles possuía pequenas falhas. Por mais que revisássemos cada template no momento da compra dele, sempre havia uma ou outra falha que nos escapava, mas ficava bem fácil de enxergar uma vez que o template estive em uso no site de um cliente.
Quando encontrávamos uma falha, corrigíamos, naturalmente. Mas, espere, estávamos duplicando os templates. Então, ao fazermos a correção no original, tínhamos que replicar em cada uma das cópias. Mas, não pense que bastava copiar e colar a correção.
Cada site tem um layout que usa, como base, o código CSS de um template. Mas, normalmente há pequenas alterações no CSS que são pertinentes exclusivamente àquele site. Portanto, não apenas tínhamos um código CSS duplicado, como também modificado.
Colocar as correções nestes arquivos CSS era um tormento. Foi nesse estágio que sofrimento e dor passaram a nos visitar diariamente. Também pudera, tanto tempo desenvolvendo software e caímos no mais básico de todos os erros: duplicar.
A solução
Durante o mês de janeiro, sofremos muito com essa questão, aprendemos bastante e fizemos o que precisava ser feito. Alteramos completamente o funcionamento do sistema para que ele passasse a ter uma forma de utilização de templates mais racional.
A partir daí, cada site passou a ter um parâmetro de configuração onde informávamos o nome do template adotado. Por sua vez, cada site poderia ter um conjunto de arquivos CSS e de imagens específicos para particularidades dele. Então, o HTML de cada página gerada para o site do cliente passava a ficar assim:
Primeiro carrega todos os arquivos CSS do template.
Em seguida, carrega todos os arquivos CSS específicos daquele site, os quais, eventualmente, alteram ligeiramente o funcionamento do template original.
No momento em que essa alteração foi feita, as coisas ficaram bem mais simples. Continuamos a corrigir eventuais falhas nos templates, mas agora, podíamos corrigir em um único ponto e todos os sites que usavam o template corrigido recebiam a correção automaticamente.
Lição do dia: não duplique! O "copiar e colar" de hoje realmente significará a dor e o sofrimento de amanhã. E o pior: este amanhã sempre chega muito mais rápido do que imaginamos.
Hoje começo a descrever algumas das lições que aprendemos até o momento com o Be on the Net. E começarei logo por uma das mais importantes, pois envolve a parte mais sensível do corpo humano, o bolso.
No Be on the Net os pagamentos são mensais e adiantados. Porém, no início, nos deparamos com a seguinte questão: quando um cliente contrata nosso serviço, qual deve ser o momento a partir do qual devemos começar a cobrar?
Devemos cobrar imediatamente? Ou primeiro colocamos o site no ar e depois fazemos a primeira cobrança?
O que nos pareceu mais razoável, inicialmente, foi colocar o site no ar, avançando até certo ponto, quando então enviávamos o primeiro boleto de pagamento. Chegar neste ponto, envolvia algumas tarefas executadas por nós e outras pelo cliente.
O problema
Logo descobrimos que esse modelo não funciona. As pessoas que nos contratam normalmente têm um pequeno negócio e são muito ocupadas. Querem um site porque acreditam no retorno para os negócios. Mas, ele trará mais trabalho. É inevitável. A pessoa precisa colocar seu conteúdo no ar, bem como fazer outras atividades relacionadas ao site.
Então, o que acabava acontecendo é que nós executávamos nossas tarefas rapidamente, enquanto o cliente frequentemente demorava para fazer a parte dele. E nós demorávamos para começar a receber pelo site.
Analisando superficialmente, pode-se ter a impressão de que apenas nós saíamos perdendo. Mas, isso não é verdade. O cliente também perde por não avançar com o site. Frequentemente, ele perde até mais, pois o site ajuda a trazer novos negócios. Então, cada dia que o cliente passa sem o site no ar, é mais um dia em que ele deixa de captar novos negócios.
No nosso lado, além de termos de enfrentar a demora de alguns clientes, também tivemos que lidar com outros que nos deram todo o trabalho inicial e, quando chegou a hora de fazer o primeiro pagamento, sumiram. Portanto, trabalhamos à toa.
A solução
Um dia a ficha caiu para mim. Nós estávamos simplesmente fazendo a coisa errada e a solução era a mais simples de todas. O cliente deve pagar a primeira mensalidade imediatamente, assim que fecha o contrato. E nós só devemos começar a preparar o site dele quando o pagamento puder ser identificado na conta corrente da empresa.
Isso é bom para nós por razões óbvias: a gente recebe logo e só trabalha para quem realmente paga. Quem nos procura na empolgação, mas não paga por qualquer razão que seja, simplesmente não recebe o serviço, o que é perfeitamente coerente.
Isso também é bom para o cliente. O fato de ele ter pago logo no início, faz com que ele priorize o site. Esse é o ponto principal. Por já ter pago, a pessoa dedica tempo e esforço para fazer a parte que lhe cabe, o quanto antes.
Essa é uma mudança que parece óbvia olhando em retrospecto. Mas, levou uns bons dois meses até nos darmos conta de que tínhamos que fazer isso.
Quando as coisas estão no início, a gente ainda não sabe ao certo se alguém vai contratar o produto. Temos medo. Então, tentamos adiar os pagamentos ao máximo, para que seja possível mostrar um pouco do nosso trabalho ao cliente, antes que ele tenha que abrir a carteira. Com o tempo, a gente ganha confiança. E essa confiança foi necessária para que passássemos a cobrar logo no início, antes mesmo que fizéssemos qualquer preparação do site do cliente.
De lá para cá, temos respeitado esse modelo e os resultados não poderiam ser melhores. Quem paga leva, quem não paga, não leva e, portanto, não nos gera nenhum trabalho.
Hoje começo a descrever algumas das lições que aprendemos até o momento com o Be on the Net. E começarei logo por uma das mais importantes, pois envolve a parte mais sensível do corpo humano, o bolso.
No Be on the Net os pagamentos são mensais e adiantados. Porém, no início, nos deparamos com a seguinte questão: quando um cliente contrata nosso serviço, qual deve ser o momento a partir do qual devemos começar a cobrar?
Devemos cobrar imediatamente? Ou primeiro colocamos o site no ar e depois fazemos a primeira cobrança?
O que nos pareceu mais razoável, inicialmente, foi colocar o site no ar, avançando até certo ponto, quando então enviávamos o primeiro boleto de pagamento. Chegar neste ponto, envolvia algumas tarefas executadas por nós e outras pelo cliente.
O problema
Logo descobrimos que esse modelo não funciona. As pessoas que nos contratam normalmente têm um pequeno negócio e são muito ocupadas. Querem um site porque acreditam no retorno para os negócios. Mas, ele trará mais trabalho. É inevitável. A pessoa precisa colocar seu conteúdo no ar, bem como fazer outras atividades relacionadas ao site.
Então, o que acabava acontecendo é que nós executávamos nossas tarefas rapidamente, enquanto o cliente frequentemente demorava para fazer a parte dele. E nós demorávamos para começar a receber pelo site.
Analisando superficialmente, pode-se ter a impressão de que apenas nós saíamos perdendo. Mas, isso não é verdade. O cliente também perde por não avançar com o site. Frequentemente, ele perde até mais, pois o site ajuda a trazer novos negócios. Então, cada dia que o cliente passa sem o site no ar, é mais um dia em que ele deixa de captar novos negócios.
No nosso lado, além de termos de enfrentar a demora de alguns clientes, também tivemos que lidar com outros que nos deram todo o trabalho inicial e, quando chegou a hora de fazer o primeiro pagamento, sumiram. Portanto, trabalhamos à toa.
A solução
Um dia a ficha caiu para mim. Nós estávamos simplesmente fazendo a coisa errada e a solução era a mais simples de todas. O cliente deve pagar a primeira mensalidade imediatamente, assim que fecha o contrato. E nós só devemos começar a preparar o site dele quando o pagamento puder ser identificado na conta corrente da empresa.
Isso é bom para nós por razões óbvias: a gente recebe logo e só trabalha para quem realmente paga. Quem nos procura na empolgação, mas não paga por qualquer razão que seja, simplesmente não recebe o serviço, o que é perfeitamente coerente.
Isso também é bom para o cliente. O fato de ele ter pago logo no início, faz com que ele priorize o site. Esse é o ponto principal. Por já ter pago, a pessoa dedica tempo e esforço para fazer a parte que lhe cabe, o quanto antes.
Essa é uma mudança que parece óbvia olhando em retrospecto. Mas, levou uns bons dois meses até nos darmos conta de que tínhamos que fazer isso.
Quando as coisas estão no início, a gente ainda não sabe ao certo se alguém vai contratar o produto. Temos medo. Então, tentamos adiar os pagamentos ao máximo, para que seja possível mostrar um pouco do nosso trabalho ao cliente, antes que ele tenha que abrir a carteira. Com o tempo, a gente ganha confiança. E essa confiança foi necessária para que passássemos a cobrar logo no início, antes mesmo que fizéssemos qualquer preparação do site do cliente.
De lá para cá, temos respeitado esse modelo e os resultados não poderiam ser melhores. Quem paga leva, quem não paga, não leva e, portanto, não nos gera nenhum trabalho.
Neste mesmo mês de dezembro de 2008, lá pelos últimos dias, lançamos o Be on the Net como um produto comercial. Agora ele já está no ar há pouco mais de um semestre e chegou a hora de contar o que se passou e onde estamos neste momento.
Onde estamos?
No momento, temos em torno de 100 clientes no Be on the Net (muitos ainda não estão apresentados na página de clientes). É claro que gostaríamos de já ter um número maior, porém, 100 clientes é um número bem maior do que poderíamos esperar em tão poucos meses. Não, não me refiro a tão poucos meses como valor absoluto. O que quero dizer é que a vida comercial do Be on the Net tem pouco mais de seis meses, o que é muito pouco para um produto. E, apesar disso, já são 100 clientes. Uau! Isso é melhor do que poderíamos imaginar.
O que rolou?
O Be on the Net de hoje não é muito diferente do que era em dezembro do ano passado. A essência permanece a mesma, as funcionalidades são praticamente as mesmas e o código sofreu poucas alterações. Fizemos alguns ajustes finos ao longo do caminho, corrigimos alguns poucos bugs, mas no geral, continua sendo o mesmo código de seis meses atrás. Então isso quer dizer que ficamos de bobeira durante todo esse tempo?
De forma alguma. Ter o software funcionando foi só o começo. No momento em que ele foi lançado comercialmente, tivemos que passar a lidar com os outro 95% que realmente fazem o software deixar de ser apenas um software e efetivamente se transformar em um produto desejado pelas pessoas.
Operacional
Nós montamos uma fila de espera durante o desenvolvimento do Be on the Net. Com isso, várias pessoas contrataram o serviço logo nos primeiros dias. O que nos fez perceber rapidamente que precisávamos criar toda uma infraestrutura operacional que simplificasse nosso trabalho.
Quando um novo cliente nos contrata, há várias pequenas ações que precisamos fazer aqui e outras que o cliente tem que fazer por lá. Por exemplo, emissão do contrato, geração de boleto de pagamento, configuração de DNS, aplicação do template escolhido etc. Individualmente, cada tarefa dessas é simples, mas quando tomadas em conjunto, podem consumir um bom tempo, sobretudo se não estiverem bem otimizadas.
Essas são algumas das questões que mais geraram aprendizado para nós:
Ao longo dos próximos dias, tentarei escrever sobre cada um desses pontos. A ideia é tentar revelar, ao máximo, os bastidores dos primeiros meses do funcionamento do Be on the Net como um produto comercial. Fique ligado!
Neste mesmo mês de dezembro de 2008, lá pelos últimos dias, lançamos o Be on the Net como um produto comercial. Agora ele já está no ar há pouco mais de um semestre e chegou a hora de contar o que se passou e onde estamos neste momento.
Onde estamos?
No momento, temos em torno de 100 clientes no Be on the Net (muitos ainda não estão apresentados na página de clientes). É claro que gostaríamos de já ter um número maior, porém, 100 clientes é um número bem maior do que poderíamos esperar em tão poucos meses. Não, não me refiro a tão poucos meses como valor absoluto. O que quero dizer é que a vida comercial do Be on the Net tem pouco mais de seis meses, o que é muito pouco para um produto. E, apesar disso, já são 100 clientes. Uau! Isso é melhor do que poderíamos imaginar.
O que rolou?
O Be on the Net de hoje não é muito diferente do que era em dezembro do ano passado. A essência permanece a mesma, as funcionalidades são praticamente as mesmas e o código sofreu poucas alterações. Fizemos alguns ajustes finos ao longo do caminho, corrigimos alguns poucos bugs, mas no geral, continua sendo o mesmo código de seis meses atrás. Então isso quer dizer que ficamos de bobeira durante todo esse tempo?
De forma alguma. Ter o software funcionando foi só o começo. No momento em que ele foi lançado comercialmente, tivemos que passar a lidar com os outro 95% que realmente fazem o software deixar de ser apenas um software e efetivamente se transformar em um produto desejado pelas pessoas.
Operacional
Nós montamos uma fila de espera durante o desenvolvimento do Be on the Net. Com isso, várias pessoas contrataram o serviço logo nos primeiros dias. O que nos fez perceber rapidamente que precisávamos criar toda uma infraestrutura operacional que simplificasse nosso trabalho.
Quando um novo cliente nos contrata, há várias pequenas ações que precisamos fazer aqui e outras que o cliente tem que fazer por lá. Por exemplo, emissão do contrato, geração de boleto de pagamento, configuração de DNS, aplicação do template escolhido etc. Individualmente, cada tarefa dessas é simples, mas quando tomadas em conjunto, podem consumir um bom tempo, sobretudo se não estiverem bem otimizadas.
Essas são algumas das questões que mais geraram aprendizado para nós:
Ao longo dos próximos dias, tentarei escrever sobre cada um desses pontos. A ideia é tentar revelar, ao máximo, os bastidores dos primeiros meses do funcionamento do Be on the Net como um produto comercial. Fique ligado!
Pronto, agora temos uma fonte mais rica de informação do que somente os links do sidebar aqui do lado. →
E aguardem! Temos mais planos para esta recém-inaugurada página. Breve acabaremos com o suspense...
Nosso filhote está crescendo e se tornando um homenzinho! :)
Pronto, agora temos uma fonte mais rica de informação do que somente os links do sidebar aqui do lado. →
E aguardem! Temos mais planos para esta recém-inaugurada página. Breve acabaremos com o suspense...
Nosso filhote está crescendo e se tornando um homenzinho! :)
