Ajouter le support dans une app avec le Mobile SDK

Le support intégré est utile lorsque le client regarde déjà le produit à l'origine de sa question. Une surface native conserve ce contexte, mais elle a toujours besoin d'un responsable et d'un chemin fiable vers l'équipe.

Vérifier le contenu du release 0.2.0

DobroDesk Mobile SDK 0.2.0 est distribué sous la forme d'un release composé uniquement d'artefacts. Le release publié couvre iOS, Android, Capacitor, React Native et NativeScript. Le package Flutter s'appelle dobrodesk_sdk et porte la version 0.2.0. Le code source natif n'est pas inclus dans le package public.

Commencez par choisir la plateforme hôte et l'artefact correspondant. Le dépôt public du SDK documente les assets immuables et leurs sommes de contrôle, tandis que les guides iOS et Android décrivent la configuration. Épinglez la version testée afin qu'une mise à jour indépendante ne modifie pas l'expérience de support.

Ouvrir le support depuis le bon contexte

Ouvrez le support depuis un contexte produit utile. Ne partagez que le contexte client ou compte que l'hôte est autorisé à transmettre et expliquez ce que le client peut faire dans la vue de support. Le SDK fournit l'entrée dans l'app. DobroDesk gère la conversation, la boîte partagée et les connaissances approuvées.

Traitez les permissions et les capacités optionnelles comme des décisions de l'application hôte. Les artefacts Android de voix et de notifications push sont optionnels et l'hôte gère les permissions du microphone et des notifications. Ne présentez pas ces artefacts comme une garantie universelle de voix ou de push.

Prévoir récupération et permissions

Préparez la récupération avant le premier release. Si le client est hors ligne, si une permission manque ou si l'installation du SDK ne se termine pas, affichez la prochaine étape et conservez l'intention de contacter l'équipe. Un bon relais explique comment continuer au lieu de perdre la demande.

Testez le même cas sur chaque plateforme prévue. Vérifiez le démarrage à froid, la session restaurée, la langue, le retour arrière, le clavier et le retour dans l'app. Testez ensuite le relais vers un conseiller et vérifiez que le contexte reste compréhensible dans la boîte partagée.

Tester la limite du release avant livraison

Documentez la limite du release pour l'équipe. Notez la version, la plateforme, la somme de contrôle et les permissions de l'hôte. Lors d'une mise à jour, comparez les notes publiées et répétez les tests de conversation et de session restaurée avant de changer la version en production.

Une bonne intégration mobile paraît native à l'entrée et cohérente avec le support qui la prend en charge. Gardez le parcours court, rendez la responsabilité explicite et utilisez les guides publics du SDK comme source des capacités réellement disponibles dans le release livré.