UtteraUttera

Comment demander de l'aide

Une adresse et c'est tout : support@uttera.ai. Une personne répond.

Il n'y a pas de formulaire, pas de numéro de ticket, et pas de bot demandant si vous avez essayé de redémarrer. Quand le volume l'exigera, nous construirons quelque chose avec plus de machinerie, et ce sera dit ici ; d'ici là, un e-mail arrive plus tôt et reçoit une réponse tout autant.

Si ce que vous voulez savoir, c'est si le service est en panne plutôt que si c'est juste vous, cela se vérifie avant d'écrire : état du service.

Ce qu'il faut nous envoyer

Ceci suffit presque toujours pour comprendre ce qui s'est passé sans avoir à vous demander autre chose :

ÉlémentD'où il vient
X-Request-Id — le plus importantUn en-tête de la réponse qui a échoué. Il identifie votre requête exacte parmi toutes celles du jour.
Heure approximative et fuseau horaireVotre horloge. Sans le fuseau, une heure ne sert à rien.
Le endpoint/v1/audio/transcriptions, /v1/summarize
Ce que vous attendiez et ce qui s'est passéVous. L'erreur littérale, s'il y en a une, mieux collée que résumée.
Votre identifiant de clientIl est sur votre page de compte. Ce n'est pas une référence secrète : le connaître ne donne accès à rien.
Ne nous envoyez jamais votre clé d'API. Ni en entier, ni « les premiers caractères au cas où ». Nous n'en avons besoin pour rien : avec le X-Request-Id, nous trouvons la requête. Si nous recevions un jour une clé dans un e-mail, nous la révoquerions et vous préviendrions.

Et si le problème concerne un fichier audio précis, vous n'avez pas besoin de l'envoyer pour commencer. Presque tout se diagnostique à partir de l'identifiant de requête. Si nous avions un jour besoin de l'audio, nous le demanderions et expliquerions pour quoi — ce qui est la seule façon qu'un de vos enregistrements finisse entre nos mains plus longtemps que les secondes qu'il faut pour le traiter.

Combien de temps nous prenons

Voici ce à quoi nous nous engageons. C'est le délai de première réponse les jours ouvrés, non le délai de résolution : certaines pannes se règlent en dix minutes et d'autres non, mais savoir que quelqu'un s'en occupe ne devrait pas dépendre de la chance.

PlanPremière réponse
FreeDès que nous le pouvons. Aucun engagement — mais c'est bien lu.
Startup · Developer2 jours ouvrés
Professional1 jour ouvré
Business4 heures ouvrées
EnterpriseContact direct, convenu dans le contrat
Ce n'est pas le SLA. Le SLA de votre plan est un engagement sur la disponibilité du service et tient tout seul. Un e-mail répondu tardivement ne consomme pas de SLA, et un service en panne ne se répare pas en répondant vite à un e-mail.

Si quelque chose est réellement cassé

Si vous pensez avoir trouvé un bug de notre part — non une question d'usage — dites-le dans l'objet. Nous nous en occupons avant tout le reste, et s'il s'avère que vous aviez raison, nous le publierons : dans cette documentation si cela change quelque chose d'écrit ici, et dans le changelog si cela touche au service.

Et si ce que vous avez trouvé est un problème de sécurité, écrivez-le à la même adresse avec [seguridad] dans l'objet et ne le publiez pas entre-temps. Nous répondrons avec ce que nous savons et avec un délai.