This page is a runnable two-week pilot protocol, not another Arabic note-taker list. The Gulf sequence is a visible hardware recorder, consent and PDPL questions for counsel, a code-switch quality scorecard, and bilingual action items a person reviews. Set consent and access first. Test real Arabic–English meetings — including mid-sentence switches — on that scorecard. Success is only when corrected notes produce human-confirmed owners and deadlines. Hardware waits until that workflow passes. This method is not a “best tool” claim.
Consent, in this protocol, means calendar-invite disclosure plus a spoken start-of-meeting script. Stop if anyone objects. Limit who can reach the audio, transcript and summary, and set a retention default before the first recording. This is an operating protocol for a team pilot. It is not legal counsel and not an opinion on PDPL or any other statute.
Quality is useful only when it becomes action. Score Arabic, English and mid-sentence switches on meaning-critical errors and on the time needed to correct them. Ship a note from the pilot only if the corrected record reliably yields an action, an owner and a due date inside the window your team agreed in Week 0.
What “done” looks like
“Done” is a two-week test a UAE or KSA team can repeat. You should be able to show the meeting types in scope, that every recording used the same notice and access rules, a scorecard covering Arabic-heavy, English-heavy and code-switching samples, and notes a reviewer turned into owned, dated actions. Hardware waits until that pack exists.
Write the success rule before Week 1: a reviewer can produce a shareable note whose action lines name an owner and a due date, and those owners confirm the assignment. If the current capture method cannot do that, adding devices will not fix the workflow.
Name the exclusions in the same document. This protocol does not cover covert recording, HR investigations, legal strategy, privileged counsel sessions, or meetings a participant would treat as confidential beyond ordinary minutes. Those labels are scope boundaries, not legal advice. If a session might be excluded, do not record it — ask the business owner and, where needed, counsel before the invite goes out. Also exclude quiet one-speaker demonstrations. The finished, checked note is the unit of evaluation, as in the meeting-device pilot worksheet and Meeting AI: measure the finished note.
Week 0 — Consent and privacy gate
Week 0 is a gate: no capture until invite language, verbal script, access list, retention default and vendor questions are written down and accepted by the pilot owner. See also the consent and privacy test.
Calendar invite. State that the session may be recorded to produce internal meeting notes; name the languages you expect (Gulf Arabic and English, including switching); say who will see audio, transcript and summary; and tell people how to object — reply to the invite, or say so at the start.
Start-of-meeting script. The host says, in the language the room is using, that recording is on, what will be produced, who can access it, and that anyone may object. Then pause. If anyone objects, stop. Do not negotiate a “just this once” exception in the room. Take unrecorded minutes, or reschedule with a different list.
Access. List who may open audio, transcript and summary. Default to host, designated reviewer and pilot owner. A share link is access; record who holds it.
Retention. Before the first file exists, set how long audio, transcript and summary are kept, where they live, and who can delete them. Use a short default that still covers the scoring week.
Vendor questions. Ask where audio and text are processed and stored, whether subprocessors see content, whether a residency option exists, how deletion works, and who can export or reassign an account. These are procurement questions, not a PDPL interpretation. If the answer is vague, do not start Week 1 on that vendor.
Keep the Week 0 pack in an approved system. An inquiry to CNPS needs destination, languages, team size and timeline — not confidential minutes. See privacy and request a quotation.
Week 1 — Capture design
Design capture around the meetings you already run. Device choice is secondary.
Pick three to five recurring sessions that mix Gulf Arabic and English the way your team speaks: an internal stand-up, a customer or partner call with external guests, and at least one working session where people switch languages mid-sentence. Note speaker count, room versus remote, and whether guests sit outside your organisation.
Stay device-agnostic for the first pass. Use whatever already records with consent — a table recorder, earbuds, a laptop, a room system — as long as capture is visible and you can collect audio, a transcript and a summary inside the access list. Measure the whole path: capture, transfer, transcript, summary, correction, action extraction.
After two or three sessions you will know whether capture is the bottleneck (distance, overlap, missing remote audio) or whether correction and ownership are. Only then consider a dedicated recorder. TicNote is one capture option; choose a SKU on the TicNote collection. This page does not rank models and does not run checkout. Confirm destination, plan and listing before any order. Compare form factors on AI meeting devices and Equip my team after the workflow passes.
Keep Week 1 samples inside the Week 0 rules. Do not widen the audience because a summary “looks useful.”
Scorecard: Arabic, English, and mid-sentence switches
Do not buy on a claimed word-error rate. A single percentage hides the misses that waste time: a wrong name, a changed number, an English clause that reverses an Arabic condition, or a switched sentence treated as noise. Score meaning-critical errors and minutes-to-correct.
Use one row per sample. Mark dialect or code-switch density in plain language. Count speakers and meaning-critical errors in Arabic, English and at switch points. Record time-to-correct. Then apply the ship rule.
| Sample | Dialect / code-switch density | Speakers | Meaning-critical errors (AR / EN / switch) | Time-to-correct | Ship / no-ship |
|---|---|---|---|---|---|
| Internal weekly, table + one remote | Khaleeji-dominant; English product names | 5 | Count each class separately | Minutes to a shareable note | Ship only if actions have owner + due |
| Partner call with external guests | Mixed; guests may use another Arabic variety | 4 | Same three classes; flag guest names | Same | No-ship if access or consent was incomplete |
| Working session with mid-sentence switches | High switch density | 3 | Switch-point errors counted on their own | Same | No-ship if switch errors change commitments |
| English-led update with Arabic asides | English-dominant | 6 | Aside clauses must keep their force | Same | No-ship if asides disappear from the note |
Pass rule (operational). A sample ships only when consent and access were complete, meaning-critical errors were counted by language and by switch, time-to-correct stayed inside the Week 0 budget, and the corrected note produced at least one action with a named owner and a confirmed due date. Zero errors still fail if nobody can say who will do what by when. Several errors can still inform the pilot if correction was fast and owners confirmed — they do not justify a bulk purchase.
Leave the WER box empty. File any vendor percentage as a claim beside the scorecard. Keep evaluation files in the approved system.
Notes become action items
The note is not finished when the summary appears. It is finished when a person has checked it and the work has owners.
For every candidate action, record four fields: the action in one line; the owner (a person, not a department); the due date; and the language of the source utterance — Arabic, English, or mixed. The last field shows whether errors cluster on one side of the switch. If an action was agreed in Arabic and the English summary softened it, that is a meaning-critical miss, not a style issue.
Human review happens before share. The reviewer checks decisions, numbers, names, conditions and open questions, then sends the action list only to people on the access list plus the named owners. Owners confirm or correct the assignment. Unconfirmed lines stay in the pilot pack.
If the team already tracks work elsewhere, copy confirmed lines by an approved export. Do not connect a new transcription account to a company-wide task board during the test. The finished-note method is the same idea: measure the checked record, not the first draft.
Gulf-specific checks
Treat Gulf Arabic as the language you hear, not as a generic “Arabic” toggle. Formal written Arabic can still fail on Khaleeji phonology, local names, mixed numerals, or English terms inside an Arabic sentence. Include at least one sample in the variety your hosts and guests use. If speakers come from more than one Gulf country, say so on the scorecard.
External guests change consent. The invite and verbal script must include them. If a guest objects, stop. If a guest joins late, repeat the script. Do not record guests on a personal account.
Data residency and PDPL questions belong to counsel and the security owner. Ask vendors the residency and deletion questions in Week 0, then escalate those answers. This protocol does not interpret a statute or certify a hosting region. If counterparties are government-adjacent or regulated, add their recording rules to the exclusion list. When in doubt, take unrecorded minutes.
Copy-paste checklist
- Name the pilot owner, the reviewer, and the meeting types in scope.
- Write exclusions: covert recording; HR, legal and privileged sessions; any other type counsel or the business owner bars.
- Draft invite language: recording purpose, languages, access, how to object.
- Draft the start-of-meeting script in the language the host will speak; include the pause.
- Freeze the access list and the retention default; write who can delete.
- Send vendor questions on processing location, subprocessors, residency options, deletion and account reassignment.
- Choose real bilingual sessions, including one with mid-sentence switches and one with external guests if that is normal work.
- Capture with consent using the current method first; keep files inside the access list.
- Fill the scorecard: dialect or switch density, speaker count, meaning-critical errors by AR / EN / switch, time-to-correct, ship or no-ship.
- Turn each shipped note into actions with owner, due date and source-utterance language; require owner confirmation before wider share.
- Decide hardware only after the workflow passes; if you want a TicNote, open the collection and confirm the listing — do not rank SKUs from this page.
- Write a one-page decision: proceed, narrow the meeting types, change the capture path, or stop.
FAQ
Someone objects. What do we do? Stop recording. Offer unrecorded minutes or a later session with a different list. Do not continue “without using their name,” and do not keep a partial file. An objection ends capture for that session.
Cloud or on-prem? Ask where audio and text are processed, who can reach them, and how deletion is proven. If you lack a required residency option, do not start Week 1 on that stack. This page does not certify a topology.
When should we buy devices? After the scorecard and action-ownership rule pass. If correction or consent fails, fix the workflow first. Devices come from the TicNote collection or a quotation; this site does not take payment.
Pods or Lite? Do not decide from a method page. Open the TicNote collection or Equip my team and confirm the exact SKU. This guide will not rank them.
Request a scoped next step
If you want help designing the two-week pack — languages, destination, sample size, or a device shortlist after the workflow passes — contact CNPS or request a quotation. Share country, team size, languages and whether guests are external. For hardware after the protocol holds, use Equip my team or the TicNote collection. Purchases complete on shop.cnps.ai.