What a campaign stores, in plain English

Customers use an email address and password to manage their organisation. We store their account email and verification state, a salted password hash (not the password), organisation membership, organisation defaults, and security metadata for expiring verification/reset links, bounded authentication rate limits and revocable sessions. Transactional email delivers account verification and password reset links. These accounts are separate from internal staff access and from anonymous campaign participation; no customer identity is added to participant observations.

Customer authentication uses its own secure browser cookie. Verification and password-reset links are single-use and expire; signing out revokes the customer session. Customer account and report retention policy is still being determined. No permanent report availability is promised.

• Observation text and type (Whinge, Nice Try or Praise), the appropriate follow-up fields, frequency and suggestions, language, submission state, creation/finalisation times and reviewed process memberships.
• The site named by the campaign QR/link, where a campaign uses sites. The site belongs to each observation, not to a person's identity. Reports apply a site participation privacy floor and contextual review.
• Optional process timing: real UTC start/end timestamps, status and completed duration. When you start a timer, we also store your device’s UTC offset at that moment to preserve its local start-time display. This does not request location permission or determine your site. Overlap, overnight, extended and unfinished classifications are derived for analysis. Participants see running starts and controls, not durations or analytical flags.
• A random campaign-specific participant reference and authenticated browser cookie, issue time, introduction-seen state, and follow-up eligibility/completion state. No employee account is required.
• Separate campaign-level questionnaire answers and an optional comment. The response record has no participant reference or precise submission timestamp; a completion flag prevents a second response. Small numbers, completion state or storage order can still permit inference; separation is not a guarantee against attribution by elimination.
• Submission keys and keyed request digests bind retries to their original observation and prevent accidental duplicates. Withdrawal erases words, timings and the content digest; a minimal receipt and empty withdrawal record support truthful recovery.
• Bounded campaign/session admission counters, server-side submission timing and keyed content-pattern signals, temporary protection state, and campaign-level integrity event counts. These are kept separate from process evidence and are not individual customer histories.
• Campaign and customer settings: organisation name and staff notes, campaign name, dates and closure, participant capacity, site names/references, public links, branding and optimised uploaded customer logos stored by Whinge. Original uploads and unnecessary image metadata are not retained. An organisation logo can be reused for later campaigns; each campaign keeps its own copy. Older URL-based logos continue to be served through Whinge, never hotlinked by participant browsers. Technical records include schema versions and restricted operational error information.

These are the categories the application uses to run and report a campaign. This is a summary of application data, not an exhaustive account of hosting-provider infrastructure records.

Relevant participant text is sent to the configured AI service to organise related process evidence, propose synthesis and check draft findings. Initial grouping receives text, field roles and stable evidence references, without participant identity, location or timing metadata. Later phases receive only the evidence and reporting context needed for that task. Whinge calculates counts, privacy groups and timing facts; human review precedes release.

Restricted records include evidence snapshots, model and prompt versions, phase inputs/outputs, validation results, review decisions and API usage. These are separate from customer reports. Service-provider processing terms and final retention arrangements must be verified before deployment; this summary does not promise a particular provider retention policy.

• Employee names, email addresses, phone numbers, employee numbers or organisational rank are not requested. Free-text answers or customer-entered content can nevertheless identify someone.
• Employee accounts, job titles or team names taken from an HR system. Nothing is imported from a payroll, HR or directory system.
• The application does not collect IP-based participant identity, device fingerprints, precise location, typing cadence, mouse movement or behavioural biometrics. It does not link observations to these signals.
• Participant identifiers are not reused across campaigns. Customer organisation settings may be shared; participant identities are separate.
• An individual's working time. A timing belongs to a process observation. The anonymous campaign identity lets its author manage it, but there are no individual employee time reports.

Answers are held in a managed database, not on the employee's phone and not in an email inbox. Our production database is in the UK, and a campaign's data sits there. There is no per-campaign region setting.

In the browser, the campaign page sets one cookie per campaign to hold the anonymous session. Your anonymous campaign identifier remains on this browser until the campaign's short follow-up period ends. It is not reused in another campaign. A form may temporarily keep only its outstanding submission key in session storage to recover from a reload; it does not store your words or credentials there. There are no advertising cookies and no analytics that follow a person on this site or on a campaign page.

The organisation running the campaign decides what happens to the answers it receives: who reads the appraisal, who it is shared with, and what is done about it. We provide the campaign tool and hold the data for that organisation while the campaign runs.

Completed campaign reports are stored privately as generated documents. Generation, review and release are separate. Every view and download requires customer sign-in and organisation membership. Notification emails contain a portal link, not participant text or report attachments. Report records support expiry and removal; final retention periods remain to be agreed.

A campaign is a temporary exercise. It closes on the date it was set, no more answers can be sent after that, and no campaign becomes a standing record of a workplace.

We have not published a retention period, and we are not going to invent one on a public page. The retention policy is being written, and it will state how long a campaign's answers are kept after the window closes and how they are deleted. Until it exists, do not treat this page as a statement about deletion.

• There is no certification, accreditation or compliance badge on this site, and none is claimed. The work needed before a commercial launch, including the parts that need professional review, is not finished.
• Nothing here is legal advice, and nothing here is the formal data-processing terms for a customer.
• No employee name is requested, but free text can contain names or identify its author. That limit belongs in any honest summary of the data, so it is stated on the anonymity page and in the appraisal.

If you have a question about data before running a campaign — where it would sit, who could see it, or what a campaign would not hold — ask us. Answering it is part of selling the thing honestly.

Contact support