Adicione atendimento ao app com o Mobile SDK

O atendimento dentro do app é útil quando o cliente já está olhando para o produto que gerou a dúvida. Uma superfície nativa preserva esse contexto, mas ainda precisa de uma pessoa responsável e de um caminho confiável até a equipe.

Saiba o que existe no release 0.2.0

O DobroDesk Mobile SDK 0.2.0 é distribuído como um release somente com artefatos. O release publicado cobre iOS, Android, Capacitor, React Native e NativeScript. O pacote Flutter se chama dobrodesk_sdk e está na versão 0.2.0. O código-fonte nativo não faz parte do pacote público.

Comece escolhendo a plataforma host e o artefato correto. O repositório público do SDK documenta assets imutáveis e somas de verificação, enquanto os guias de iOS e Android explicam a configuração. Fixe a versão que você testou para que uma atualização independente não altere a experiência de atendimento.

Abra o atendimento no contexto certo

Abra o atendimento a partir de um contexto útil do produto. Compartilhe apenas o contexto de cliente ou conta que o host pode compartilhar e explique o que o cliente pode fazer na tela de atendimento. O SDK oferece a entrada no app. O DobroDesk cuida da conversa, da Caixa de entrada compartilhada e do conhecimento aprovado.

Trate permissões e recursos opcionais como decisões do host. Os artefatos Android de voz e push são pacotes opcionais e o app host controla as permissões de microfone e notificações. Não descreva esses pacotes como garantia universal de voz ou push.

Planeje recuperação e permissões

Prepare a recuperação antes do primeiro release. Se o cliente estiver offline, faltar uma permissão ou a configuração do SDK não terminar, mostre o próximo passo e preserve a intenção de contato. Um bom fallback explica como continuar em vez de descartar a solicitação em silêncio.

Teste o mesmo caso de atendimento em cada plataforma que você pretende publicar. Verifique inicialização a frio, sessão restaurada, idioma, voltar, teclado e retorno ao app. Depois teste o encaminhamento para uma pessoa e confirme que o contexto continua claro na Caixa de entrada compartilhada.

Teste o limite do release antes de publicar

Deixe o limite do release visível para a equipe. Registre versão, plataforma, soma de verificação e permissões do host. Ao atualizar, compare as notas publicadas e repita os testes da conversa e da sessão restaurada antes de mudar a versão em produção.

Uma boa integração móvel parece nativa na entrada e coerente com a operação de atendimento por trás dela. Mantenha o percurso curto, deixe a responsabilidade explícita e use os guias públicos do SDK como fonte das capacidades realmente disponíveis no release que será enviado.