We sell our SaaS to companies. Their employees are the ones who need to trust us.
One of the strangest product problems I've encountered while building a B2B SaaS is this:
the person paying for the product is not necessarily the person who needs to trust it the most.
I'm building Sigilo Profissional, a platform for employee feedback, organizational climate, and anonymous whistleblowing.
Our customer is the company.
But when someone needs to report harassment, fraud, discrimination, or misconduct, the actual user is an employee.
And that employee may be reporting the exact organization that pays us.
That creates a very different product dynamic.
The buyer and the user want different things
The company usually cares about things like:
- compliance
- case management
- auditability
- reporting
- risk reduction
- access control
- organizational visibility
The employee cares about something much simpler:
"Can this come back to me?"
That question changes everything.
A company can buy a technically perfect reporting system.
But if employees do not trust it, the product has failed.
This was one of the biggest mindset shifts for us.
We initially thought we were building a compliance tool.
We slowly realized we were building a trust product.
Trust changes product decisions
This sounds abstract until it starts affecting the roadmap.
For example, from a traditional SaaS perspective, collecting more data is usually useful.
More analytics.
More logs.
More user information.
More context.
But in an anonymous reporting system, every piece of information you collect can become a reason for the user not to trust you.
So instead of asking:
"What else can we collect?"
we started asking:
"Do we actually need this data?"
That influenced decisions around IP logging, accounts, email addresses, access control, file uploads, and how users return to a report.
Some of those decisions make the product harder to build.
But if removing friction for the company creates fear for the employee, we are optimizing for the wrong user.
The weirdest metric: zero reports
Another thing surprised me.
Imagine a company implements an anonymous reporting channel.
Six months pass.
Zero reports.
At first glance, that sounds great.
Maybe the company has an amazing culture.
But it can also mean:
- nobody knows the channel exists
- nobody believes it is anonymous
- employees fear retaliation
- nobody believes anything will be investigated
- the product is too difficult to use
So "number of reports" by itself is a terrible success metric.
In fact, the first sign that the product is working may look negative:
more problems start appearing.
But the software did not create those problems.
They were already there.
The product simply made them visible.
This is a very strange dynamic when you're used to SaaS metrics where "more activity" is almost always interpreted as positive.
We also discovered that privacy is part of marketing
Normally, engineering decisions stay behind the product.
Users do not care what database you use.
They do not care how your authorization system works.
They should not have to.
But privacy-sensitive software is different.
If we tell an employee:
"Your report is anonymous."
they have every reason to be skeptical.
So some technical decisions need to become part of the product communication.
For example:
"We don't store your IP address."
That is an infrastructure decision.
But it is also a trust signal.
This changed the way I think about marketing privacy products.
You cannot just say:
"Trust us."
You need to explain enough about the system for the user to understand why they should trust it.
B2B software can have two very different customers
This is probably the broader lesson I've taken from the experience.
In many B2B products, the buyer and the end user are different people.
But usually their incentives are at least roughly aligned.
With anonymous reporting, that alignment is not guaranteed.
The company wants visibility.
The employee wants protection.
The company wants useful information.
The employee wants to reveal as little identifying information as possible.
The company wants accountability.
The employee may fear exactly what happens if the wrong person gains access.
Our job as the product team is to build a system where those interests can coexist.
And that has been much harder — and more interesting — than simply building another dashboard.
The question I'm still thinking about
I've started wondering how many other B2B SaaS products have this same hidden problem.
The buyer pays, but another group ultimately decides whether the product works.
HR software.
Healthcare.
Education.
Security.
Internal feedback tools.
Maybe even some fintech products.
If you're building B2B:
How different is your buyer from your actual end user?
And have you ever had to make a product decision that was worse for the buyer experience, but necessary to earn the user's trust?
Would love to hear examples.
This is a fascinating trust asymmetry. In most B2B SaaS, the buyer and the user are at least broadly aligned. Here, the product only works if the employee believes the system can protect them even when that creates risk for the paying customer.
That makes privacy, auditability and perceived independence part of the product itself, not just compliance features.
The “zero reports” metric is a great example of outcome metrics needing trust context. Have you considered measuring anonymous funnel completion or return-to-case rate as leading indicators?
Appreciate the honesty here, most people only share the wins.
We face a lighter version of this gap at UtilitySEO. The person who runs an SEO scan is often a consultant or agency, but the invoice goes to the business owner. Different incentives for the same tool — the consultant wants depth and technical detail, the owner wants a score and a fix list.
"Privacy decisions become marketing decisions" is the insight that took us longest to learn. We chose no signup for our free scan partly as a trust signal — if we do not ask for an email before showing results, the implicit message is that we trust the product to convert on its own. Engineering decision, but it does more marketing work than any landing page copy.
The zero-reports paradox is the clearest sign you are building for the right user. Would the company prefer zero reports because it looks good, or real reports because it reduces actual risk? That question answers who the product really serves.
The person paying and the person who needs to trust it being different is a sharp way to frame it. For reporting tools, 'Can this come back to me?' really is the whole product.
Really good writeup, thanks for sharing it. What's the next thing you're planning to try here?
Have you seen any employee behavior that clearly changes when trust signals are strengthened—more reports, greater completion, or willingness to return to an existing case?
The zero-reports point generalises: a silent channel and a healthy one look the same on the dashboard, so the useful number is form opens vs. submissions, counted in aggregate with no identifiers. Lots of opens and almost no sends is the trust gap, measured.
On making privacy claims believable: "we don't store your IP" lands better when it's specific and checkable, like a short list of exactly what gets stored per report, shown on the form itself. A claim people can inspect beats one they have to take on faith.
Appreciate the honesty here, most people only share the wins.
Interesting approach. What was the hardest part to get right?