Reference16r1:Concept App Service Conference Transcriptions
Jump to navigation
Jump to search
Applies To
- innovaphone Conference Transciptions from version 16r1
Overview
The main goal of the Conference Transcriptions Service is to create video‑conference meeting summaries, which can be accessed in the Phone Apps.
To achieve this:
- Users can start a transcription of the conference audio by clicking the “Transcribe Conference” button in the Phone Apps.
- This action makes the Conference Transcriptions service connect to the conference room.
- It records the audio and creates audio files of approximately one minute in length.
- It forwards these small audio files via the com.innovaphone.transcriptions API, offered by the Transcriptions Service ( Concept App Service Transcriptions)
- It receives the transcripts of these small files and stores them in the service database.
- If the user stops the transcription by clicking on the "Transcribe Conference" Button again
- The Conference Transcriptions Service gathers the transcribed text from the database
- It retrieves the prompt configured in the settings plugin ConferenceTranscriptions settings plugin
- It sends the transcript together with the prompt to the Assistant App Service via the com.innovaphone.assistant API
- It receives the meeting summary and stores that summary in the database of the service
- Users may start and stop transcriptions multiple times during a meeting. As long as users remain in the room, the service recognizes that the meeting is still the same for that room.
- After the meeting, users can find the AI‑generated meeting summary in the call list of their Phone Apps by clicking on the “i” button.
Licensing
- In order to use the service each user needs the newly introduced UCC license
- Also one Port License is used by the app service to establish a VoIP registration at the PBX
Installation
In order to make the service work properly, two supplemental services must be installed first:
- the myApps Assistant which will summarize the transcript Concept App Service myApps Assistant
- the Transcriptions Service which establishes a connection to a remote transcription server Concept App Service Transcriptions
Go to the Settings App (fomerly known as PBX manager) and open the "AP app installer" plugin. On the right panel, the App Store will be shown. Hint : if you access it for the first time, you will need to accept the "Terms of Use of the innovaphone App Store"
- In the search field located on the top right corner of the store, search for "Conference Transcriptions" and click on it.
- Select the proper firmware version, for example "Version 16r1" and click on install.
- Tick "I accept the terms of use" and continue by clicking on the install yellow button.
- Wait until the install has been finished.
- Close and reopen the Settings App (PBX manager) in order to refresh the list of the available colored AP plugin icons.
- Open the "AP Conference Transcriptions" Plugin by clicking on it and click on " + Add an App" and then on the "Conference Transcriptions API" button.
- Enter a "Name" (used as display name / all character allowed) and the "SIP" (no space, no capital letters). e.g : Name: Conference Transcriptions API, SIP: conference-transcriptions-api
- Choose a LLM (model) from the dropdown
- Tick the appropriate template to distribute the App (the app is needed at every user object from any user who wants to use the assistant API)
- Click OK to save the settings. A green check mark will be shown to confirm that the configuration is good.
Conference Transcriptions - App Service
The App Service performs tasks in the following areas:
- Transcribes the audio of a conference room
- Stores the transcript, including chat messages, in the database
- Creates and stores the summary of the transcript in the database
It can be configured in the Settings App ConferenceTranscriptions settings plugin.
Phone App Integration
Users may control the generated transcripts using the Phone Apps. If the default transcript generated right after the meeting is not adequate users may generate a new customized one using the button "Customize style". They may:
- Choose a different predefined prompt from the drop-down menu (or use no prompt at all choosing the "-")
- Give some extra info or requests using the input field "What should be the focus?"
- This may be something like "Translate the transcript in Korean!"
- or "Just write down which decisions were made!", "There were some links pasted in the chat. Please integrate them in the meeting summary!"
Summary prompts
You may configure the prompts freely. Here are some propositions you may copy/paste into the corresponding field of the settings plugin. Depending on the used model these prompts don't need to be that sophisticated. Something like "Summarize the following transcript! Make clear who has taken which task!" may be sufficient.
1. General prompt
# Meeting-Protokoll aus Transkript erstellen
Du erhältst ein Meeting-Transkript. Erstelle daraus ein kurzes, gut lesbares Protokoll. Es soll festhalten, was Leser nach dem Meeting wissen müssen, ohne den Gesprächsverlauf nachzuerzählen.
**Leitprinzip: So viel wie nötig, so wenig wie möglich.**
## 1. Sprache
Erkenne automatisch die Hauptsprache des Meetings und schreibe das gesamte Protokoll in dieser Sprache. Das gilt für Titel, Einleitung, Überschriften und alle Bullets.
Verwende die Sprache, in der das Meeting überwiegend geführt wird. Einzelne fremdsprachige Passagen, automatisch eingefügte Übersetzungen, Transkriptionsfehler oder technische Begriffe ändern die Ausgabesprache nicht.
Übersetze Eigennamen, Produktnamen, technische Bezeichnungen, @-Tags und wörtlich zu übernehmende Bezeichnungen nicht.
## 2. Nur Informationen aus dem Transkript
**Stütze jede Aussage auf das Transkript.**
Du darfst mehrere Aussagen zum selben Sachverhalt zu einer gemeinsamen Erkenntnis verdichten. Ergänze dabei aber keine Informationen, Begründungen, Entscheidungen, Verantwortlichkeiten oder Zusammenhänge, die das Transkript nicht trägt.
Wenn das Transkript wegen Transkriptionsfehlern oder unklarer Aussagen keine sichere Schlussfolgerung erlaubt, erfinde keine plausible Bedeutung.
## 3. Relevante Informationen auswählen
Das Protokoll hält fest, **was Leser aus jedem relevanten Arbeitsthema mitnehmen müssen**.
Eine Information kommt grundsätzlich infrage, wenn mindestens eines davon zutrifft:
- Sie ist ein Ergebnis oder eine Entscheidung.
- Sie ist eine zentrale Erkenntnis aus der Diskussion.
- Sie konkretisiert eine Anforderung, ein Problem oder eine relevante Unterscheidung.
- Sie verändert den bisherigen Stand.
- Aus ihr entsteht eine Aufgabe oder ein nächster Schritt.
- Sie ist eine ernsthaft weiterverfolgte Option oder Lösungsrichtung, auch wenn noch nicht darüber entschieden wurde.
- Sie ist eine offene Frage, ein Blocker, ein Risiko oder eine Abhängigkeit, die das weitere Vorgehen beeinflusst.
- Ein bewusst behandeltes Thema wurde eingeordnet, zurückgestellt oder aus dem aktuellen Scope ausgeschlossen.
- Sie ist nötig, damit ein Ergebnis, eine Aufgabe oder das weitere Vorgehen verständlich ist.
### Informationswert prüfen
Eine grundsätzlich relevante Information kommt nicht automatisch ins Protokoll.
Nimm sie nur auf, wenn sie für Leser nach dem Meeting einen zusätzlichen Informationswert hat:
- Sie beeinflusst die weitere inhaltliche Arbeit, eine Entscheidung oder das Handeln nach dem Meeting.
- Ohne sie würde einem Leser etwas Wichtiges fehlen.
- Sie liefert gegenüber den bereits ausgewählten Aussagen eine zusätzliche Erkenntnis.
**Die Länge oder Gesprächsdauer eines Themas entscheidet nicht über seine Relevanz.** Nimm auch kurz behandelte Themen auf, wenn sie diese Kriterien erfüllen.
Alles andere lässt du weg – auch wenn es im Meeting ausführlich besprochen wurde.
Das betrifft insbesondere:
- Gesprächsverlauf, einzelne Wortbeiträge, Wiederholungen und Zustimmung
- spontane Ideen, die nicht weiterverfolgt werden
- hypothetische Fallbacks ohne Bedeutung für das weitere Vorgehen
- Beispiele und Anekdoten, die nur eine Aussage illustrieren
- Details zur Durchführung einer Aufgabe, die für das spätere Handeln nicht wichtig sind
- technische Details, die für das spätere Handeln nicht nötig sind
- beiläufige Bemerkungen
Unterscheide zwischen einer beiläufig genannten Idee und einer ernsthaft diskutierten Option. Eine Option ist relevant, wenn die Diskussion zeigt, dass sie beim weiteren Vorgehen berücksichtigt, geprüft oder bewusst offengehalten werden soll.
Behalte Informationen, die eine verantwortliche Person später braucht, um ihre Aufgabe selbstständig auszuführen oder Fehler zu vermeiden. Das Protokoll soll aber keine Bedienungsanleitung werden.
## 4. Diskussionen verdichten
Erzähle Diskussionen nicht nach. **Leite aus mehreren Aussagen zum selben Sachverhalt die zentrale Erkenntnis, den aktuellen Stand oder die weiterverfolgte Richtung ab.**
Wenn beispielsweise mehrere Kriterien diskutiert werden und sich daraus ergibt, welche Kriterien für die weitere Arbeit wichtig sind, nenne diese Kriterien direkt. Gib nicht wieder, wer welches Kriterium vorgeschlagen hat.
Eine Diskussion muss keine endgültige Entscheidung ergeben, um relevant zu sein. Wenn sich daraus eine Arbeitsrichtung, wichtige Unterscheidung, ernsthafte Option oder ein Risiko ergibt, halte diese knapp fest und erhalte den Grad der Verbindlichkeit.
Nenne Hintergrund, Begründungen und technische Details nur, wenn sie nötig sind, um ein Ergebnis, eine Entscheidung oder das weitere Vorgehen zu verstehen oder später nachvollziehen zu können.
Eine Information ist nicht allein deshalb relevant, weil sie eine Kernaussage genauer erklärt. Wenn die Kernaussage ohne diese Erklärung verständlich und handlungsfähig bleibt, lass die Erklärung weg.
Wenn eine bewusst behandelte Diskussion kein Ergebnis und keine erkennbare Richtung hatte, erwähne das nur, wenn die offene Frage für die weitere Arbeit relevant bleibt.
Verworfene Alternativen nennst du nur, wenn das Verwerfen selbst ein relevantes Ergebnis ist.
Wenn nach einer Entscheidung ein relevanter Widerspruch ausdrücklich bestehen bleibt, halte ihn knapp fest. Suggeriere keinen Konsens, den es nicht gab.
### Beispiele und Details
Wenn eine übergeordnete Erkenntnis bereits verständlich ist, lass Beispiele und einzelne Diskussionsdetails weg.
Nenne ein Beispiel nur, wenn es selbst weiterverfolgt wird, für eine Entscheidung wichtig ist oder eine notwendige Information enthält, die in der übergeordneten Aussage verloren gehen würde.
Mehrere Beispiele aus einer Diskussion sind kein Grund, sie im Protokoll aufzuzählen.
## 5. Aufgaben im Kontext nennen
Trenne Aufgaben nicht von dem Sachverhalt, aus dem sie entstehen. Der Leser soll verstehen, was jemand tun soll und warum, ohne an eine andere Stelle des Protokolls springen zu müssen.
Wenn die Aufgabe bereits zusammen mit ihrem Kontext genannt wurde, wiederhole sie nicht an anderer Stelle.
Verwende bei konkreten Aufgaben den @-Tag der verantwortlichen Person, wenn er aus dem Transkript eindeutig bekannt ist. Übernimm Tags exakt. Erfinde keine Tags. Wenn kein Tag bekannt ist, verwende den Namen.
Es gibt keine separate Aufgabenliste.
## 6. Verbindlichkeit und Unsicherheit erhalten
Eine Aussage darf im Protokoll nie sicherer oder verbindlicher werden als im Transkript.
Unterscheide zwischen:
- beschlossenen Entscheidungen und eindeutigen Aufgaben
- geplanten Vorgehensweisen und Absichten
- ernsthaft diskutierten Optionen
- Vorschlägen und Möglichkeiten
- Vermutungen, Schätzungen und unbestätigten Aussagen
Aus „ich würde das testen“ wird nicht „Anna testet das“. Aus „ich glaube“ wird keine Tatsache.
Wenn eine unsichere Aussage relevant ist, erhalte die Unsicherheit sprachlich, zum Beispiel mit „vermutlich“, „wahrscheinlich“, „möchte“, „könnte“ oder „noch nicht bestätigt“.
Eine ernsthaft diskutierte Option darf als solche genannt werden, aber nicht als Entscheidung erscheinen.
## 7. Änderungen, Termine und Abhängigkeiten
Wenn eine bestehende Entscheidung, Planung oder ein relevanter Status geändert wird, mache die Veränderung sichtbar. Nenne bei Bedarf alten und neuen Stand.
Zahlen, Termine und Zeitangaben nennst du nur, wenn sie für Planung, Verständnis oder weiteres Handeln relevant sind.
Abhängigkeiten, Einschränkungen und Blocker nennst du, wenn sie beeinflussen, was als Nächstes möglich ist.
Organisatorische Absprachen behandelst du nach denselben Relevanzkriterien wie alle anderen Informationen. Nimm sie auf, wenn sie für das weitere Vorgehen wichtig sind; lass sie weg, wenn sie keinen zusätzlichen Informationswert haben.
## 8. Struktur des Protokolls
Beginne mit einem kurzen Titel, der das zentrale Thema des Meetings benennt. Der Titel enthält keine Ergebnisse oder Details.
Danach folgen ein bis zwei Sätze, die erklären, worum es im Meeting ging und welches Ziel oder welcher Zweck verfolgt wurde. Nenne nur Kontext, den Leser brauchen, um die folgenden Themen zu verstehen. Nimm Ergebnisse, Aufgaben und Rollen hier nicht vorweg, wenn sie zu einem konkreten Thema gehören.
Gliedere anschließend nach den **relevanten Arbeitsthemen des Meetings**.
Ein Thema verdient einen eigenen Themenblock, wenn daraus ein Ergebnis, eine zentrale Erkenntnis, eine Aufgabe, eine relevante Option, ein Risiko, eine Scope-Entscheidung oder ein nächster Schritt hervorgeht und diese Information die Relevanzkriterien aus Abschnitt 3 erfüllt.
Wenn klare Agenda-Punkte erkennbar sind, orientiere dich daran. Andernfalls bündele eng zusammenhängende Inhalte unter gemeinsamen Themenüberschriften.
Bevorzuge wenige sinnvolle Themenblöcke gegenüber vielen kleinen Sektionen.
Überschriften benennen das Thema, nicht das Ergebnis.
Innerhalb eines Themenblocks:
- Beginne normalerweise mit dem Ergebnis, der Entscheidung oder der wichtigsten Erkenntnis.
- Stelle notwendigen Kontext nur dann davor, wenn das Ergebnis sonst nicht verständlich wäre.
- Nenne Aufgaben und nächste Schritte unmittelbar bei dem Sachverhalt, aus dem sie entstehen.
- Verwende keine Labels wie „Ergebnis“, „Hintergrund“ oder „Aufgabe“.
## 9. Schreibstil
Schreibe klar, direkt und natürlich. Das Protokoll soll so klingen, wie Menschen im Arbeitsalltag miteinander schreiben. Ein leichter Grad an Lockerheit ist erwünscht, solange die Aussagen präzise bleiben.
### Aktiv statt Passiv
**Bevorzuge konsequent aktive und direkte Formulierungen. Vermeide Passivkonstruktionen und passiv wirkende Ersatzformen.**
Wähle das Subjekt nach diesen Regeln:
1. **Eine konkrete Person handelt:** Nenne die Person.
- „@asu überarbeitet die Nutzergruppen.“
2. **Die Gruppe handelt gemeinsam:** Verwende „wir“.
- „Wir starten mit dem Basic Call.“
3. **Kein konkreter Handelnder ist relevant oder eindeutig bekannt:** Formuliere den Sachverhalt direkt über den Gegenstand.
- „Der Task wandert in Sprint 2.“
- „Gruppenlogin kommt ins Backlog.“
- „Die Vorzimmerfunktion gehört nicht zum aktuellen Scope.“
Erfinde keine verantwortliche Person, nur um Passiv zu vermeiden.
Vermeide auch passiv wirkende Ersatzformen und Nominalstil wie „ist vorgesehen“, „soll erfolgen“, „findet statt“, „eine Prüfung von …“ oder „eine Überarbeitung von …“. Formuliere stattdessen mit einem natürlichen Subjekt und einem einfachen Verb.
### Kurz und natürlich
- Nenne eine Person konkret, wenn ihre Zuständigkeit oder Handlung für das weitere Vorgehen relevant ist.
- Verwende „wir“ nur für gemeinsames Vorgehen, nicht für Aufgaben einzelner Personen.
- Vermeide künstliche Sammelbezeichnungen wie „das Team“, „die Beteiligten“ oder „die Runde“, wenn sie keinen zusätzlichen Informationswert haben.
- Verwende einfache Verben statt abstrakter Substantive.
- Schreibe kurze, vollständige Sätze.
- Ein Bullet enthält genau eine Kernaussage.
- Formuliere die Kernaussage so kurz wie möglich.
- Ein Bullet besteht normalerweise aus einem Satz.
- Verwende einen zweiten Satz nur, wenn eine notwendige Einschränkung, Begründung oder Konsequenz sonst verloren geht.
- Details, die die Kernaussage nur erklären, illustrieren oder technisch präzisieren, lässt du weg.
- Enthält ein Bullet zwei eigenständige relevante Aussagen, teile sie auf zwei Bullets auf.
- Kürze nicht durch kompliziertere oder stärker verdichtete Sätze. Entferne stattdessen Informationen mit geringerem Informationswert.
- Vermeide formelle Berichts- und Verwaltungssprache.
- Vermeide Floskeln wie „im Rahmen von“, „hinsichtlich“, „diesbezüglich“, „seitens“, „bezüglich“ und „im Hinblick auf“.
- Vermeide leere Formulierungen wie „Es fand eine Diskussion statt“ oder „Es wurden verschiedene Aspekte besprochen“.
- Keine Emojis, Bewertungen, Anbiederung oder künstliche Lockerheit.
### Unterbullets
Wenn eine Kernaussage mehrere gleichrangige Kriterien, Aspekte oder Optionen enthält, kannst du kurze Unterbullets verwenden, wenn sie dadurch schneller erfassbar werden.
Beispiel:
- Wichtiger für die Nutzergruppen sind:
- einfache vs. komplexe Rufabläufe
- Audio vs. Video
- neue vs. geübte Nutzer
Nutze Unterbullets nur zur besseren Lesbarkeit.
## 10. Erlaubt und verboten
### Aktiv formulieren
**Verboten:** „Die Nutzergruppen werden überarbeitet.“
**Erlaubt:** „@asu überarbeitet die Nutzergruppen.“
**Verboten:** „Mit dem Basic Call soll gestartet werden.“
**Erlaubt:** „Wir starten mit dem Basic Call.“
**Verboten:** „Der Task wird in Sprint 2 verschoben.“
**Erlaubt:** „Der Task wandert in Sprint 2.“
### Bullets kurz halten
**Verboten:** Eine Kernaussage mit Details erklären, die für das weitere Verständnis oder Handeln nicht nötig sind:
- „Der bisherige Claude-Ansatz aus dem technischen Rufzustandsdokument liefert zu viele technische Details für das UI. Das Dokument eignet sich eher als Checkliste, nicht als direkte Grundlage für automatisch generierte Screens.“
**Erlaubt:**
- „Das technische Rufzustandsdokument dient als Checkliste, nicht als Grundlage für automatisch generierte Screens.“
**Verboten:** Einen nächsten Schritt mit einer entbehrlichen Begründung verlängern:
- „Wir starten im Prototyping mit dem Basic Call, um den Ablauf und die Zusammenarbeit mit Claude besser zu verstehen.“
**Erlaubt:**
- „Wir starten das Prototyping mit dem Basic Call.“
**Verboten:** Zwei Sätze verwenden, wenn dieselbe relevante Information kürzer ausgedrückt werden kann:
- „Beim späteren Umbau besteht das Risiko, eine gereifte App durch eine neue, noch lückenhafte Lösung zu ersetzen. In der aktuellen Prototyping-Phase entsteht daraus noch kein Umsetzungsrisiko.“
**Erlaubt:**
- „Das Umsetzungsrisiko entsteht erst beim späteren Umbau, nicht in der aktuellen Prototyping-Phase.“
### Bullets nicht überladen
**Verboten:**
- „Die F-Keys funktionieren nach aktuellem Stand. @rse ergänzt noch die Erkennung des Default-Geräts und erstellt eine Liste der Icons für @asu. Danach kann die App intern getestet und entschieden werden, ob noch etwas fehlt.“
**Erlaubt:**
- „@rse ergänzt vor dem internen Test noch die Erkennung des Default-Geräts.“
- „@rse erstellt eine Liste der benötigten Icons. @asu erstellt und prüft die Icons.“
- „Danach können wir die App intern testen.“
### Aufgaben im Kontext nennen
**Verboten:** „@Nina: Fehlermeldung überarbeiten.“
**Erlaubt:** „Die Fehlermeldung erklärt nicht, wie Nutzer das Problem beheben können. @Nina überarbeitet den Text.“
### Verbindlichkeit erhalten
**Verboten:** Aus „Ich würde vielleicht kleinere Modelle testen“ wird „@Anna testet kleinere Modelle.“
**Erlaubt:** „Anna möchte auch kleinere Modelle testen.“
### Diskussionen verdichten
**Verboten:** Die einzelnen Positionen und Wortbeiträge einer Diskussion nacheinander wiedergeben.
**Erlaubt:** „Zwei Varianten wurden abgewogen. Wir entscheiden uns für B, weil sie für Nutzer verständlicher ist.“
### Änderungen sichtbar machen
**Verboten:** Eine relevante Änderung nur als neuen Zustand nennen.
**Erlaubt:** „Der Release verschiebt sich von September auf Oktober.“
## 11. Ausgabeformat
Gib das fertige Protokoll ausschließlich als HTML aus.
Die Anzahl und Namen der Themenblöcke ergeben sich aus dem Inhalt des Meetings. Erzeuge keine festen Kategorien wie „Entscheidungen“, „Aufgaben“, „Key Points“ oder „Offene Fragen“.
Aufgaben, Entscheidungen, offene Fragen und nächste Schritte stehen direkt im passenden Themenblock.
### HTML-Struktur
```html
<br>
<b>[Kurzer Titel]</b>
<br>
<br>
<i>[Ein bis zwei Sätze zu Zweck und Kontext des Meetings.]</i>
<br>
<br>
<b>[Themenüberschrift]</b>
<ul>
<li><i>[Kernaussage]</i></li>
<li><i>[Kernaussage]</i></li>
</ul>
<br>
<br>
<b>[Weitere Themenüberschrift]</b>
<ul>
<li><i>[Kernaussage]</i></li>
</ul>
```
Wenn Unterbullets nötig sind, setze sie als verschachtelte `<ul>` um:
```html
<ul>
<li><i>[Übergeordnete Kernaussage]</i>
<ul>
<li><i>[Punkt 1]</i></li>
<li><i>[Punkt 2]</i></li>
</ul>
</li>
</ul>
```
### Strikte HTML-Regeln
- Verwende ausschließlich `<ul>`, `<li>`, `<br>`, `<b>` und `<i>`.
- Beginne die Ausgabe direkt mit `<br>`.
- Titel und Themenüberschriften stehen in `<b>`.
- Die Einleitung steht vollständig in `<i>`.
- Der gesamte inhaltliche Text innerhalb von `<li>` steht in `<i>`.
- Auch der Text von Unterbullets steht vollständig in `<i>`.
- Verwende kein Markdown.
- Verwende keine anderen HTML-Tags und keine HTML-Kommentare.
- Umschließe die Ausgabe nicht mit `<html>`, `<body>`, `<div>` oder einem anderen globalen Element.
- Erzeuge keine leeren Abschnitte oder Platzhalter.
- Gib vor oder nach dem HTML keinen zusätzlichen Text aus.
## 12. Prüfung vor der Ausgabe
Prüfe das fertige Protokoll abschließend:
1. **Relevanz:** Jede Information erfüllt die Kriterien aus Abschnitt 3 und liefert zusätzlichen Informationswert.
2. **Verdichtung:** Keine Gesprächsverläufe, unnötigen Beispiele, Details oder Wiederholungen.
3. **Bullet-Länge:** Prüfe jeden Bullet einzeln. Kannst du Wörter, Erklärungen oder einen zweiten Satz entfernen, ohne relevante Information zu verlieren? Wenn ja, kürze ihn.
4. **Verbindlichkeit:** Keine Aussage ist sicherer oder verbindlicher als im Transkript.
5. **Aufgaben:** Verantwortlichkeiten stimmen und Aufgaben stehen in ihrem inhaltlichen Kontext.
6. **Sprache und Stil:** Das Protokoll verwendet die Hauptsprache des Meetings und formuliert aktiv, direkt und natürlich. Formuliere Passiv und passiv wirkende Konstruktionen um, ohne Verantwortlichkeiten zu erfinden.
7. **Format:** Struktur und HTML entsprechen vollständig den Vorgaben aus Abschnitt 11.
Gib ausschließlich das fertige HTML-Protokoll aus.
2. A more structured version:
You will receive a meeting transcript. Your task is to turn it into a structured meeting summary. The entire summary — including section headers, bullet points, and all text — must be written in the same language as the transcript. Detect the language automatically. If the transcript is in german write the summary in german. If the transcript is in english, write the summary in english... Follow these instructions exactly: 1. Read the transcript carefully. 2. Extract only the information that is clearly stated. Do not guess or invent anything. 3. Create the final summary using the exact structure below, but translate the section headers into the language of the transcript. OUTPUT FORMAT (translate the headers into the transcript language, but keep the structure): <br> <b>A short title describing the meeting.</b> <br> <br> <ul> <li><b>Summary: </b></li> <ul> <!-- (2–4 sentences describing the purpose of the meeting and the main outcomes.) --> <li>Sentence 1</li> <li>Sentence 2</li> </ul> <br> <br> <li><b>Decisions:</b></li> <ul> <li>Decision 1</li> <li>Decision 2</li> <!-- Write “None mentioned” if no decisions were made. --> </ul> <br> <br> <li><b>Key Points:</b></li> <ul> <li>Bullet point 1</li> <li>Bullet point 2</li> <li>Bullet point 3</li> <!-- Add more if needed --> <!-- 2-3 sentences for each point --> </ul> <br> <br> <li><b>Tasks:</b></li> <ul> <li>Person — Task — Deadline (or “No deadline mentioned”)</li> <!-- Add as many as needed. Or none of none mentionned--> </ul> <br> <br> <li><b>Open Questions:</b></li> <ul> <li>Question 1</li> <li>Question 2</li> <!-- Write “None mentioned” if none. --> </ul> </ul> RULES: Use HTML lists (<ul><li></li></ul>) only for bullet points. Do not add information that is not in the transcript. Keep the writing clear and concise. Keep the structure exactly as shown, but translate the headers. Do not wrap the whole answer in a single HTML tag. Use a normal text style. No italic. TRANSCRIPT:
3. When meetings are used to take decisions:
You will receive a meeting transcript. Your task is to turn it into a structured meeting summary. The entire summary — including section headers, bullet points, and all text — must be written in the same language as the transcript. Detect the language automatically. If the transcript is in german write the summary in german. If the transcript is in english, write the summary in english... Follow these instructions exactly: 1. Read the transcript carefully. 2. Extract only the information that is clearly stated. Do not guess or invent anything. 3. Create the final summary using the exact structure below, but translate the section headers into the language of the transcript. OUTPUT FORMAT (translate the headers into the transcript language, but keep the structure): <br> <b>A short title describing the meeting.</b> <br> <br> <li><b>Results:</b></li> <ul> <li>Results 1</li> <li>Results 2</li> <!-- Write “None mentioned” if no decisions were made. --> </ul> <br> <br> <li><b>Miscellaneous:</b></li> <ul> <li>Bullet point 1</li> <li>Bullet point 2</li> <li>Bullet point 3</li> <!-- Add more if needed --> <!-- maximum 2, better 1 sentences for each point -- </ul> <br> <br> <li><b>Tasks:</b></li> <ul> <li>Person (with sip e.g. @pso)— Task</li> <!-- Add as many as needed. Or none of none mentionned--> </ul> RULES: Use HTML lists (<ul><li></li></ul>) only for bullet points. Do not add information that is not in the transcript. Keep the writing clear and concise. Keep the structure exactly as shown, but translate the headers. Do not wrap the whole answer in a single HTML tag. TRANSCRIPT:
Troubleshooting
First check if at PBX/Registrations a JSON registration for conference-transcriptions-api is present. If not, check sufficient amount of available PBX-port license - the service requires one.
For troubleshooting the Conference Transcriptions App Service, you need activate the traceflags App, Database and HTTP-Client in your App instance.