Requisitos de Software de Suporte: A Lista de Verificação Completa

Escolher o software de apoio ao cliente certo depende de saber exatamente do que a sua equipa precisa antes de começar a comparar ferramentas. Já vi equipas de CX escolherem plataformas que pareciam excelentes nas demonstrações, mas que ficavam aquém no encaminhamento, no acompanhamento de SLA ou nas integrações de que dependiam diariamente.

A escolha errada custa-lhe tempo, dinheiro e motivação dos agentes. Esta lista de verificação divide os requisitos por prioridade—indispensáveis, expectativas padrão e necessidades específicas—para que possa pré-selecionar ferramentas que se adequem realmente aos seus fluxos de trabalho, aos seus clientes e à sua infraestrutura tecnológica.

Lista de verificação dos requisitos de software de apoio ao cliente

Utilizo esta lista de verificação dos requisitos de software de apoio ao cliente para comparar plataformas com base em fluxos de trabalho de suporte reais, necessidades dos clientes e limitações técnicas. Começo pelos requisitos de que todas as equipas precisam e, em seguida, separo as funcionalidades padrão das considerações específicas de cada setor:

Requisitos funcionais essenciais

Indispensáveis absolutos

• Sistema de gestão de tickets: A plataforma deve permitir aos agentes criar, atribuir, atualizar, definir prioridades, fundir e fechar tickets a partir de uma única interface. Cumprir este requisito significa que cada interação com o cliente tem um ciclo de vida rastreável, desde o primeiro contacto até à resolução.
• Suporte multicanal (omnicanal): Todos os contactos recebidos—e-mail, chat em direto, telefone, redes sociais e formulários Web—devem aparecer numa caixa de entrada unificada. Os agentes nunca devem ter de alternar entre ferramentas distintas para tratar diferentes canais.
• Encaminhamento e atribuição automatizados de tickets: O sistema deve utilizar regras configuráveis para encaminhar automaticamente os tickets para o agente, equipa ou fila certos, com base em critérios como o canal, o tipo de problema ou o segmento de cliente—sem triagem manual.

Requisitos padrão

• Base de conhecimento e portal de autosserviço: A plataforma deve disponibilizar um repositório pesquisável e organizado de artigos, perguntas frequentes e guias práticos, acessível tanto aos clientes como aos agentes. Os clientes devem conseguir resolver problemas comuns sem abrir um ticket.
• Gestão e acompanhamento de SLA: Deve ser possível definir objetivos de tempo de resposta e de resolução, acompanhar o progresso em relação a esses objetivos em tempo real e acionar escalamentos automáticos quando um ticket estiver em risco de incumprimento.
• Relatórios e painéis de análise: Os painéis integrados devem apresentar métricas como pontuações CSAT, tempo até à primeira resposta, taxas de resolução e desempenho individual dos agentes—sem ser necessário exportar dados para as consultar.
• Respostas predefinidas e macros: Os agentes devem poder guardar e inserir modelos de resposta pré-escritos para perguntas comuns. As macros devem suportar ações em várias etapas, como enviar uma resposta e atualizar simultaneamente um campo do ticket.
• Ferramentas de colaboração: A plataforma deve suportar notas internas, @menções e caixas de entrada partilhadas, para que os agentes possam coordenar o tratamento dos tickets sem que o cliente veja a discussão interna.

Requisitos específicos

• Funcionalidades de IA e assistente de conversação: A plataforma deve tratar automaticamente as respostas de primeira linha, identificar a intenção do cliente a partir do conteúdo da mensagem e evitar a criação de tickets, apresentando conteúdos relevantes de autosserviço antes de envolver um agente.
• Gestão de assistência técnica e de deslocações ao local: Para empresas que enviam técnicos às instalações dos clientes, a plataforma deve suportar o agendamento, a atribuição de trabalhos e o acompanhamento do estado dos técnicos no terreno—e não apenas filas de suporte digital.

Requisitos técnicos e de integração

Indispensáveis absolutos

• Integração com CRM: A plataforma deve ligar-se de forma nativa ou através de API ao seu CRM—Salesforce, HubSpot ou equivalente—para que os agentes possam consultar os registos completos dos clientes, os negócios em aberto e o histórico de interações sem sair da interface do serviço de apoio ao cliente.
• API REST aberta e webhooks: A plataforma deve disponibilizar uma API REST documentada e suportar webhooks de saída, para que a sua equipa possa criar integrações personalizadas, acionar fluxos de trabalho externos e sincronizar dados com ferramentas que não tenham conectores pré-criados.
• Implementação SaaS na nuvem com SLA de disponibilidade: A plataforma deve ser alojada e mantida pelo fornecedor, com uma garantia contratual de disponibilidade de 99.9% ou superior, eliminando a necessidade de a sua equipa gerir a infraestrutura ou assegurar a manutenção dos servidores.

Requisitos padrão

• Integração de e-mail e calendário: A plataforma deve sincronizar bidirecionalmente com o Gmail, o Outlook e o Office 365, para que os agentes possam gerir a correspondência dos pedidos de suporte e o agendamento sem terem de alternar entre aplicações.
• Aplicações móveis para iOS e Android: A plataforma deve ter aplicações móveis nativas que permitam aos agentes consultar, responder e atualizar pedidos de suporte a partir de um telemóvel ou tablet — e não apenas através de uma vista do navegador otimizada para dispositivos móveis.
• Integrações pré-configuradas com ferramentas de comunicação: A plataforma deve disponibilizar integrações prontas a utilizar com ferramentas como o Slack, o Microsoft Teams e o Zoom, para que os alertas de pedidos de suporte, os escalamentos e a colaboração entre agentes possam ocorrer dentro das ferramentas que a sua equipa já utiliza.
• Escalabilidade e desempenho: A plataforma deve manter tempos de resposta e capacidade de gestão de pedidos consistentes à medida que aumentam o volume de suporte e o número de agentes, sem exigir alterações manuais à infraestrutura ou atualizações de plano que provoquem períodos de indisponibilidade.

Requisitos especiais

• Opção de implementação no local: Para organizações com políticas rigorosas de residência de dados ou restrições regulamentares, o fornecedor deve disponibilizar uma implementação totalmente alojada pelo cliente, que funcione integralmente dentro da sua própria infraestrutura.
• Integrações com plataformas de comércio eletrónico: A plataforma deve ligar-se a sistemas de comércio eletrónico como o Shopify, o Magento ou o WooCommerce, incorporando diretamente na vista do pedido de suporte os dados da encomenda, o estado do envio e o histórico de compras.
• Integração com telefonia e CTI: A plataforma deve integrar-se profundamente com os sistemas telefónicos dos centros de contacto, permitindo funcionalidades como janelas de contexto em chamadas recebidas, criação automática de pedidos de suporte a partir dos registos de chamadas e registo de chamadas associado ao histórico de pedidos de suporte do cliente.

Requisitos de segurança e conformidade

Requisitos absolutamente indispensáveis

• Encriptação de dados em trânsito e em repouso: A plataforma deve encriptar todos os dados transmitidos entre utilizadores e servidores utilizando TLS/SSL e armazenar os dados com encriptação AES-256 ou equivalente. Cumprir este requisito significa que os dados dos clientes são ilegíveis para partes não autorizadas, quer estejam a ser transmitidos, quer estejam armazenados numa base de dados.
• Controlo de acesso baseado em funções (RBAC): A plataforma deve permitir aos administradores atribuir permissões ao nível das funções, controlando exatamente quais os agentes, gestores e equipas que podem consultar, editar ou eliminar pedidos de suporte, dados de clientes e definições de configuração. Cumprir este requisito significa que nenhum agente tem acesso para além do necessário à sua função profissional.
• Conformidade com o RGPD e a privacidade dos dados: A plataforma deve suportar pedidos relativos aos direitos dos titulares dos dados, gestão de consentimento e políticas configuráveis de retenção de dados. Cumprir este requisito significa que pode responder a pedidos de eliminação, gerir durante quanto tempo os dados dos clientes são armazenados e demonstrar conformidade regulamentar quando solicitado.

Requisitos padrão

• Suporte para início de sessão único (SSO) e SAML: A plataforma deve integrar-se com fornecedores de identidade como o Okta ou o Azure Active Directory, para que os agentes iniciem sessão através do sistema de autenticação existente da sua organização. Cumprir este requisito significa que pode aplicar políticas de acesso a toda a empresa e desativar imediatamente o acesso dos agentes quando estes saem da organização.
• Autenticação de dois fatores e multifator (2FA/MFA): A plataforma deve suportar um segundo passo de verificação no início de sessão — através de uma aplicação autenticadora, SMS ou token de hardware. Cumprir este requisito significa que as palavras-passe comprometidas, por si só, não são suficientes para aceder ao sistema de suporte.
• Registos de auditoria e monitorização da atividade: A plataforma deve manter um registo completo e inviolável das ações dos utilizadores, incluindo edições de pedidos de suporte, alterações de estado, atualizações de configuração e eventos de início de sessão. Cumprir este requisito significa que pode reconstruir exatamente o que aconteceu em qualquer pedido de suporte ou sessão de administração.
• Avaliação SOC 2 Tipo II: O fornecedor deve dispor de um relatório SOC 2 Tipo II atualizado, elaborado por um auditor independente, que confirme que os seus controlos de segurança foram testados ao longo do tempo — e não apenas avaliados num único momento. Cumprir este requisito significa que dispõe de provas de terceiros de que o fornecedor trata os seus dados de forma responsável.

Requisitos especiais

• Conformidade com a HIPAA: O fornecedor deve assinar um Acordo de Associado Comercial (BAA) e demonstrar controlos relativos ao acesso, à encriptação, ao registo de auditorias e à notificação de violações que cumpram os requisitos da HIPAA para informações de saúde protegidas. Cumprir este requisito significa que as organizações de saúde podem utilizar legalmente a plataforma para tratar interações de suporte relacionadas com pacientes.
• Conformidade com a PCI-DSS: A plataforma deve cumprir os controlos do Padrão de Segurança de Dados da Indústria de Cartões de Pagamento para qualquer ambiente onde possam surgir dados de cartões de pagamento em pedidos ou mensagens de clientes. Cumprir este requisito significa que não está a expor dados dos titulares de cartões num canal de suporte não seguro.
• Residência dos dados e opções de alojamento regional: O fornecedor deve disponibilizar a possibilidade de armazenar os seus dados numa região geográfica específica — como a UE, os EUA ou a APAC — sem os replicar noutras jurisdições. Cumprir este requisito significa que pode satisfazer as leis locais de soberania dos dados e as políticas internas de governação de dados.

Requisitos de Suporte e Implementação do Fornecedor

Requisitos Absolutamente Essenciais

• Suporte técnico 24/7: O fornecedor deve disponibilizar suporte técnico ininterrupto através de canais em direto — não apenas documentação ou um sistema de pedidos. Cumprir este requisito significa que a sua equipa tem um processo de escalamento real quando algo avaria à meia-noite ou durante o fim de semana.
• Preços e licenciamento transparentes: O fornecedor deve publicar preços claros e previsíveis — por agente, por nível ou baseados na utilização — sem taxas não divulgadas para funcionalidades padrão. Cumprir este requisito significa que pode elaborar um orçamento preciso e evitar surpresas nos custos depois de assinar.
• Assistência na migração de dados: O fornecedor deve disponibilizar ferramentas, documentação ou suporte prático para transferir o histórico de pedidos, os registos de clientes e as configurações existentes do seu sistema antigo. Cumprir este requisito significa que não perde conhecimento institucional nem deixa os agentes a trabalhar sem contexto histórico durante a mudança.

Requisitos Padrão

• Responsável dedicado pelo processo de integração: O fornecedor deve designar um contacto de implementação identificado que oriente a sua equipa durante a configuração inicial, a parametrização e a entrada em funcionamento. Cumprir este requisito significa que tem um único responsável durante a fase de implementação de maior risco.
• Documentação e recursos de formação: O fornecedor deve manter materiais de consulta autónoma atualizados — guias escritos, apresentações em vídeo e percursos de certificação — aos quais os agentes e administradores possam aceder sempre que necessário. Cumprir este requisito significa que a sua equipa não depende totalmente do suporte do fornecedor para aprender a utilizar a plataforma.
• Atualizações regulares do produto e visibilidade do roteiro: O fornecedor deve publicar um roteiro de desenvolvimento e notas de versão com uma periodicidade consistente. Cumprir este requisito significa que pode planear tendo em conta as próximas alterações e avaliar se a orientação da plataforma está alinhada com as suas necessidades a longo prazo.
• Comunidade de utilizadores e ecossistema de parceiros: O fornecedor deve manter um fórum de utilizadores ativo e uma rede de consultores certificados ou programadores terceiros. Cumprir este requisito significa que pode tirar partido do conhecimento dos seus pares, encontrar apoio para a implementação e expandir a plataforma sem ter de recorrer ao fornecedor para tudo.

Requisitos Especiais

• Gestor dedicado de sucesso do cliente: O fornecedor deve designar um contacto de conta identificado, responsável pela relação contínua consigo — não apenas pela implementação. Cumprir este requisito significa que as equipas empresariais têm um parceiro proativo que acompanha a utilização, assinala problemas e defende internamente as suas necessidades.
• Serviços profissionais para desenvolvimento personalizado: O fornecedor deve disponibilizar uma equipa interna de serviços capaz de criar fluxos de trabalho, integrações ou configurações à medida que vão além do produto padrão. Cumprir este requisito significa que as organizações com necessidades não padronizadas não têm de depender totalmente de programadores terceiros para adaptar a plataforma às suas necessidades.

Requisitos de Experiência do Utilizador e Gestão da Mudança

Requisitos Absolutamente Essenciais

• Interface intuitiva para agentes: A plataforma deve apresentar um espaço de trabalho simples e organizado logicamente, onde os agentes possam navegar entre tickets, registos de clientes e ferramentas internas sem uma curva de aprendizagem acentuada. Cumprir este requisito significa que os novos agentes podem tratar a sua primeira fila de tickets sem semanas de formação específica da plataforma.
• Espaço de trabalho personalizável para agentes: Os agentes devem poder configurar os seus próprios painéis, vistas de tickets e filtros de filas de acordo com a forma como realmente trabalham. Cumprir este requisito significa que cada agente vê as informações mais relevantes para a sua função, sem ter de percorrer campos irrelevantes ou esquemas desorganizados.
• Portal de autosserviço voltado para o cliente: A plataforma deve disponibilizar um portal com a identidade da marca, onde os clientes possam enviar tickets, acompanhar o estado dos pedidos em tempo real e aceder à base de conhecimento. Cumprir este requisito significa que os clientes dispõem de um canal direto e transparente que reduz o volume de pedidos recebidos e estabelece expectativas claras quanto à resolução.

Requisitos padrão

• Configuração pelo administrador sem código: Os administradores não técnicos devem poder modificar campos de tickets, regras de fluxo de trabalho, lógica de encaminhamento e definições do portal através de uma interface visual — sem escrever código ou enviar pedidos aos programadores. Cumprir este requisito significa que a sua equipa pode adaptar a plataforma a alterações nos processos sem criar um obstáculo ao desenvolvimento.
• Integração inicial na aplicação e configuração orientada: A plataforma deve incluir visitas guiadas, sugestões e listas de verificação de configuração que ajudem os novos agentes e administradores a aprender as funções essenciais dentro do próprio produto. Cumprir este requisito significa que a sua equipa não tem de depender inteiramente de sessões de formação conduzidas pelo fornecedor para começar a trabalhar eficazmente.
• Notificações e alertas configuráveis: Tanto os agentes como os clientes devem poder controlar quais os eventos que acionam notificações, através de que canais e com que frequência. Cumprir este requisito significa que os agentes se mantêm informados sobre a atividade dos tickets sem sofrerem de fadiga provocada pelos alertas, e que os clientes recebem atualizações de acordo com as suas preferências de comunicação.
• Conformidade com as normas de acessibilidade: A plataforma deve cumprir as normas de acessibilidade WCAG 2.1 AA tanto para a interface dos agentes como para o portal voltado para o cliente. Cumprir este requisito significa que os agentes com deficiência podem utilizar a plataforma sem lacunas ao nível das adaptações, e que os clientes com necessidades de acessibilidade podem interagir com o seu canal de apoio.

Requisitos especiais

• Suporte multilingue e à localização: A plataforma deve suportar vários idiomas na interface dos agentes, no portal do cliente e nas comunicações automatizadas — com a capacidade de encaminhar os clientes para agentes ou conteúdos correspondentes ao seu idioma. Cumprir este requisito significa que as equipas de apoio globais podem atender os clientes no seu idioma preferido sem gerirem instâncias separadas da plataforma.
• Ambiente de testes e pré-produção: O fornecedor deve disponibilizar um ambiente não produtivo onde os administradores possam criar, testar e validar alterações aos fluxos de trabalho, regras de automatização e integrações antes de as colocar em produção. Cumprir este requisito significa que as alterações de configuração não acarretam o risco de interromper filas de tickets ativas ou fluxos de trabalho dos agentes em curso.
• Análise da adoção e utilização para administradores: A plataforma deve disponibilizar dados de utilização por agente e por equipa — frequência de início de sessão, utilização de funcionalidades e padrões de tratamento de tickets — que os administradores possam utilizar para identificar lacunas na adoção. Cumprir este requisito significa que pode detetar quais os agentes que não estão a utilizar funcionalidades essenciais e intervir com formação direcionada antes de isso afetar a qualidade do serviço.

Requisitos específicos do setor/opcionais

Nem todas as equipas precisam destas funcionalidades desde o primeiro dia, mas ignorá-las sem uma análise cuidada é precisamente o que faz com que as listas de verificação de requisitos tendam a falhar. Estes requisitos aplicam-se quando o seu setor, a sua base de clientes ou o seu modelo operacional criam necessidades que uma plataforma de apoio ao cliente de utilização geral não satisfaz por defeito.

Requisitos absolutamente indispensáveis

• Conformidade com a HIPAA: O fornecedor deve assinar um Acordo de Associado Comercial (BAA) e demonstrar controlos relativos ao acesso, à encriptação, ao registo de auditoria e à notificação de violações que satisfaçam os requisitos da HIPAA para informações de saúde protegidas.
  Cumprir este requisito significa que as organizações de cuidados de saúde podem utilizar legalmente a plataforma para tratar interações de apoio relacionadas com pacientes.
• Conformidade com a PCI-DSS: A plataforma deve cumprir os controlos da Norma de Segurança de Dados da Indústria de Cartões de Pagamento em qualquer ambiente onde possam surgir dados de cartões de pagamento em tickets ou mensagens de clientes. Cumprir este requisito significa que os dados dos titulares dos cartões não ficam expostos num canal de apoio não seguro.
• Opção de implementação no local: Para organizações com políticas rigorosas de residência de dados ou restrições regulamentares, o fornecedor deve disponibilizar uma implementação totalmente alojada localmente, que funcione integralmente na sua própria infraestrutura. Cumprir este requisito significa que os seus dados de apoio nunca entram no ambiente de cloud do fornecedor.

Requisitos padrão

• Funcionalidades de IA e chatbot: A plataforma deve tratar automaticamente as respostas de primeira linha, identificar a intenção do cliente a partir do conteúdo da mensagem e apresentar conteúdos relevantes de autosserviço antes de envolver um agente. Cumprir este requisito significa que a sua equipa desvia uma parte mensurável do volume de pedidos sem aumentar o número de funcionários.
• Suporte multilingue e à localização: A plataforma deve suportar vários idiomas na interface do agente, no portal do cliente e nas comunicações automatizadas — com a possibilidade de encaminhar os clientes para agentes ou conteúdos correspondentes ao seu idioma. Cumprir este requisito significa que as equipas de suporte globais podem atender os clientes no idioma que preferem sem gerir instâncias separadas da plataforma.
• Ambiente de sandbox e de preparação: O fornecedor deve disponibilizar um ambiente que não seja de produção, onde os administradores possam criar, testar e validar alterações aos fluxos de trabalho, regras de automatização e integrações antes de as disponibilizarem. Cumprir este requisito significa que as alterações de configuração não correm o risco de perturbar as filas de pedidos em produção ou os fluxos de trabalho ativos dos agentes.
• Gestor dedicado de sucesso do cliente: O fornecedor deve atribuir um contacto de conta identificado, responsável pela relação contínua consigo — e não apenas pela implementação. Cumprir este requisito significa que as equipas empresariais têm um parceiro proativo que acompanha a utilização, assinala problemas e defende internamente as suas necessidades.
• Integração de telefonia e CTI: A plataforma deve integrar-se com os sistemas telefónicos do centro de contacto, permitindo janelas de contexto em chamadas recebidas, a criação automática de pedidos a partir dos registos de chamadas e o registo de chamadas associado ao histórico de pedidos do cliente. Cumprir este requisito significa que as interações por voz são incluídas no mesmo registo de suporte que todos os outros canais.

Requisitos especiais

• Gestão de serviços no terreno e de despacho para o local: Para as empresas que enviam técnicos às instalações dos clientes, a plataforma deve suportar o agendamento, a atribuição de trabalhos e o acompanhamento do estado dos trabalhadores no terreno — e não apenas filas de suporte digital. Cumprir este requisito significa que as ordens de trabalho no local e as filas de pedidos remotos ficam no mesmo sistema.
• Integrações com plataformas de comércio eletrónico: A plataforma deve ligar-se a sistemas de comércio eletrónico como Shopify, Magento ou WooCommerce, incorporando os dados das encomendas, o estado dos envios e o histórico de compras diretamente na vista do pedido. Cumprir este requisito significa que os agentes podem resolver problemas relacionados com encomendas sem alternar entre o serviço de apoio e a plataforma de comércio.
• Residência dos dados e opções de alojamento regional: O fornecedor deve oferecer a possibilidade de armazenar os seus dados numa região geográfica específica — como a UE, os EUA ou a APAC — sem que sejam replicados noutras jurisdições. Cumprir este requisito significa que pode cumprir as leis locais de soberania dos dados e as políticas internas de governação de dados.
• Serviços profissionais para desenvolvimento personalizado: O fornecedor deve disponibilizar uma equipa interna de serviços capaz de criar fluxos de trabalho, integrações ou configurações personalizadas que vão além do produto padrão. Cumprir este requisito significa que as organizações com necessidades não convencionais não têm de depender inteiramente de programadores externos para fazer a plataforma funcionar.
• Análise da adoção e da utilização para administradores: A plataforma deve apresentar dados de utilização por agente e por equipa — frequência de início de sessão, utilização de funcionalidades e padrões de tratamento de pedidos — que os administradores possam usar para identificar lacunas na adoção. Cumprir este requisito significa que pode detetar quais os agentes que não estão a utilizar funcionalidades essenciais e intervir com formação direcionada antes de isso afetar a qualidade do serviço.

Requisitos sobrevalorizados

Algumas funcionalidades de serviço de apoio parecem impressionantes nas demonstrações, mas acrescentam pouco valor após a implementação. Eu daria prioridade a fluxos de trabalho fiáveis e a resultados de serviço mensuráveis, tratando depois estas vantagens com cautela:

• Chatbots de IA: Estas ferramentas respondem a perguntas de rotina, classificam a intenção e sugerem conteúdos da base de conhecimento. Muitas vezes desiludem quando os artigos estão desatualizados, as perguntas dos clientes precisam de contexto ou os agentes têm de corrigir respostas imprecisas.

• Caixas de entrada omnicanal: A cobertura omnicanal completa pode ser desnecessária se os seus clientes utilizarem apenas alguns canais de suporte. Dê prioridade a um suporte fiável nos canais que os seus clientes realmente utilizam, em vez de pagar por uma cobertura abrangente de que não necessitará.

• Aplicações móveis nativas: As aplicações móveis nativas são mais importantes para as equipas que tratam regularmente de pedidos longe de uma secretária. Acrescentam menos valor quando os agentes gerem sobretudo casos complexos através de integrações de ambiente de trabalho, históricos detalhados e vários separadores do navegador.

• Gamificação dos agentes: A gamificação acrescenta pontos, distintivos, classificações ou concursos ao tratamento de pedidos. Estas medidas podem recompensar o volume de pedidos em detrimento de resoluções ponderadas, especialmente quando os relatórios de desempenho já acompanham métricas de qualidade.

• Personalização ilimitada: Esta promessa significa normalmente um controlo amplo sobre campos, disposições, automatizações e fluxos de trabalho. Uma configuração excessiva pode criar processos confusos, aumentar o trabalho de manutenção e dificultar futuras migrações.

• Suporte em direto 24 horas por dia, 7 dias por semana: A assistência permanente proporciona acesso a representantes do fornecedor fora do horário normal de funcionamento. É sobrevalorizada quando os problemas noturnos recebem respostas predefinidas, uma escalada lenta ou suporte de equipas sem acesso técnico.

Etapas para personalizar a lista de verificação dos requisitos do seu software de suporte

Utilize estas etapas para alinhar a sua lista de verificação com o seu modelo de suporte, as necessidades dos clientes e o seu ambiente tecnológico:

1. Defina os objetivos empresariais e o âmbito do projeto: Decida se precisa de um serviço de suporte destinado aos clientes, de uma central de serviços interna de TI ou de ambos. A gestão de serviços de TI (ITSM) também pode exigir gestão de ativos, gestão de alterações, catálogos de serviços e fluxos de trabalho alinhados com o ITIL. Documente os seus utilizadores, canais, SLA, necessidades de elaboração de relatórios e fluxos de trabalho principais antes de comparar ferramentas.

2. Recolha contributos de todas as partes interessadas: Pergunte aos agentes, responsáveis de equipa, administradores, equipas de TI, segurança, finanças e sucesso do cliente de que precisam da plataforma. Registe os requisitos relativos à gestão de pedidos, encaminhamento, gestão do conhecimento, integrações, permissões, elaboração de relatórios e autosserviço dos clientes.

3. Classifique e estabeleça prioridades para os requisitos: Classifique cada requisito como absolutamente indispensável, expectativa padrão ou funcionalidade opcional. Dê maior prioridade às capacidades relacionadas com a prestação de serviços, como a atribuição de pedidos, o acompanhamento de SLA, o histórico do cliente, as regras de escalamento e a elaboração fiável de relatórios.

4. Avalie as necessidades de integração, escalabilidade e segurança: Enumere os sistemas aos quais o serviço de suporte tem de se ligar, incluindo CRM, comércio eletrónico, correio eletrónico, telefonia, identidade e ferramentas de colaboração. Confirme o acesso à API, as expectativas de desempenho, a encriptação, o controlo de acesso baseado em funções (RBAC), os registos de auditoria, as necessidades de conformidade e os requisitos de alojamento regional.

5. Calcule o custo total de propriedade & o ROI: Compare as taxas de subscrição com os custos de implementação, migração, formação, integração, personalização, suporte e administração futura. Calcule o ROI utilizando resultados mensuráveis, como a redução do número de pedidos pendentes, uma resolução mais rápida, uma utilização melhorada do autosserviço e custos de tratamento mais baixos.

Principais partes interessadas na seleção de software de suporte

Inclua vários grupos empresariais ao recolher os requisitos do software de suporte. Cada equipa identifica riscos, fluxos de trabalho e necessidades dos clientes diferentes, pelo que os seus contributos ajudam a evitar lacunas durante a avaliação. O seu envolvimento também promove a responsabilidade partilhada pela seleção e implementação finais.

Utilize esta tabela para identificar quem deve contribuir e o que cada parte interessada deve avaliar:

A sua lista de verificação de requisitos é apenas uma parte do processo

Depois de definir os seus requisitos, saber como escolher software de suporte fornece-lhe o enquadramento para avaliar fornecedores, a estrutura do caso de negócio e as etapas de implementação necessárias para transformar esta lista de verificação numa decisão final segura.