Calculator consent and follow-up
Calculator Consent Evidence Matrix for Lead Follow-Up
A purpose-by-channel evidence matrix for calculator results, requested delivery, sales contact, marketing follow-up, CRM context and withdrawal.
Direct answer
Do not treat calculator completion, contact capture and marketing consent as one event. Define each purpose and channel separately, record the notice and choice the person saw, deliver the requested result without bundling unrelated promotion, and propagate withdrawal to every system using the affected permission. The responsible organisation must choose and document the applicable lawful basis for its jurisdiction and context.
Definition
A calculator consent record is evidence of a specific person's affirmative choice for a defined purpose and channel at a known time, tied to the notice version and an available withdrawal path. It is not merely an email address, a completed result or a preselected checkbox—and consent is not automatically the correct lawful basis for every operational use.
Key findings
Verified 14 October 2026
- Calculator completion, requested result delivery, requested sales contact and promotional follow-up are separate events; one generic consent boolean cannot describe them accurately.
- Where consent is used, the record needs the purpose, channel, wording or notice version, affirmative state, event time, source and current withdrawal status.
- A preselected marketing control or missing notice/timestamp is not reliable consent evidence, and an unchecked optional control must not trigger marketing.
- Withdrawal should suppress the affected purpose and channel downstream without erasing other bounded records that have a separately documented purpose or obligation.
Why separate calculator results from follow-up consent?
A visitor may calculate a result, request a report, ask for a sales call or opt into product updates. Those actions have different purposes and expectations. A single field such as `consent=true` cannot explain which channel, notice, purpose or version was accepted.
CALCULATOR-CONSENT-EVIDENCE-MATRIX
What evidence belongs in a purpose-by-channel matrix?
Start with the promised user action, then identify the narrow evidence needed to prove or operate it. Do not infer promotional permission from a result request, required contact field or CRM record.
| Purpose | User action | Evidence to retain | Do not infer |
|---|---|---|---|
| Show an on-screen result | Complete valid inputs | Calculator and formula version | Marketing permission |
| Send a requested result | Explicitly request delivery | Address, request time and notice version | Ongoing promotional email |
| Request a sales call | Ask to be contacted | Channel, topic, time and routing state | Consent to unrelated campaigns |
| Email marketing | Make a separate affirmative choice where required | Wording, state, time, source and withdrawal status | Permission from a required calculator field |
| CRM qualification | Complete a documented operational workflow | Needed inputs, result band, source, basis and retention rule | Unlimited reuse of every answer |
What should a calculator-native evidence record contain?
Store an immutable completion ID; calculator and formula versions; result and qualification band; purpose identifier; selected channel; notice and control version; event time; source page; documented basis; and current withdrawal or suppression state. Keep data needed to prove the decision, not an unrestricted screenshot or payload containing unnecessary personal information.
Use one stable event identity across the calculator, native CRM, email workflow and connected destinations so retries do not create a second logical permission event.
What did the twelve deterministic decisions test?
The fixtures execute this editorial decision contract. They do not select a lawful basis for a real organisation or test a named consent platform. All twelve returned the expected decision on 14 October 2026.
| ID | Scenario | Expected decision |
|---|---|---|
| C01 | Result displayed without contact data | Show result; create no marketing permission |
| C02 | Email requested only for a PDF | Deliver the requested artifact only |
| C03 | Optional marketing box unchecked | Do not enrol in marketing |
| C04 | Marketing box preselected | Treat as invalid consent evidence |
| C05 | Separate email marketing choice selected | Record purpose, wording, time and source |
| C06 | Person requests a sales call | Route that request only |
| C07 | CRM receives result and qualification | Retain bounded operational context and rule |
| C08 | Notice version missing | Block marketing enrolment and investigate |
| C09 | Consent timestamp missing | Treat evidence as incomplete |
| C10 | Withdrawal received | Suppress the affected purpose and channel downstream |
| C11 | New unrelated purpose proposed | Obtain a new valid basis or do not reuse data |
| C12 | Duplicate webhook arrives | Keep one logical event by completion ID |
Worked example: requested PDF plus optional updates
A fictional savings calculator shows its result immediately. The visitor then asks for a PDF by email and separately chooses monthly product updates. The system creates one completion record, one requested-delivery event and one email-marketing permission event with the exact notice version.
If the visitor later unsubscribes from product updates, the marketing purpose is suppressed in the native CRM and any connected sender. The bounded PDF-delivery history is assessed separately under its documented purpose rather than being mislabeled as continuing marketing permission.
How should consent controls be made accessible?
Use a visible label that names the purpose and channel. Do not preselect optional marketing. Put overall instructions before the form, identify required and optional fields in text, and associate field-specific instructions with their controls. Placeholder text is not a replacement for a label.
Keep choices keyboard-operable and understandable without color. When validation fails, identify the affected field and describe the correction in text.
Calculator consent release checklist
Release only after the visible choice, stored evidence and downstream behavior match.
- List every purpose and delivery channel separately.
- Document the applicable lawful basis selected by the responsible organisation.
- Preserve the notice, control and calculator versions with the event time.
- Do not block a promised result on agreement to unrelated marketing.
- Send only data required by the destination's documented purpose.
- Make withdrawal easy and propagate it to native and connected systems.
- Reconcile duplicate, delayed and failed events by stable completion ID.
- Set retention rules by record type instead of keeping every answer forever.
Verification and correction path
Sources and all twelve deterministic decisions were checked on 14 October 2026. The ICO marks its consent guidance as under review following the Data (Use and Access) Act, and its direct-marketing guidance records an update on 28 April 2026. Recheck the current law, jurisdiction and channel before implementation. If a scenario appears wrong, use the correction form and include the purpose, channel, audience, jurisdiction and affected evidence field.
Method and evidence
Evidence type: Purpose-by-channel evidence matrix, versioned record contract, withdrawal flow and twelve executed deterministic decisions
- Separated on-screen results, requested delivery, requested sales contact, marketing, CRM qualification and withdrawal into distinct purposes and channels.
- Defined the evidence needed for each decision without treating a completed calculator or captured address as blanket marketing permission.
- Executed twelve deterministic decisions covering optional controls, preselection, notice and time evidence, withdrawal, new purposes and duplicate events.
- Rechecked current ICO and W3C guidance while disclosing that the ICO consent guidance is under review following the Data (Use and Access) Act.
Topic score: 4.58 / 5. Business fit 4.8, verified demand 4.2, distinct intent 4.7, original evidence 4.8, citation usefulness 4.6, feasibility 4.5.
Primary sources
- ICO: What is valid consent? ↗UK regulator guidance for freely given, specific, informed and unambiguous consent; marked under review following the Data (Use and Access) Act; checked 14 October 2026.
- ICO: Obtain, record and manage consent ↗UK regulator guidance for consent requests, records, management and withdrawal; marked under review; checked 14 October 2026.
- ICO: Direct marketing guidance ↗Current UK direct-marketing planning, collection and preference guidance; page records a 28 April 2026 update; checked 14 October 2026.
- W3C WAI Form Instructions ↗Primary accessibility guidance for required and optional instructions, labels, formats and assistive-technology-readable help; checked 14 October 2026.
Limitations
- This matrix is an implementation and evidence model, not legal advice or a decision about the correct lawful basis.
- Requirements vary by jurisdiction, channel, audience, existing relationship, data category and sector; qualified review may be required.
- The ICO consent guidance was under review on the verification date following the Data (Use and Access) Act and may change.
- The examples use email and CRM concepts but do not test a named calculator, consent platform, sender, CRM, browser, assistive technology or production dataset.
- The twelve fixtures validate the published decision order, not legal compliance or conversion performance.
Verification and corrections
Current ICO consent and direct-marketing guidance, W3C form instructions and twelve deterministic purpose-channel decisions verified 14 October 2026.
Recommended retest: Recheck after any jurisdiction, audience, lawful-basis, notice, channel, CRM, sender, retention or withdrawal-process change.
Found an error or a changed standard? Use the correction process and include the page URL and primary evidence.
Next step
Apply the evidence to your next release
Use the published method, keep a dated test record and revisit the result after the calculator or its operating rules change.
Open the testing protocol