Question handling
What a support assistant may say about how you handle data
The person typing this is not a customer with a problem. They work in procurement, security or legal at a company evaluating you, and they found the chat widget because it was faster than emailing sales. Everything the assistant says here is a statement by your company about its security posture, made to somebody who is writing it down.
What they are really asking
They are working out how much internal friction buying from you will cause, and whether the answers exist in writing or will have to be extracted.
- where is our data stored
- are you soc 2 compliant
- do you have a dpa we can sign
- who are your subprocessors
- is data encrypted at rest
- can you complete our security questionnaire
- do you carry out penetration testing
- how long do you retain customer data
- can we see your latest audit report
- are you gdpr compliant
The material that answers it
An assistant is only as good as the document behind it, and for this question the document usually exists but is written in the wrong shape. What each one has to contain to be answerable:
| A trust or security page you are willing to stand behind | The only material that should be indexed for this intent. Everything on it is a public commitment, which is the correct bar: if a sentence is not one you would sign, it should not be on the page and therefore cannot be repeated by an assistant. |
|---|---|
| A subprocessor list with a change notification commitment | Who else touches customer data, in what role, and where. Buyers ask because their own contracts require them to, and a maintained list turns a two week email thread into a link. |
| Your data processing agreement | Available to read before signature rather than on request. Publishing it removes a step from every procurement process and lets the assistant answer the question rather than take a message about it. |
| Certifications actually held, with scope and dates | Independent audit reports and certifications are sales artefacts with a defined scope, an assessment period and an expiry, and they are issued after a review process rather than claimed. Publish which ones exist, what they cover and when they were issued. Never publish a claim of compliance with a framework you have not been assessed against, because the assistant will repeat it word for word. |
| Retention and deletion timelines | How long data lives after a contract ends, what deletion means operationally, and whether an export is available first. This appears in nearly every questionnaire and is one of the easier ones to answer definitively. |
How to handle it
Decide what is publishable before you index anything
This intent is unusual in that the content work comes entirely first. An assistant reading an internal policy document will answer from it, and internal security documentation is written with a candour that is appropriate internally and damaging externally.
Index the public trust page and nothing else. The test for a sentence belonging on that page is whether you would put it in a contract.
Answer word for word, not in your own words
Security answers get pasted into questionnaires and sometimes into contracts. A paraphrase that tightens a hedge, drops a scope limitation, or upgrades regularly reviewed into continuously monitored has changed the commitment.
Because every answer carries numbered citations back to the source, the buyer can see which page a sentence came from. That is worth more here than anywhere else in support: it converts an assistant's answer into a pointer at a document, which is exactly the status it should have.
Refuse on anything you have not published
If the trust page does not mention penetration testing, the correct answer is that it is not published and here is who to ask. Not a general reassurance about taking security seriously, which sounds like an answer, gets recorded as one, and is a claim your company now owns.
Run this intent cautiously. The cost of a refusal is one email to a person who was going to email somebody anyway. The cost of an improvised claim is a representation made to a buyer during due diligence.
Route the questionnaire itself, with the deal context attached
Nobody completes a spreadsheet of two hundred controls through a chat widget. What the assistant can do is answer the handful of questions gating the conversation, then collect the company name, the person's role and what they need, so the reply comes from somebody who knows whether this is a small account or a six month procurement.
When it stops being an answer
The questionnaire document itself
Any request to complete, review or sign something. That is a sales and security workflow with a named owner, and the widget's job is to get it there with enough context that the first reply is useful.
Requests for audit reports or test summaries
Independent audit reports and penetration test summaries are normally released under an agreement, and sometimes only to prospects at a certain stage. The release decision belongs to a person. The assistant should say that a report exists, if one does, and route the request.
Any request for an exception or a bespoke term
A specific data location, a deletion timescale different from the published one, an extra contractual commitment. These are negotiations. An assistant that produces something sounding like agreement has created an expectation somebody else has to withdraw.
How this one goes wrong
The improvised claim that becomes a representation
The assistant is asked whether data is encrypted at rest, finds nothing specific, and produces a sentence assembled out of a marketing page about taking security seriously. It sounds correct. It is pasted into a vendor assessment. Months later it is the sentence somebody points at.
The cost is not embarrassment, it is a claim about your controls made in your name to a buyer who relied on it. The defence is entirely in the setup: publish a trust page, index only that, run the caution level high on this cluster, and write a fallback that names the person who handles security review rather than apologising.
The same question, trade by trade
The pattern above holds everywhere. The wording, the escalation line and the material behind it do not, so there is a page per trade.
- For a medical practicePatients ask who their data is shared with; organisations send the practice assurance forms. Neither is answered by improvising.
- For a law firmPanel onboarding, outside counsel guidelines and data terms come from a client's buyers, not from consumers, and none can be agreed in a chat.
- For a accounting firmAssurance questions arriving from a client's own auditor or biggest customer, and why the assistant may only point at what is published.
- For a insurance brokerThe form and the request for the broker's own cover arrive together and are different documents. Neither is answered in chat.
- For a mortgage brokerIntroducers vet the firms they refer to. The questions are about payslips, statements and identity documents sitting together in one place.
- For a recruitment agencyProcurement wants to know how a recruiter stores identity documents and worker records. Only published answers, because each one is a commitment.
- For a marketing agencyAgencies process customer data for clients. What the assistant can answer from a published position, and where a person has to commit the firm.
- For a online courseA small training purchase can attract a full vendor assessment. What a course business can answer from published pages, and what it cannot.
- For a SaaS companyMid deal a buyer's security team pastes control questions into chat. What can be cited, and why the spreadsheet stays somebody's job.
- For a developer tools companyAudit logs, retention windows and release provenance. What can be answered from published trust material, and which rows need an agreement.
- For a fintech appA corporate assessment and a nervous customer arrive in the same box. Neither is served by being answered as the other one.
- For a healthtech appHealth buyers run governance review first. What can be cited from the impact assessment, the data flows and the retention schedule.
Questions
- Should a support widget answer these at all?
- For the published facts, yes, and it saves a genuine amount of time on both sides. For anything not on your trust page it should refuse and route, because this audience writes down what you say.
- What stops it inventing a certification we do not hold?
- It answers only from the material you index, and below the match threshold it returns your fallback message without reaching the model at all. If the certification is not in your material there is nothing to retrieve, and a cautious setting means it refuses rather than reaching for an adjacent page.
- Can we index our internal security policy so it answers more?
- You could, and you should not. Internal policy documents describe controls, exceptions and known weaknesses in language written for colleagues. Index the public commitment and keep the internal document out of the retrievable set.
Keep reading
- Handling password resetsAn assistant cannot reset anything. It can walk somebody through your real flow and name the step that usually breaks.
- Handling account access problemsLocked out, wrong email, a colleague who left, no admin remaining. Identity cannot be checked in a widget, so explain, collect, hand over.
- Handling data deletion requestsA deletion request is a request with a clock on it, not a question. The characteristic failure is silence, so it always has to reach a person.
- Every question typeHandling patterns for the questions every support inbox gets.
Try it on your own material
Upload a document or point it at your site, paste one line of HTML, then ask it something only your business could answer.