The SMARTFENSE demo end-to-end: what gets measured and what you get

Mesa de control con varios paneles que muestran la misma operación desde distintos ángulos, como metáfora de una demo que recorre el programa de concienciación de principio a fin.

The SMARTFENSE demo end-to-end: what gets measured and what you get

Choosing a security awareness platform from a sales deck leaves too many open questions. An end-to-end demo answers what a slide can’t. It shows how the platform behaves with a scenario close to yours, which metrics you’ll be able to report afterward, and what stays in your hands once the walkthrough is over.

In its 2024 Data Breach Investigations Report, Verizon found that the human element was involved in 68% of breaches analyzed, exactly the ground a security awareness program works on. If the risk concentrates there, the decision of which platform to use to reduce it deserves to be evaluated with evidence, not intuition. This piece walks through the SMARTFENSE demo from start to finish: what gets configured, what gets measured, and what gets delivered.

What is an end-to-end demo of an awareness platform?

An end-to-end demo is a full walkthrough of the platform using a scenario representative of your organization, from enrolling a group of employees to reading the results of a simulation and a training module. It links every part of the program in a single flow, instead of showing isolated screens out of context.

The difference with a catalog demo is practical. A catalog demo shows features in isolation: here’s the campaign editor, here’s the report, here’s the content library. An end-to-end demo puts them in sequence, which is how they’ll actually run the day the program is in production. For anyone evaluating the tool, that sequence is what reveals whether the pieces fit together or whether each one solves its own part well while the whole leaves gaps.

What gets measured during a SMARTFENSE demo?

The demo measures the same indicators that hold up a real program, applied to the test scenario: phishing simulation click rate, report rate, training completion, and how risk evolves by group and by employee. These are the metrics you’ll later have to defend in front of leadership, so it’s worth seeing them in motion from day one.

Concretely, a well-built demo lets you see:

  • Click rate and report rate in the simulation. The count of who fell for it isn’t enough; what matters is how many recognized the email and reported it, because that’s the behavior the program sets out to build.
  • Completion and performance in the training assigned after the simulation, to understand whether the content connects with the employee or gets abandoned halfway through.
  • Segmented risk by department, site, or role, not a global average that hides the most exposed groups.
  • Export and programmatic access to that data. SMARTFENSE exposes its metrics through an API, so reporting isn’t locked inside the platform; we cover that flow in how to bring your SMARTFENSE metrics into real time with APIs.

These are also the metrics that end up in a board meeting. Translating those numbers into a narrative the board understands is something we tackle in board-level reporting: the steering committee in two minutes.

What do you get when the demo is over?

When it’s done, the organization walks away with four things: access to the test environment for a limited time, the set of metrics from the scenario you ran, a configuration proposal tailored to your reality, and a rollout plan. The idea is that the decision doesn’t rest on the memory of a meeting, but on concrete material you can review internally.

The configuration proposal is the part that tends to be underestimated. It captures the decisions that matter in a real deployment: which content catalogs apply to your sector, which languages the program will communicate in, which integrations come into play (corporate directory, SSO via SAML or OpenID Connect, connectors to the rest of the stack), and how the platform takes on your company’s brand. Each of those choices changes the effort to go live, and it’s better to see them before signing than after.

When the scenario allows, we also share results from organizations with a similar profile. We publish them in case studies, because a metric from your own test environment carries more weight when it’s set against what other teams achieved in production.

A diagram of a five-stage journey, connected from enrolling a group to the rollout plan, on a work surface in technological tones.

What does the demo process look like step by step?

The process follows five chained stages, designed so each one feeds the next:

  1. Discovery. A short conversation to understand the size of the organization, sector, languages, the maturity of the current program, and which integrations exist. Without this, the demo shows a generic scenario that speaks to no one.
  2. Environment setup. A space is prepared with a group of test employees, the relevant catalogs and, where it applies, the organization’s brand. At this point you already see how the platform feels with data close to the real thing.
  3. Execution. A phishing simulation is launched and the associated training is assigned to the employee who interacts with it. This is where the program “happens” instead of being explained.
  4. Reading the metrics. The dashboards are walked through with the scenario’s results: click rate, report rate, completion, and segmented risk. If choosing a tool is part of the process, it’s worth cross-checking these numbers against a clear evaluation framework, like the one we lay out in honest criteria for choosing a phishing simulation tool.
  5. Rollout plan. It closes with the configuration proposal and the steps to move from the test environment to production, including integrations and timeline.

The full walkthrough usually fits into one or two sessions. The actual duration depends on how many integrations you want to see working live during the setup stage.

How is a demo different from a pilot?

A demo is a guided, contained walkthrough over a test scenario; a pilot is a real, limited deployment with a subset of your own employees, your own data, and a window of several weeks. The demo answers “how does it work and what does it measure?”; the pilot answers “what happens with my people?”.

SMARTFENSE offers both paths because they resolve different decisions. The demo is enough when the team needs to understand the flow, validate the integrations, and see the metrics in motion. The pilot makes sense when the organization wants to measure behavior across its own population before committing to a full deployment, for example to estimate the baseline risk or to win over leadership with internal data. If you’re still defining what to prioritize when evaluating, the decision framework for choosing an awareness platform helps order the criteria before requesting either one.

In both cases, the logic is the same one SMARTFENSE stands behind as a platform. The evaluation rests on what gets measured, not on what gets promised. You can see the full functional scope on the platform or arrange a walkthrough at /demo/.

Frequently asked questions

How long does a SMARTFENSE demo take?
One or two sessions. The core walkthrough (discovery, setup, execution, and reading the metrics) fits into one session; adding integrations working live may call for a second.

Do I need to connect my directory or my systems for the demo?
Not for the standard demo, which runs on a test environment. Connecting the corporate directory, SSO, or the rest of the stack is shown when you want to validate those integrations specifically, or it’s reserved for the pilot.

Which metrics will I be able to see?
Click rate and report rate in the simulation, training completion and performance, and risk segmented by group and by employee. All of it exportable and accessible through an API.

Does the demo use my organization’s data?
The demo works on a representative test scenario. When you need to measure across the real population, that’s the role of the pilot, which is scoped to a subset of your own employees.

What do I take away when it’s over?
Temporary access to the environment, the metrics from the scenario you ran, a configuration proposal tailored to your organization, and a rollout plan toward production.

Mauro Sánchez

CTO de SMARTFENSE, lidera los equipos de ingeniería y desarrollo. Especialista en materia de ciberseguridad e infraestructura, siendo el encargado de definir y concretar las integraciones y alianzas tecnológicas estratégicas de SMARTFENSE con diferentes soluciones. Más de 20 años avalan su experiencia en la toma de decisión e implementación de medidas de seguridad y tecnología.

Leave a Reply