CRM 2015/2016 – Plugin Trace Logs

Pessoal,

Desde o Update 1 do CRM 2015, podemos observar de forma centralizada (em um único local) os logs dos plugins ou custom workflows que temos registrados no Dynamics CRM. Isso nos auxiliará bastante em relação a visualização de erros e execuções.

O log apresenta um conteúdo detalhado do plugin/custom workflow, com informações do Nome do Plugin, Mensagem, Entidade Primária, Valores de Configuração (seguros ou não), Hora da Execução, Tempo de Execução, Detalhamento do Erro, entre outros!

plugintracelog_1

plugintracelog_2

 

O recurso não vem ativado por padrão, assim devemos, primeiramente ativá-lo, navegue em Configurações > Administração > Configurações do Sistema > Aba Customizações > Opção Plugin e Workflow Customizado Trace de Atividade (Plug-in and Custom Workflow Activity Trace), selecione as opções “Todos” ou “Exceções“:

plugintracelog_3

 

Caso tenha selecionado a opção Exceções, todas as exceções de plugins/custom worflows serão logadas automaticamente! Para acessá-las navegue em Configurações > Log de Execução de Plugins (Plug-in Trace Logs)

Caso tenha selecionado Todos, todas as execuções de plugins/custom workflows serão logados! Vale lembrar que para que todos os plugins e custom workflows executados sejam apresentados na listagem, teremos que incluir informações de Trace na codificação, como no exemplo abaixo:

public void Execute(IServiceProvider serviceProvider)
{
    ITracingService tracer = (ITracingService)serviceProvider.GetService(typeof(ITracingService));
    IPluginExecutionContext context = (IPluginExecutionContext)serviceProvider.GetService(typeof(IPluginExecutionContext));
    IOrganizationServiceFactory factory = (IOrganizationServiceFactory)serviceProvider.GetService(typeof(IOrganizationServiceFactory));
    IOrganizationService service = factory.CreateOrganizationService(context.UserId);

    try
    {
        Entity entity = (Entity)context.InputParameters["Target"];

        if (tracer == null)
            throw new InvalidPluginExecutionException("Failed to retrieve the tracing service.");


        // The InputParameters collection contains all the data passed in the message request.
        if (context.InputParameters.Contains("Target") && context.InputParameters["Target"] is Entity)
        {
            // Verify that the target entity represents an account.
            // If not, this plug-in was not registered correctly.
            if (entity.LogicalName != "account")
                return;

            tracer.Trace("Tracing started...");

            //Query Project Link Settings
            QueryExpression query = new QueryExpression("account");
            ColumnSet cols = new ColumnSet();
            cols.AllColumns = true;
            query.ColumnSet = cols;

            EntityCollection settings = service.RetrieveMultiple(query);
            foreach (Entity ent in settings.Entities)
            {
                tracer.Trace("account name " + ent.Attributes["name"]);
            }

            tracer.Trace("The Plugin tracing has finished...");
        }
    }
    catch (Exception e)
    {
        throw new InvalidPluginExecutionException(e.Message);
    }
}

Vejam que no código acima, eu faço uso do objeto ITracingService, que de acordo com as funções do código podemos inserir pontos de trace “tracer.Trace(‘MENSAGEM’)”. Podemos utilizar como boa prática a implementação do trace para facilitar a resolução de bugs nos plugins/custom workflows!

Para maiores informações consulte:

Debug a plug-In

CRM2011: Useful ITracingService addiion when creating plugin assemblies

[]’s,

Tiago Cardoso

Publicado em Dynamics CRM | Marcado com , | Deixe um comentário

CRM – Modelos de Direitos (Entitlement Templates)

Pessoal,

Este será o último post da série sobre SLA’s! Modelos de Direitos (Modelos de Termos de Suporte). Para acessar os posts anteriores:

Acredito que este post é apenas mero informativo, pois a base de tudo esta contida no post de Direitos (Entitlements). Mas podemos tenho um pouco mais de informações para compartilhar!

Modelos de Direitos são templates que podemos reutilizá-los quando estamos criando um novo Direito, uma série de informações serão herdadas, podemos mantê-las, ou alterá-las, caso necessário.

Os atributos são basicamente os mesmos dos Direitos, para criar um novo Modelo, navegue em Configurações > Gerenciamento de Serviços > Modelos de Direito > Novo:

modelos_direitos_1

 

Um explicação sobre os atributos do formulário:

  • Nome do Modelo de Direito – (Autoexplicativo);
  • Data de Início – Data em que estrará em vigor o Direito que utilizou este Modelo como base (vale lembrar que caso seja informada uma data superior a atual, não será possível ativar o Direito, pois ele irá esperar até a data de início informada. O mesmo se aplica para definir o Direito como “Padrão”;
  • Data de Término – Data em que o Direito que utilizou este Modelo como base não valerá mais;
  • Restrito com base nos termos do direito – Por padrão possui o valor “Não”, isto indica que será possível criar novas ocorrências mesmo após o valor do atributo “Termos Restantes” possui o valor “0”. Caso seja, selecionado “Sim”, não será possível criar novas ocorrências;
  • SLA – Informe o SLA que deseja ser aplicado para o Direito que utilizou este Modelo como base (lembre-se este SLA será aplicado em todos os Direitos que utilizarem este Modelo, podemos trocar, mas ele será herdado);
  • Descrição – (Autoexplicativo);
  • Tipo de Alocação – Possui dois valores “Número de Ocorrências” e “Número de Horas”, definem qual o critério de quantificação de uso do Direito que utilizou este Modelo como base:
  • Número de Ocorrências – A contabilização do termo de suporte será a quantidade de ocorrências que forem criadas;
  • Número de Horas – A contabilização do termo de suporte será a quantidade de horas utilizadas para solucionar as ocorrências;
  • Redução Restante em – Possui dois valores “Resolução de Ocorrência” e “Criação de Ocorrência”, este atributo é utilizado para realizar a contabilização (redução) da quantidade de “Termos Restantes”, isto será aplicado no Direito que utilizou este Modelo como base:
  • Resolução de Ocorrência – Reduzirá o contador de Termos Restantes quando a ocorrência for resolvida;
  • Criação de Ocorrência – Reduzirá o contato de Termos Restantes quando uma ocorrência for criada;
  • Total de Termos – Quantidade de termos de suporte (Direitos) que poderá ser utilizada para o Direito que utilizou este Modelo como base;

Observem que não temos o atributo Cliente, pois por tratar-se de um modelo, não devemos definir um cliente específico, e sim criarmos algo genérico que possa ser reaproveitado! Após salvar o Modelo, podemos incluir informações na entidades relacionadas “Canal de Direito (Atendimento)“ e “Produtos”:

modelos_direitos_2

Bastante simples e intuitivo, basta inserir os canais de direito e produtos que este modelo suportará:

  • Canal de Direito – Devemos informar quais canais o Direito que utilizou este Modelo como base irá considerar, no exemplo acima, informei “Email”, “Facebook”, “Telefone” e “Twitter”. Estes termos irão ser avaliados para reduzir os valores do atributo Termos Restantes (existente apenas no formulário de Direitos).
    Não é possível termos na somatória dos canais (Total de Termos) um valor superior ao do valor do atributo “Termos Restantes”;
  • Produtos – Podemos informar quais produtos o Direito que utilizou este Modelo como base irá considerar, no exemplo acima, apenas o produto “Lync Online” irá ser avaliado para reduzir os valores do atributo Termos Restantes (existente apenas no formulário de Direito). Caso nenhum produto seja informado, todos os produtos serão considerados!

Pronto Modelo de Direito criado! Agora podemos criar Direito utilizando como base este Modelo, para isso navegue em Configurações > Gerenciamento de Serviços > Direitos > Novo > Pelo Modelo:

modelos_direitos_3

 

modelos_direitos_4

modelos_direitos_5

Vejam que não foram preenchidos os atributos Nome e Cliente Principal, pois eles precisam ser informados por nós!

Em relação aos relacionamentos Canal de Direito e Produtos eles não foram ainda preenchidos porque não salvamos o Direito, assim que for salvo, as informações serão herdadas do Modelo base:

modelos_direitos_6

Podemos a qualquer momento realizar as mudanças que forem necessárias, alterar prazos, SLA, tipo de alocação, redução restante, total de termos, canais de direito ou produtos.

A ideia realmente é nos poupar trabalho, imagine uma base de clientes muito grande, que necessitam de um direito configurado, podemos criar modelos seguindo alguma diretriz, assim quando, fomos criar os direitos não teremos muito trabalho adicional! Codificação também poderá ser uma outra forma para realizar uma maior automação na criação dos direitos, porém os modelos nos ajudam em 90% dos casos!

Este e post e esta série de posts sobre SLA termina por aqui. Espero que tenha comentado cada função com um bom nível de aprofundamento e que seja útil para você!

Para maiores detalhes, vide o artigo oficial:

Definir qualificações rapidamente com modelos

[]’s,

Tiago Cardoso

Publicado em Dynamics CRM | Marcado com , , , , | 2 Comentários

CRM 2015/2016 – Direitos (Entitlement)

Pessoal,

Em meu último post sobre SLA’s, na parte final, inclui uma nota que para finalizar o assunto SLA’s eu precisaria falar sobre Direitos (sim, um péssimo nome escolhido na tradução, na realidade estamos falando de Termos de Suporte). Mas onde que existe a relação mencionada?! O que são exatamente os Modelos de Direito e Direitos?! Bem, isso será o assunto dos próximos dois posts. Direitos (este post!) e Modelos de Direitos (próximo post).

Bom, vamos a respostas das perguntas acima…

No CRM Online Spring ’14 Update e no CRM 2013 Service Pack 1 (OnPremises) foram adicionadas as funcionalidades de Direitos e Modelos de Direitos:

  • Direitos – Permitem que seja configurado os termos de serviço/suporte de um cliente. Com ele conseguimos individualizar o atendimento ao cliente, ou seja, o cliente irá receber uma atenção especial que foi previamente determinada e podemos verificar o andamento dos atendimentos (nível de serviço) de acordo com as configurações estabelecidas.
    Os direitos não devem ser confundidos com os Contratos, pois contratos possuem informações financeiras não os termos de suporte.
    Os direitos podem ser relacionados a um SLA especifico, permitindo que tenhamos SLA personalizados para o cliente, canal de atendimento, produto ou contato. Em resumo, conseguimos controlar o suporte ao cliente em níveis altamente detalhados!
  • Modelos de Direitos – São templates que podem ser utilizados no momento em que vamos criar um novo Direito (por agora abstraia esta ideia!);

Com a explicação acima, é hora de irmos ao CRM!

Navegue em Configurações > Gerenciamento de Serviços > Direitos > Novo (Podemos criar um Direito utilizando um Modelo, mas iremos falar de Modelo no próximo post!):

direitos_1

Informações sobre os campos e como preenche-los:

  • Nome – (Autoexplicativo);
  • Cliente Principal – Devemos informar ao qual Cliente (Conta ou Contato) que este termo de suporte será aplicado;
  • Data de Início – Data em que estrará em vigor o termo de suporte (vale lembrar que caso seja informada uma data superior a atual, não será possível ativar o Direito, pois ele irá esperar até a data de início informada. O mesmo se aplica para definir o Direito como “Padrão”;
  • Data de Término – Data em que o termo de suporte não valerá mais;
  • Restrito com base nos termos do direito – Por padrão possui o valor “Não”, isto indica que será possível criar novas ocorrências mesmo após o valor do atributo “Termos Restantes” possui o valor “0”. Caso seja, selecionado “Sim”, não será possível criar novas ocorrências;
  • SLA – Informe o SLA que deseja ser aplicado para este termo de suporte;
  • Descrição – (Autoexplicativo);
  • É Padrão – Só poderá ser alterado via barra de comando após a gravação do termo de suporte;
  • Tipo de Alocação – Possui dois valores “Número de Ocorrências” e “Número de Horas”, definem qual o critério de quantificação de uso dos termos de suporte:
    • Número de Ocorrências – A contabilização do termo de suporte será a quantidade de ocorrências que forem criadas;
    • Número de Horas – A contabilização do termo de suporte será a quantidade de horas utilizadas para solucionar as ocorrências;
  • Redução Restante em – Possui dois valores “Resolução de Ocorrência” e “Criação de Ocorrência”, este atributo é utilizado para realizar a contabilização (redução) da quantidade de “Termos Restantes”:
    • Resolução de Ocorrência – Reduzirá o contador de Termos Restantes quando a ocorrência for resolvida;
    • Criação de Ocorrência – Reduzirá o contato de Termos Restantes quando uma ocorrência for criada;
  • Total de Termos – Quantidade de termos de suporte que poderá ser utilizada para este Direito nos prazos determinados;
  • Termos Restantes – Contabiliza automaticamente a quantidade de termos já utilizada;

Após salvar o Direito, podemos incluir informações na entidades relacionadas “Canal de Direito (Atendimento)“, “Produtos” e “Contatos“:

direitos_2

Um pouco de informação sobre cada relacionamento:

  • Canal de Direito – Devemos informar quais canais o termo de suporte irá considerar, no exemplo acima, apenas “Twitter”, “Facebook” e “Telefone” irão ser avaliados para reduzir os valores do atributo Termos Restantes. Não é possível termos na somatória dos canais (Total de Termos) um valor superior ao do valor do atributo “Termos Restantes”;
  • Produtos – Podemos informar quais produtos o termo de suporte irá considerar, no exemplo acima, apenas o produto “Lync Online” irá ser avaliado para reduzir os valores do atributo Termos Restantes. Caso nenhum produto seja informado, todos os produtos serão considerados!
  • Contatos – Quais Contatos do nosso Cliente que ao criarem uma ocorrência irão contabilizar (reduzir) os valores do atributo Termos Restantes;

Acredito que a parte mais importante deste post…


Se o Direito não for definido como “Padrão”, temos que adicionar manualmente na ocorrência qual será o Direito que desejamos aplicar. Creio que está ação deva ser evoluída nas próximas atualizações do CRM, pois seria interessante por exemplo, apenas informar um produto, canal ou contato na ocorrência, e o CRM indicar qual é o Direito que está sendo utilizado e associá-lo à Ocorrência. Assim, recomendo a utilização de Direitos definidos como “Padrão” ou a codificação de uma lógica para “auto selecionar” o Direito à ser utilizado de acordo com as informações da ocorrência.


A última etapa, será Ativar e Definir como Padrão (lembre-se da descrição acima, caso não possui uma codificação para selecionar automaticamente qual o direito que está sendo utilizado, recomendo que todos os direitos sejam definidos como “Padrão”. Nota: Apenas um direito padrão por cliente é suportado!):

direitos_3

Bom, com o direito configurado, ativado e definido como padrão, vamos criarmos uma nova ocorrência para o cliente “Adventure Works”:

direitos_4

Notem que em nenhum momento eu selecionei o Direito que desejo que seja utilizado, pois como defini como Padrão, ao salvar a ocorrência automaticamente será adicionado o direito “Direito Adventure Works”, que foi criado anteriormente. Neste caso, bastaria apenas selecionar o cliente “Adventure Works” que tudo funcionaria bem, coloquei também a Origem “Facebook” para vermos depois que nosso contador deste canal será reduzido (decrementado).

Salve a ocorrência e veja que o direito “Direito Adventure Works” será relacionado automaticamente:
direitos_5

Quando observamos os Detalhes do SLA, vemos que o SLA que está sendo considerado foi o definido no momento da criação do Direito, assim o CRM usará este SLA na ocorrência:
direitos_6

Ao Resolver ou Cancelar a Ocorrência, nosso direito reduzirá automaticamente seus contadores, pois temos uma Ocorrência sendo fechada, este foi o gatilho de redução que configuramos no direito:
direitos_7
Após concluir a ocorrência, podemos navegar até o direito que estamos trabalhando. Veremos que os contadores foram reduzidos, tanto os “Termos Restantes” quando o “Canal Facebook”, não possuem mais a quantidade definida originalmente:

direitos_8

 

É isso, criamos um direito e o utilizamos quando criamos uma ocorrência para o cliente alvo do direito! Não é tão complicado quando parecia…

Como eu disse anteriormente, acredito que este recurso ainda será melhor explorado pela Microsoft, mas da forma que já se encontra, podemos fazer inúmeras variações!

Para maiores informações, consulte o material oficial:

Criar um direito para definir os termos de suporte para um cliente
Criar e gerenciar uma ocorrência

O último post desta série sobre SLA’s será sobre os Modelos de Direitos!

[]’s,

Tiago Cardoso

Publicado em Dynamics CRM | Marcado com , , , | Deixe um comentário

Os números de 2015

Os duendes de estatísticas do WordPress.com prepararam um relatório para o ano de 2015 deste blog.

Clique aqui para ver o relatório completo

Publicado em Dynamics CRM | Deixe um comentário

CRM 2015/2016 – Utilizando Pausa nos SLA’s

Pessoal,

No post anterior, criamos um SLA Padrão, bem como seus Itens de SLA.

Agora chegou o momento de usarmos a funcionalidade de Pausa.

A partir do CRM 2015, temos a possibilidade pausar uma ocorrência, o administrador do CRM, pode definir quais valores serão aceitos como “pausa”. Os valores apresentados levam em relação o atributo Razão do Status (statuscode) da entidade Ocorrência, quando o Status (statecode) possui o valor “Ativo”, ou seja, apenas ocorrências no Status “Ativos” poderão ser pausadas. O fato importante desta abordagem é a possibilidade de criarmos novos valores no atributo Razão do Status, de acordo com a necessidade da área de negócios da companhia.

Para selecionar os valores da Razão do Status que poderão ser pausar a ocorrência, precisamos navegar em Configurações > Gerenciamento de Serviços > Contratos de Nível de Serviço > Parâmetros de Configuração de Serviço:

SLA_pausa_1

Vale lembrar que faz sentido termos um ou mais valores não selecionados como válidos para a Pausa, pois temos que ter valores que o tempo deve ser contabilizado. No exemplo acima, deixei o valor “Em Andamento” não selecionado, ou seja, toda vez que a ocorrência estiver com este valor o tempo será levado em consideração, nos demais valores os contadores de SLA será pausados!

Para avaliarmos as configurações que fizemos anteriormente, precisamos criar uma ocorrência. Ao salvar automaticamente o valor do atributo Razão do Status será “Em Andamento” e o tempo será contabilizado:

SLA_pausa_5

O responsável pela ocorrência pode julgar a necessidade de outras informações que o SLA não deve ser contabilizado. Este processo pode ser automatizado, por exemplo, um workflow verifica se determinados campos da ocorrência foram previamente preenchidos, caso não, altera o valor do atributo Razão do Status. Com a edição da Razão do Status, para o valor “Aguardando Detalhes” (por exemplo). Ao salvar, teremos o resultado abaixo:

SLA_pausa_3

Após localizar as informações faltantes, a Razão do Status poderá voltar para o valor “Em Andamento”, contabilizando assim o tempos de SLA novamente!
SLA_pausa_4
SLA_pausa_6Vale lembrar a pausa sempre respeitará todas as configurações de dias/horários comerciais e feriados cadastrados no CRM. São uma combinação de fatores, pois será considerado o horário de trabalho do responsável pela ocorrência, o horário comercial definido no SLA e os feriados cadastrados no sistema. Assim, acredito que o trabalho mais dificil e complexo nós não conseguimos visualizar, mas ele é realizado internamente pelo CRM, nosso papel é de apenas configurar as variáveis e deixar o CRM controlar os prazos!

Acredito que ainda falte mais um post à respeito de SLA’s, que seria utilizar SLA’s relacionando aos Direitos (Entitlements). Desta forma, chegaremos ao “suprassumo” do atendimento ao Cliente, pois os Direitos serão direcionados a um cliente específico!

Este post termina aqui!

[]’s,

Tiago Cardoso

 

Publicado em Dynamics CRM | Marcado com , , | Deixe um comentário

CRM 2015/2016 – Criando SLA’s

Pessoal,

Após meu post anterior sobre o conceito de SLA’s e detalhes de como utilizá-los no CRM. Este novo post dedica-se a apresentar um exemplo prático de como criar um SLA!

Bom vamos à prática!

Precisamos navegar em Configurações > Gerenciamento de Serviços > Contratos de Nível de Serviço > Clicar em Novo e preencher o formulário:

SLA_1

Preencha o formulário de SLA (maiores detalhes no post anterior).

Após preencher o formulário é hora de Salvar e criar um Item de SLA:

SLA_2

Devemos ter em mente quais serão nossos indicadores? Quais atributos serão necessários para realizar este item de SLA (seção “Aplicável Quando”)? Quais atributos serão os responsáveis por estabelecer o “Critério de Sucesso” do SLA? Como serão tratadas as falhas e avisos? Qual os tempos que devem ser considerados como “deadlines”?

Após a obtenção das respostas acima, chegou a hora de criar nosso item de SLA!

Minha ideia foi de criar um SLA Padrão, então não vou utilizar todas funcionalidades disponíveis. Quero apenas verificar se primeira resposta dada ao cliente (* vide abaixo maiores detalhes) respeitou os prazos de SLA (veja que os valores de tempo foram modificados para facilitar o entendimento deste post):

SLA_8SLA_9SLA_10

* O atributo Primeira Resposta Enviada (firstresponsesent) não é um atributo automático, o CRM não o preenche automaticamente. Cabe uma definição do que será considerado o primeiro contato, após isso, uma pequena customização deve ser feita para marcar o atributo como “Sim” (primeira resposta enviada = sim).

Para visualizar todos os indicadores possíveis, devemos criar outro Item de SLA, desta vez para contabilizar o tempo máximo de resolução da ocorrência. Será muito parecido ao anterior, vejam:

SLA_11

SLA_12 SLA_13

Pronto! Itens de SLA e SLA criados! Devemos agora “Ativar” e “Definir como Padrão” (pois este SLA será o SLA genérico):

SLA_14

Agora, toda vez que uma ocorrência for criada automaticamente o SLA iniciará! Para visualizar expanda a guia Detalhes do SLA Avançado:

SLA_15

Quando finalizamos a ocorrência em tempo hábil, teremos o indicador “Resolver em” com o valor “Com êxito”. (Lembre-se de recarregar o formulário após Resolver a Ocorrência):

SLA_18

Quando o tempo atingir seu limite, será criado automaticamente os registros de Tarefa que definimos anteriormente:

SLA_16

SLA_17

 

Bom terminamos este post aqui! Como disse no post anterior, ainda temos muito para trabalhar, em breve virão mais posts sobre SLA!

[]’s,

Tiago Cardoso

Publicado em Dynamics CRM | Marcado com , , | Deixe um comentário

CRM 2015/2016 – Entendendo os SLA’s

Pessoal,

Deste o CRM 2013 Spring Release, podemos trabalhar com os Contratos de Nível de Serviço (SLA’s – Service Level Agreements).

Para quem não está familiarizado com o tema, um breve resumo. SLA’s são contratos de serviço que devem ser obedecidos para atingir um nível de serviço previamente estabelecido ou combinado. No caso do Dynamics CRM, usamos na entidade Ocorrência para sempre solucionarmos os incidentes seguindo uma métrica previamente determinada, que basicamente inclui o tempo como principal fator de satisfação (podemos usar o tempo combinado com outros indicadores, mas cada necessidade é um caso à parte). Os Indicadores de Desempenho (KPI’s – Key Performance Indicators) são os pontos determinantes para sabermos se as ocorrências estão sendo atendidas de acordo com o esperado.

Com o entendimento e a ideia de uso dos SLA’s e KPI’s, vamos aos detalhes…

Quando os SLA’s foram introduzidos no CRM 2013, havia apenas o tipo “SLA Padrão“, com a chegada do CRM 2015 ganhamos o tipo “SLA Avançado/Melhorado“. O que cada um é capaz de fazer e quando utiliza-los?

  • SLA Avançado/Melhorado

– Temos a possibilidade de pausar uma ocorrência quando ele estiver com status de suspensão, todos os contadores ficam pausados, até que a ocorrência seja reativada. Neste momento todos os indicadores são recalculados levando em consideração a data atual e inicia-se a contagem novamente;

– Podemos configurar ações de sucesso do SLA, ou seja, quando os limites não foram atingidos, podemos enviar a informação para sistemas externos ou no próprio CRM;

– Podemos rastrear o status e tempo do SLA no próprio formulário da ocorrência, tudo de forma nativa, todas as informações são guardadas em uma entidade

  • SLA Padrão

– Conforme eu falei anteriormente o SLA Padrão foi o primeiro recurso fornecido de forma nativa para o CRM, ele possui certas limitações. Podemos fazer todas as suas funções utilizando o SLA Avançado/Melhorado. Deste modo, não é aconselhável criar um SLA Padrão;

Além dos tipos de SLA, temos a possibilidade de criarmos “SLA dedicados a um específico Cliente”, que no Dynamics CRM são chamados de Direitos (Entitlements), este será o assunto de um post posterior a este!

Programaticamente os SLA’s nada mais são do que workflows, o CRM cria um workflow para cada item de SLA, deste modo, consegui verificar se os critérios de sucesso, falha e aviso foram atingidos.

Para visualizarmos os Contratos de Serviço precisamos navegar em Configurações > Gerenciamento de Serviços > Contratos de Nível de Serviço.

SLA_1

Um pouco de informação sobre os atributos do formulário:

  • Nome – É auto explicável! :)
  • Aplicável de – É o atributo do tipo DateTime do formulário que será observado e comparado
  • Horário Comercial – Podemos carregar um registro da entidade Calendário, pois cada SLA pode ter um horário diferente para o seu tratamento
  • Tipo de SLA – Existem as opções “Padrão” ou “Avançado”, que foram detalhadas anteriormente, neste exemplo estamos utilizando o SLA Avançado
  • Permitir Pausa e Retomada – Caso o tipo do SLA seja Avançado podemos selecionar “Permitir”, caso seja Padrão só poderemos selecionar “Não Permitir”

Depois que preenchemos o formulário e salvamos, podemos criar os Itens de SLA (Detalhes de SLA).

Esta etapa é a mais importante e deve ser bem compreendida para o devido uso dos Itens de SLA:

  • Nome do Item de SLA, selecione qual KPI de SLA o item de SLA irá ser computado (podem ser selecionados os atributos Primeira Resposta por KPI ou Resolver por KPI).
  • Aplicável Quando – Nesta seção, deve ser configurado qual a condição que o SLA será aplicado, ou seja, qual o “universo” de ocorrências ou de seus registros relacionados que será o alvo deste Item de SLA.

Ainda um pouco confuso?! Então ai vai um exemplo:

Imagine que este Item de SLA só deverá funcionar para ocorrências em que o Cliente possua uma Receita Anual igual ou superior a 100.000,00 e que apenas ocorrências do Tipo “Problema”. Assim restringimos que apenas este tipo de combinação seja utilize este Item de SLA:

SLA_4

  • Critério de Sucesso – Este item é mais simples de ser compreendido. Devemos selecionar qual o critério que será considerado o de sucesso. Devemos informar o que será observado para dizer que o SLA foi atendido ou não. Geralmente observamos algum atributo da entidade ocorrência, mas também podemos observar os registros relacionados à ocorrência.

Um exemplo seria, verificar se a flag “Primeira Resposta Enviada” possui o valor “Sim”, isto indica que algum agente do CRM realizou alguma ação na ocorrência. Mas podemos também verificar se o atributo Contato da ocorrência foi preenchido (algum regra de negócio pode exigir que em determinada etapa de processo da ocorrência que este atributo seja preenchido):

SLA_5

  • Ações com Êxito – Como eu disse anteriormente, podemos criar ações mesmo quando o SLA não foi atingido (o que é o esperado, certo?! rsrsrs). Imagine que o gestor da equipe de tratamento de incidentes gostaria de saber toda vez que um chamado não atingiu os limites do SLA?! Claro que da forma que escrevi seria uma grande redundância, mas pense em caso bem específicos de SLAs que tenham um grande relevância para a companhia… Nestes casos, seria interessante alertar de alguma forma o gestor! Podemos realizar as seguintes ações:

SLA_6

  • Falha do Item do SLA – Devemos incluir qual o tempo máximo para que o Critério de Sucesso seja atendido, assim que a ocorrência exceder este período, será considerado que o SLA não foi cumprido (podemos inserir valores que a listagem não possui. Por exemplo: 20 minutos):

SLA_7

  • Ações da Falha – Quais ações devem ser executadas quando os Critérios de Sucesso não foram cumpridos no prazo determinado. Podemos realizar as mesmas ações do item Ações com Êxito: Enviar Emails, Criar/Atualizar e Atribuir Registros e Alterar Status;
  • Aviso do Item do SLA – Devemos incluir em que terminado tempo para alertar sobre a possibilidade de não cumprir o SLA, assim que a ocorrência atingir este período, significa que o SLA pode não ser cumprido a tempo. Devemos seguir a mesma ideia do item Falha do Item SLA;
  • Ações de Aviso – Quais ações de aviso devem ser executadas quando os Critérios de Sucesso ainda não foram cumpridos e o prazo já está se esgotando. Podemos realizar as mesmas ações do item Ações com Êxito: Enviar Emails, Criar/Atualizar e Atribuir Registros e Alterar Status;

Após o preenchimento e termos salvo o Item de SLA, podemos criar mais itens, “Ativar” (é obrigatório para que o SLA seja localizado e executado automaticamente pelo “Core” do CRM) e/ou “Definir como Padrão” (podemos definir um SLA que será o padrão, isto é uma boa funcionalidade quando tempo por exemplo uma ocorrência que não atingiu os critérios necessários pelos outros SLA’s do sistema, assim o SLA Padrão irá ser o utilizado):

SLA_14

Com o SLA ativado, todas vez que uma ocorrência for criada será automaticamente executado pelo CRM. Para visualizar expanda a guia Detalhes do SLA Avançado (não confundir com a seção “SLA Aplicável”, pois esta seção contém informações dos SLA’s do tipo Padrão):

SLA_15

Certamente o tema SLA não foi finalizado neste post, acredito que eu possa abordar em outros posts:

  • Um exemplo prático de SLA Avançado/Melhorado;
  • Como utilizar a funcionalidade de Pausa;
  • Utilizar Direitos (Entitlements) e SLA’s;

Para maiores informações consulte os materiais:

Definir os acordos de nível de serviço (SLAs)
Microsoft Dynamics CRM 2013 Spring ’14 Application New Features – Service Level Agreements
Microsoft Dynamics CRM 2015 Enhanced SLA New Features

[]’s,

Tiago Cardoso

Publicado em Dynamics CRM | Marcado com , , | Deixe um comentário