Draft a Coverage Clarification Request with AI at the Cursor

An insurance adviser can speak four verified inputs (policy reference, client question, wording reference and next step) plus a short task instruction. SpeakLingo's AI-at-the-cursor workflow is designed to turn them into a structured clarification-request draft at a compatible focused Windows text field, such as an email body. The adviser then reviews, corrects and sends it personally. The AI produces draft text only. It does not decide what a policy covers, and the adviser decides whether and when anything is sent.

This article covers what the request should contain, how to keep a client's question separate from confirmed policy terms, a worked example, a reusable template, a safe setup, a review checklist and a method for measuring time to reviewed output. The writing practices here are illustrative. They are not regulatory requirements or professional advice, and your firm's procedures and your own judgment set the standard. The template, review checklist and timing method are useful with any drafting tool, including typing the request yourself.

A clarification request goes to someone who can answer a question about a policy: an insurer's technical contact, an underwriter, a scheme administrator or a colleague with access to the full wording. It is easiest to answer when it carries only what the reader needs:

• Which policy. A reference the recipient can find without guessing.
• What is being asked. One question in neutral terms, attributed to the client where it came from the client.
• Where the wording sits. The clause, section or heading that seems relevant, plus the edition if known.
• What happens next. The response format you need and any date you have been given.
• What is unknown. Facts you do not yet have, stated as unknown.

A weak request mixes these together. It states the adviser's guess as if it were an answer, omits the wording reference, or buries the question in a story. The structure is simple but easy to skip when you are busy, which makes it a reasonable candidate for a repeatable spoken workflow.

SpeakLingo is built around Syping, the combination of speaking and typing. You can read the Syping explanation for the idea behind it. In this task, you speak the verified inputs and a short instruction, and the draft is written at the cursor. Where the supported cursor workflow fits your application, that can reduce copying and pasting between a separate AI window and your email or case note.

Three SpeakLingo capabilities apply:

1. Online transcription in 99+ languages. Your spoken inputs are transcribed in a supported language suited to you.
2. AI contextual formatting. Spoken fragments are shaped into a structured draft with a subject line, short sections and a clear request, instead of one block of run-on text.
3. Spoken AI text requests at a compatible focused Windows text field. You say the instruction, and the draft is aimed at the field you are working in.

You can see how these fit together on the features page, and other role-based scenarios are on the use cases page.

Some limits shape how you use it:

• Compatibility is not universal. Not every application or field will work, so test your email client or case system with a harmless dummy draft before depending on it.
• AI requests need an internet connection, an enabled service, your consent and the relevant access.
• Audio and text, and optional opt-in screen context, may be sent to remote services when AI features are used. Decide what to include with that in mind and follow your firm's rules on client information.
• AI output needs review every time.

A few minutes of setup keeps the draft in your hands until you decide otherwise.

1. Turn off automatic Enter or send behavior. SpeakLingo has an optional setting that presses Enter after text is delivered. In some apps that can send a message. Switch it off for email and case-note fields so nothing leaves your screen without a deliberate action from you.
2. Test in the exact field. Open a new message addressed to nobody, or a scratch note, and run a dummy request containing no client information. Check that the text lands in the right place.
3. Confirm online AI is ready. AI drafting needs connectivity, the service enabled, your consent and access. If any is missing, plan to use the template headings by hand.
4. Decide on screen context. It is opt-in. Keeping it off and speaking only the inputs the task needs is a reasonable default for client work.
5. Click into the field, then speak. Focus the email body or note, say the instruction and inputs, and wait for the draft.
6. Review the draft before you send. Read it fully, run the checklist below, add recipients and attachments, and only then send.

A note on how the AI request works: dictating alone does not switch AI on. Use the supported AI Task workflow, and put the instruction and every fact the draft needs into that same request. For this task that means the policy reference, the client's question, the wording reference and the next step. Earlier dictations, text already in the email field and whatever is on your screen are not automatically available to the AI, so a fact you leave out of the request cannot reliably appear correctly in the draft. The AI may flag the gap, but it may also fill it with an invented detail, so check every fact in the draft against your source documents and delete or correct anything they do not support. Screen context is a separate opt-in and may be sent to remote services, so leave it off unless you have decided it is appropriate for client work. Transcription has its own mode, setup and access requirements, so if AI is unavailable you cannot assume transcription is available, and the reverse also holds.

The most useful discipline in this task is labeling. A clarification request exists because something is unconfirmed, so the draft should not blur what the client believes, what you suspect and what the document says.

Use three labels in your head and in the draft:

• Client question: what the client asked, in their terms.
• Confirmed from documents: facts you have checked against the policy wording or schedule in front of you, such as a clause number and its heading.
• To be confirmed: anything that depends on the insurer's interpretation or on facts you lack.

Your own provisional view should not appear as a statement in the outgoing request. If you want to put it to the recipient, phrase it as a question: “Please confirm whether clause 5.3 applies to this situation” rather than “Clause 5.3 covers this.”

This matters when you speak the inputs, because spoken thinking tends to mix all three labels in one breath. Saying the label aloud (“client question…”, “wording reference…”) gives the AI a structure to follow and gives you a quick way to check the draft afterward.

The scenario below is fictional and uses no real people, policies or insurers. The draft shown illustrates the kind of output the workflow aims for. It is illustrative, not observed output from a test of the app, and real output will vary.

Before: unstructured spoken notes

An adviser dictates quickly after a client call:

“ok so this is for Mr Ellis, policy HOME-ILLUS-48213, he's asking about the leak under the kitchen sink, a slow one, does it count like a burst pipe. I think it's covered under escape of water, clause 5.3, but check. I need them to confirm, and I need to get back to him by end of next week.”

Problems with this as the basis for an email:

• The adviser's guess (“I think it's covered”) sits right beside the client's question.
• “End of next week” is not a calendar date.
• The wording edition is not mentioned.
• Nothing says when or how the leak was discovered.
• Nothing says what form of answer is wanted.

The spoken AI request

The adviser focuses the email body and speaks the instruction, following the template below:

“Using only these verified inputs, draft a coverage clarification request. Inputs: policy reference HOME-ILLUS-48213; client question, whether gradual leakage under a kitchen sink is treated the same as a sudden burst pipe; wording reference, escape of water section, clause 5.3, in the wording held on file; next step, ask the insurer to confirm in writing how the clause applies, and I need to respond to the client by a date I will add. Use a clear professional structure. Flag missing facts; do not invent them.”

The adviser leaves the “I think it's covered” opinion out of the spoken inputs on purpose, because it is not a verified input.

After: illustrative draft for review

Subject: Clarification request – Policy HOME-ILLUS-48213 – escape of water wording

Hello,

I am writing to request clarification on a client query relating to the policy above.

Client question The client has asked whether gradual leakage from beneath a kitchen sink is treated in the same way as a sudden burst pipe.

Wording reference The escape of water section, clause 5.3, in the wording held on our file.

Request Please confirm in writing how clause 5.3 applies to the situation described.

Information not yet available - Date the leak was discovered - Wording edition or version number - Our response deadline to the client [date to be added]

Thank you; I will await your written response.

Kind regards, [Name]

What the adviser still does

During review, the adviser:

• Adds the response deadline as a calendar date, or removes that line.
• Checks that the clause number and section title match the wording on file.
• Confirms the policy reference character by character.
• Checks that “gradual leakage” fairly restates the client's “slow” leak, and adjusts the wording if not.
• Decides whether the date of discovery is needed now or can be left out.
• Deletes any sentence that reads like a coverage statement.
• Adds the recipient and any attachments, then sends the email personally.

In this illustration the draft supplies structure and flags gaps, but a real draft may skip a gap or fill it with an invented detail. The adviser remains responsible for every fact in it.

Keep this as your standard spoken request. Replace the bracketed items aloud, using only facts you have checked.

Spoken instruction

“Using only these verified inputs, draft a coverage clarification request. Inputs: [Policy reference, question, wording reference, next step]. Use a clear professional structure. Flag missing facts; do not invent them.”

Input fields to speak

• Policy reference: the exact reference, spoken slowly or spelled out.
• Question: the client's question, stated neutrally, with “client question” said aloud.
• Wording reference: section, clause and edition if known. Say “edition unknown” if it is.
• Next step: what you want from the recipient and in what form, plus any deadline as a calendar date.

Output structure to expect and check

1. Subject line with the policy reference
2. One-sentence purpose
3. Client question
4. Wording reference
5. Specific request
6. Information not yet available
7. Closing and next step

If the draft comes back without a “not yet available” section even though you left something out, check whether the missing fact has been filled in with something invented. Then add that section yourself or make a fresh request with the gaps stated aloud.

Run through this before sending anything produced by an AI request:

1. Reference check. Policy reference, client name if used, and clause numbers match your source documents.
2. Attribution check. Everything the client said is labeled as the client's question or statement.
3. No coverage statements. The draft does not say, imply or hint that something is or is not covered, unless it accurately quotes confirmed wording and you intend it to.
4. No invented facts. Dates, amounts, circumstances, edition numbers and names all exist in your inputs. Delete anything else.
5. Gaps stated. Missing facts are listed as missing and have not been filled in with invented details, and placeholders are filled or removed.
6. Single clear ask. The recipient can tell what to answer and in what format.
7. Deadline accuracy. Any date is a calendar date, confirmed with whoever set it.
8. Information minimized. The message includes only what the recipient needs, in line with your firm's handling rules for client information.
9. Tone. The wording is courteous and neutral, without pressure or argument.
10. Recipient and attachments. The address line, copied parties and attachments are correct before you send.
11. Record. The final sent version, and the reply when it arrives, are saved wherever your firm keeps correspondence.
12. Client communication. Nothing from the draft goes to the client as advice until you have the confirmed answer and have reviewed it yourself.

Whether this workflow helps is a question for your own work, so measure it against your current method. The useful measure is time to reviewed output: the time from starting a request to having a version you are willing to send.

A simple way to do it:

1. Pick a comparable set of requests. Choose several ordinary clarification requests, leaving out the unusually complex ones.
2. Define the start. For example, the moment you open a blank message or begin speaking the inputs.
3. Define the end. The moment you have reviewed, corrected and approved the text. The first draft is not the end point.
4. Include the extra steps. Count time spent fixing references, rewording and adding missing facts. Include time spent switching windows or copying text if your current method involves it.
5. Record both methods. Time some requests with your existing method and some with the spoken workflow, in the same period and with similar complexity.
6. Compare typical results. Look at the middle of the set, and note any outliers and why they happened.
7. Note edit load. Keep a tally of what you corrected most often (dates, labels, tone). That tells you how to adjust your spoken inputs.

If review and correction take as long as writing the message yourself, the workflow may not suit that request type. That is a useful finding.

Online transcription supports 99+ languages, so you can speak your inputs in a supported language that suits you. This describes transcription only. It does not translate your message, and it makes no promise of AI output in every language. If you correspond with an insurer in a different language from the one you dictate in, check the draft carefully and make language decisions yourself.

AI requests depend on being online, on the service being enabled, and on your consent and access. If your connection drops and you have already configured it, offline English transcription with a local runtime can serve as a fallback for getting words down. AI drafting does not work offline, so structure the message by hand using the template headings above until connectivity returns.

Because audio, text and optional opt-in screen context may be sent remotely when AI features are used, decide in advance what you are comfortable including. Turning on screen context is your choice, and keeping inputs to the minimum the task needs is a sensible default.