VoIP<\/a>, este sistema pode facilmente gerenciar todas as chamadas, exibindo os principais detalhes. Isto pode ser inestim\u00e1vel para organiza\u00e7\u00f5es com alto volume de chamadas que precisam de informa\u00e7\u00f5es atualizadas.<\/p>\nIntegra\u00e7\u00e3o de redes sociais<\/h4>\n
A menos que voc\u00ea viva em uma caverna, voc\u00ea est\u00e1 bem ciente da import\u00e2ncia e da ubiq\u00fcidade das redes sociais nos dias de hoje. \u00c0s vezes negligenciada pelas organiza\u00e7\u00f5es, a integra\u00e7\u00e3o de suas redes sociais com seu CRM permite uma gest\u00e3o mais eficaz da imagem p\u00fablica da empresa e de seu engajamento.<\/p>\n
Fluxos de trabalho espec\u00edficos do setor<\/h4>\n
Cada setor empresarial tem suas pr\u00f3prias necessidades, e \u00e9 por isso que muitos sistemas de CRM s\u00e3o especializados em um \u00fanico setor, por exemplo, Guestware para o setor hoteleiro ou Contactually para o setor imobili\u00e1rio. Estes sistemas oferecer\u00e3o funcionalidades espec\u00edficas para cada setor (gest\u00e3o de reservas para CRM hoteleiro), mas tamb\u00e9m integra\u00e7\u00e3o com seu software emblem\u00e1tico (Zillow para im\u00f3veis).<\/p>\n
<\/span><\/span><\/span>Deve-ter e \u00e9 bom ter<\/span><\/span><\/span><\/h3>\n![](\"\/wp-content\/uploads\/2021\/11\/Moscow_Matrix.png\")
<\/p>\n
\n
<\/i>A defini\u00e7\u00e3o de Salesdorado<\/span><\/p>\nO m\u00e9todo MoSCoW \u00e9 uma t\u00e9cnica de prioriza\u00e7\u00e3o utilizada nos neg\u00f3cios para chegar a um acordo comum com as partes interessadas sobre a import\u00e2ncia que atribuem ao cumprimento de cada exig\u00eancia.<\/p>\n<\/div>\n
Seu nome vem da seguinte sigla:<\/p>\n
\n- M – Deve ter<\/strong><\/li>\n<\/ul>\n
Estes s\u00e3o os requisitos que s\u00e3o considerados “obrigat\u00f3rios”: se um deles n\u00e3o for atendido, o projeto \u00e9 considerado um fracasso. Mas cuidado, os requisitos “Devem ter” podem mudar de categoria de acordo com todas as partes envolvidas, especialmente se novos requisitos forem considerados mais importantes.<\/p>\n
DEVE tamb\u00e9m ser visto como um acr\u00f4nimo para “Minimum Usable Subset”.<\/p>\n
\n- S – Deveria ter<\/strong><\/li>\n<\/ul>\n
Estes s\u00e3o requisitos importantes mas n\u00e3o essenciais para o projeto (ou h\u00e1 uma maneira de atend\u00ea-los temporariamente e trat\u00e1-los mais tarde).<\/p>\n
\n- C – Poderia ter<\/strong><\/li>\n<\/ul>\n
As exig\u00eancias com o r\u00f3tulo “Poderia ter” s\u00e3o desej\u00e1veis mas n\u00e3o necess\u00e1rias: elas podem melhorar a experi\u00eancia do usu\u00e1rio ou a satisfa\u00e7\u00e3o do cliente a um custo m\u00ednimo de desenvolvimento. Normalmente ser\u00e3o inclu\u00eddos se o tempo e os recursos permitirem.<\/p>\n
\n- W – N\u00e3o ter\u00e1<\/strong><\/li>\n<\/ul>\n
As exig\u00eancias de “n\u00e3o ter” foram reconhecidas pelas partes interessadas como as menos cr\u00edticas, menos econ\u00f4micas ou n\u00e3o apropriadas no momento. Portanto, eles n\u00e3o s\u00e3o planejados no cronograma: ou s\u00e3o descartados ou reconsiderados para um cronograma posterior.<\/p>\n