Five rules for a product its customers never chose to study

Most of our customers have no security specialist. The person who reads an alert is usually the owner, an office manager or an outside IT partner paid by the hour. I design each alert around one question: what should this person do next? Every message in our library has a plain-language headline, the evidence behind it, a recommended action and a statement of what happens if nobody responds. Writers and analysts review the wording together, and we test new messages with owners before release. We measure acknowledgement within 24 hours rather than clicks or time spent in the dashboard. A small firm spending longer in our product would usually mean we had confused it. I also retire alerts that rarely lead to action, because every unnecessary warning weakens the next important one.

Small customers react to the shape of a price as much as its level. A per-user minimum that suits a forty-person firm can make a four-person practice pay for empty seats. Our three tiers, Essentials at €3.50, Standard at €6.50 and Complete at €10 per user each month, sit beside a flat Micro plan at €39 for up to eight users. I own packaging and pricing proposals jointly with our chief financial officer, who owns the revenue forecast. Partner economics belong in every change, because about 940 IT firms resell us and handle first-line support. I model what a partner earns per customer and how much support a cheaper plan will create. A lower price that drives partners away from the smallest firms would not serve those firms.

Our owner dashboard, alert emails and partner console are designed against the European standard for accessible ICT that public buyers commonly reference, which incorporates the web content accessibility guidelines. The European Accessibility Act applies mainly to specified consumer products and services, and our business service may sit outside its direct scope. Many of our customers fall within it, however, and their staff include people who use screen readers, magnification or keyboard navigation. We pay a panel of eleven testers who use assistive technology to work through our main tasks every quarter. A release that blocks one of those tasks does not ship, including releases already promised to a partner. I broke that rule once, for the assistant panel in 2025, and the case on this site records what it cost.

A security product sees a great deal about employees: who clicked a simulated phishing message, whose laptop is out of date, which accounts sign in from abroad. The employer pays for the service, but staff are data subjects with their own rights under European data-protection law. With our data-protection officer, I set defaults around that tension. Phishing-exercise results reach employers in aggregate unless the customer records a training purpose and informs staff; individual results are then visible only to the employee and one named administrator, and are deleted after twelve months. We collect the minimum alert metadata needed to explain an event. When partners asked for a ranking of the 'riskiest employees', I declined to build it. Employment rules differ across our three countries, and a ranking invites uses we cannot see.

Our automated assistant explains alerts in Portuguese, Spanish and English and drafts a message an owner can send to staff. It cannot dismiss, close or alter an alert, and it covers only fourteen alert types for which analysts have written playbooks. I agreed those limits with the chief technology officer and the alert desk before release. The model runs in an EU region under a processing agreement and receives alert metadata, not message content. Each explanation is labelled as automated, and Complete customers can ask a human analyst instead. We publish a limits page listing what the assistant does not do and the error rate we measured before launch. I would rather a customer learn those limits from us than discover them during an incident, when a wrong instruction costs most.