O guia do Mokapen

Portal de clientes

O portal é o espaço em que um cliente entra com as suas próprias credenciais, não com um usuário Mokapen. A partir daí abre tickets, consulta as pedidos e, se o ativar, o mural. Continua a trabalhar no CRM: o ticket e a pedido nascem nas pipelines que escolheu, com o responsável que indicou.

Encontra-o em Suporte → Portal. Cada portal tem um endereço próprio, do tipo domínio / idioma / portal / slug. O cliente não vê o resto da organização.

Criar o portal e mantê-lo desligado até estar pronto

Na lista prima o botão para um portal novo. Se a organização já atingiu o número máximo, o Mokapen abre a janela do plano em vez de criar outro. Na ficha de cada portal vê título, logótipo, se está ativo ou desligado, e a ligação externa para a home do cliente.

Em Geral define título, slug do URL, idioma predefinido, email do portal e o estado. Ativo significa que a ligação responde. Inativo significa que o portal não é acessível: use-o enquanto prepara pipelines, tópicos e catálogo, para que um cliente não entre numa página vazia. A frase na página é clara: configura o portal e ativa só as áreas que quer mostrar.

O email do portal é o que o cliente vê como remetente das credenciais. Se estiver vazio ou for uma caixa que ninguém lê, os emails de acesso saem na mesma mas as respostas perdem-se.

Que áreas o cliente vê

Em Aplicações liga, para este portal, as áreas com que o cliente pode interagir. Há três entradas, e nem todas as organizações as veem:

• Ticket — o cliente envia pedidos e lê a resposta a partir daí.
• Pedidos — vê produtos e serviços num catálogo e envia pedidos de compra.
• Mural — só aparece se a app News estiver ativa para a organização. Mostra o mural na home do portal.

Ligar a área não chega. Um portal com os tickets ligados e nenhuma pipeline escolhida cria pedidos que não sabe onde encontrar. Um portal com as pedidos ligadas e sem moeda, pipeline e estado deixa a pedido sem lugar na pipeline de vendas.

Quem pode entrar

A página Usuários do portal lista os contatos já autorizados: nome, email, conta, estado, data de criação e o cadeado de privacidade. É uma lista de controlo, não o sítio onde cria o acesso. O filtro no topo restringe as linhas.

O acesso dá-se na ficha de contato, separador Portal. A frase na ficha diz para autorizar o contato a acessar a um ou mais portais da sua organização, para comunicar e receber assistência. Por cada portal há um interruptor. Ligado, o Mokapen cria um usuário de portal para esse contato e envia-lhe um email com as credenciais: pede-lhe para entrar e alterar a senha. Se desligar o interruptor, o usuário de portal é excluído. Pedidos e tickets já ligados ao contato permanecem no CRM.

Na mesma ficha escolhe a visibilidade:

• Privada — o cliente vê os seus tickets e pedidos.
• Empresa — vê também tickets e pedidos ligados à mesma empresa. Use-a para o referente que deve seguir os pedidos de todo o cliente, não para cada pessoa da empresa: caso contrário um comercial vê os tickets abertos por um colega.

Email, nome, apelido e senha são os dados de login do portal. Não são o usuário Mokapen e não herdam um papel do CRM. Se alterar email ou senha, o contato recebe um email de atualização.

Um contato sem email não pode receber as credenciais. Um contato arquivado ou excluído desaparece da lista de usuários do portal mesmo que o acesso estivesse ligado.

Tickets abertos pelo cliente

Em Ticket escolhe a pipeline onde acabam os pedidos e os tópicos a propor. Os tópicos são os já definidos nessa pipeline: se a lista estiver vazia, o cliente não tem nada a selecionar. O botão na página leva às configurações de tópicos dessa pipeline, onde os cria e, se precisar, atribui um responsável ao tópico.

O responsável predefinido recebe todos os tickets nascidos do portal. Na criação pode mesmo assim atribuí-los a outro membro. Sem um responsável, o pedido entra na pipeline e ninguém o vê no seu kanban «o meu trabalho» até alguém se encarregar.

O cliente, depois de entrar, vê os seus tickets abertos e pode acompanhar o estado. Não vê os tickets internos que não estão ligados a ele (ou, com visibilidade Empresa, à sua empresa).

Pedidos a partir do catálogo

Em Pedidos prepara como nasce a pedido quando o cliente confirma o carrinho. Define moeda, pipeline, estado inicial e responsável. Título e descrição aceitam variáveis do usuário de portal: nome, apelido, email, empresa, contato, nota, privacidade, idioma. Um título do tipo «Pedido de {nome} {cognome}» continua legível na pipeline; um título vazio deixa uma linha sem contexto.

No portal o cliente percorre o catálogo, põe artigos no carrinho e confirma. Se no carrinho houver produtos a enviar, é-lhe pedido o país para os custos de envio. Os impostos, IVA incluído, calculam-se após a confirmação. Com a pedido criada, o cliente recebe as atualizações e pode acompanhá-la na sua área.

Com visibilidade Empresa a lista de pedidos inclui também as pedidos da mesma empresa, não só as do contato que iniciou sessão.

Quando a escolha é errada

• Portal ativo antes das aplicações. O cliente entra e encontra a home sem tickets nem pedidos. Mantenha-o inativo até pipeline, tópicos e responsáveis estarem definidos.
• Visibilidade Empresa para todos. Cada contato da empresa vê os pedidos dos outros. Deixe-a para o referente.
• O mesmo portal para clientes que não se devem ver. Um portal é um URL. Os dados continuam filtrados por contato, mas título, idioma e áreas são comuns. Dois clientes com necessidades diferentes (só tickets, ou tickets e catálogo) ficam melhor em dois portais.
• Confundir usuário de portal e usuário Mokapen. O primeiro só entra no portal. O segundo trabalha no CRM e tem um papel. Dar ao cliente um usuário Convidado do CRM não é o portal: vê fichas internas, não o catálogo.

Guias relacionados: Ticket, Pedidos, Contatos.