Num provedor de serviços de TI (MSP), nada é mais perigoso que misturar dados entre clientes. O atendimento do cliente A não pode, em hipótese alguma, expor informação do cliente B. O módulo de Clientes do Portal Nyverra ITSM é a fundação desse isolamento — e o ponto de partida de SLA, contratos e relatórios.

Este guia cobre o cadastro de clientes, o modelo multi-tenant, o escopo de visibilidade por perfil e os vínculos que dão contexto ao atendimento.

Interface do módulo no Portal Nyverra ITSM.

O cliente como eixo do sistema

Praticamente tudo no Portal gravita em torno do cliente: chamados, ativos, contratos, contatos, relatórios. Por isso um cadastro bem feito não é burocracia — é o que garante que o sistema saiba por quem está atendendo e sob quais regras.

Área	Relação com o cliente
Chamados	Herda cliente, regras e SLA do escopo
Ativos (CMDB)	Pertencem a um cliente
Contratos	Definem SLA e pool de horas do cliente
Contatos	São as pessoas da organização
Relatórios	Segmentam por cliente

Multi-tenant e escopo de visibilidade

A arquitetura é multi-tenant: uma instância atende várias organizações, cada uma isolada. A visibilidade depende do perfil:

Perfil	Alcance
Usuário do cliente	Vê apenas dados da sua organização
Técnico com VIEW_OWN	Vê os clientes aos quais está vinculado
Técnico/admin com VIEW_ALL	Vê todos os clientes

É essa separação que permite um MSP operar dezenas de clientes na mesma ferramenta sem risco de vazamento entre eles.

O que o cadastro do cliente guarda

• Identificação: razão social, nome fantasia e documento.
• Contatos: pessoas de referência (integradas à Agenda).
• Vínculos: contratos, ativos e serviços de negócio.
• Histórico: chamados e indicadores por cliente.
• Mapa de infraestrutura: no detalhe, a aba de infra mostra o mapa CMDB daquela organização.

Quem usa

Perfil	Uso
Admin / backoffice	Cadastro de clientes, contatos e vínculos
Técnico	Consulta de contexto ao atender
Cliente	Não acessa o cadastro de outros clientes

Como usar: passo a passo

1. Cadastre o cliente com dados completos e documento.
2. Adicione contatos e defina o principal ponto de comunicação.
3. Vincule contratos (SLA, vigência) e ativos (CMDB).
4. Atribua acessos: usuários (que fazem login) e vínculos de técnicos.
5. Use o cliente como filtro em chamados, relatórios e filas.

Regras de negócio

Regra	Explicação
Escopo obrigatório	Chamados e ativos respeitam o cliente — evita misturar dados entre empresas.
MSP	Operadores atendem vários clientes conforme VIEW_ALL vs VIEW_OWN.
Contrato	Contrato vencido pode afetar regras comerciais — siga a política interna além do sistema.
Privacidade	Dados de cliente e contatos são PII — trate conforme LGPD.

Boas práticas

• Padronize a nomenclatura das organizações (evita duplicidade e facilita relatório).
• Mantenha documentos e dados de contato atualizados.
• Defina o contato principal de cada cliente — agiliza comunicação em incidentes.
• Vincule contratos e ativos na criação, não “depois”.
• Use filtros por cliente nos relatórios para visão específica de cada conta.

Erros comuns

Situação	O que fazer
Cliente duplicado	Busque por documento/razão social antes de criar.
Ativo sem cliente	Vincule para garantir escopo e análise de impacto.
Usuário com escopo errado	Revise o vínculo e as permissões no módulo de Usuários.

Perguntas frequentes

Cliente é o mesmo que contato?
Não. O cliente é a organização; os contatos são pessoas dessa organização.

Um técnico pode atender vários clientes?
Sim, conforme permissões (VIEW_ALL) e vínculos.

O cliente vê dados de outros clientes?
Não — o isolamento multi-tenant impede.

Automatize via API

Clientes são expostos por API (/api/clientes), permitindo sincronizar o cadastro com CRM/ERP. Referência em developer.nyverra.com.

Cenários de uso: o cliente como eixo

1. MSP com dezenas de contas. O técnico atende vários clientes na mesma instância. O escopo por cliente garante que ele veja apenas as contas vinculadas — e que dados de um cliente nunca apareçam no atendimento de outro. É o que torna o modelo multi-tenant seguro na prática.

2. Onboarding de um cliente novo. Cadastra-se a organização, seus contatos, o contrato (com SLA) e os ativos iniciais. A partir daí, chamados daquele cliente já herdam as regras corretas — sem configuração caso a caso.

3. Contexto no incidente. Ao abrir o chamado, o técnico vê o histórico daquele cliente, os ativos e o contrato vigente, tomando decisões mais informadas em menos tempo.

KPIs e governança do cadastro

Indicador	O que revela
Clientes ativos vs inativos	Base real de operação
Clientes sem contrato vinculado	Risco comercial
Clientes sem contatos	Comunicação comprometida
Duplicidades detectadas	Qualidade do cadastro

Integração com o restante

O cadastro de clientes não vive isolado: ele alimenta contratos (SLA e pool de horas), CMDB (ativos), relatórios (segmentação) e o Portal do Cliente. Em organizações com CRM/ERP, sincronizar o cadastro via API (/api/clientes) evita retrabalho e divergência de dados. A regra é clara: um cadastro bem feito economiza horas de suporte e evita erros caros.

Checklist de cadastro de clientes

1. Pesquise duplicidade por documento/razão social.
2. Padronize a nomenclatura das organizações.
3. Adicione contatos e defina o principal.
4. Vincule contratos e ativos.
5. Configure o escopo de acesso dos usuários do cliente.
6. Reveja clientes inativos periodicamente.

Perguntas frequentes adicionais

Como o cliente acessa o portal?
Com um usuário vinculado à organização; ele vê apenas os próprios dados.

O que acontece se o cliente ficar sem contatos?
A comunicação fica comprometida; mantenha ao menos um contato principal ativo.

Posso ter várias unidades do mesmo cliente?
Sim, usando localizações/ramificações vinculadas à organização.

Conclusão

Um cadastro de clientes consistente é a base de SLA, contratos e inteligência de atendimento. Com isolamento multi-tenant e escopo por perfil, o Portal Nyverra ITSM permite operar muitos clientes em uma só instância — com segurança e organização.