Tally

Tally watches for IT friction employees never report, diagnoses the real cause, fixes it inside policy, and tells you after — all logged in Freshservice.

Comment

Inspiration

Most IT friction never becomes a ticket. Employees hit a broken VPN profile, an expired cert, a permissions gap — and instead of filing a report, they just restart, reconnect, and move on with their day. Roughly 80% of employees lose real time to broken IT every month, but almost none of them say anything about it. So the service desk looks calm — four tickets today, nothing urgent — while the actual friction (dozens of silent failures, hours of lost time) stays invisible. No ticket doesn't mean no problem. It means nobody thought it was worth interrupting their day to report it. Tally exists to close that gap: to notice what employees don't bother mentioning, and act on it before it quietly repeats itself across a whole team.

What it does

Tally is an agent for Freshservice that watches read-only signal sources for patterns of friction that never get filed — repeated reconnects, repeated restarts, repeated failed access attempts — and turns them into action without waiting to be asked.

  1. Watch — Tally continuously scores signals for repetition, not just severity, so a low-grade but recurring issue doesn't get lost under louder, one-off tickets.
  2. Diagnose — once a pattern crosses its threshold, Tally correlates it to a single, named root cause (for example, one expired certificate profile) instead of surfacing a pile of disconnected symptoms.
  3. Respect a privacy boundary — identity only attaches after the pattern and cause are established. Tally reasons about the pattern anonymously first, then attaches identity only to the confirmed cause and the population who shares it.
  4. Find the population — Tally checks who else is silently affected by the same root cause, so one person's unreported annoyance surfaces as the shared incident it actually is.
  5. File, fix, gate, notify — Tally files the real ticket, applies the fix inside policy (through an explicit approval gate — it never bypasses governance), and only then notifies the affected employees, with everything logged in Freshservice as the system of record.

The result: the fixes employees needed, without requiring them to ask for them.

How we built it

Tally is designed around a Freshservice-native pipeline: Signal Sources → Pattern Engine → Privacy Boundary → Diagnosis → Stated Cause → Population → Record → Gate → Action/Notify → System of Record.

  • The Pattern Engine ingests read-only signals and scores them for repetition rather than raw severity, which is what lets Tally catch "quiet but constant" friction that traditional ticket volume or severity-based monitoring misses entirely.
  • The Privacy Boundary is a deliberate architectural choice: pattern detection and root-cause correlation happen before any identity is attached, so Tally never profiles individuals — it profiles causes, and only maps them to people once a cause is confirmed.
  • The Gate step means Tally can diagnose and even prepare a fix automatically, but it can't act unilaterally — every fix passes through a policy checkpoint before it's applied, and only after it's filed and resolved does Tally notify the people affected.
  • Everything is logged back into Freshservice as the system of record, so Tally augments the existing ITSM workflow rather than operating as a shadow system next to it.

I built and tested this as an interactive prototype that walks through the full state machine — toggling detection on shows 29 friction events and 3 hours 40 minutes of lost time hiding behind what looked like a normal, calm service desk with only 4 filed tickets — then drills into the named cause, the 18 other employees silently affected by the same issue, and the file → fix → notify sequence end to end.

Challenges we ran into

The hardest part wasn't detecting a pattern — it was deciding what to do with it responsibly. Two problems in particular took the most iteration:

  • Turning noisy signals into one defensible pattern. Repetition alone is a weak signal; the engine needed a way to separate a genuinely recurring issue from coincidental noise before it was confident enough to name a cause.
  • Correlating a pattern to a single, named cause — without over-collecting identity. It was tempting to attach identity early to make correlation easier, but that would have meant profiling individual behavior before there was even a confirmed issue. Building the privacy boundary so identity only attaches after the cause is established, not before, took real design work to get right without weakening the detection itself.

Accomplishments that we're proud of

  • A detection model that scores for repetition, not just severity — so it surfaces the quiet, recurring friction that normally never shows up in ticket queues at all.
  • A privacy-respecting architecture where identity is a downstream consequence of a confirmed cause, never an input to detection.
  • A full closed loop — watch, diagnose, gate, fix, notify, log — rather than just another dashboard that tells someone else there's a problem and leaves the fixing to them.
  • A working interactive prototype that makes the entire pipeline demonstrable end to end, not just a slide describing it.

What we learned

The most counterintuitive lesson was that the real product isn't "detect more problems" — it's "decide what's worth acting on without asking permission for every step, while still respecting a policy gate." Most of the hard engineering ended up being about restraint: waiting for a real pattern instead of reacting to the first anomaly, and waiting to attach identity until there's an actual, defensible cause behind it.

What's next for Tally

  • Expand the signal sources beyond the current set to cover more of the everyday friction employees silently work around.
  • Tune the pattern-scoring thresholds against real historical ticket and telemetry data from a live Freshservice instance.
  • Build out richer policy-gate configurability so different teams can set their own approval thresholds for automated fixes.
  • Pilot Tally against a live employee population to validate the population-correlation step (finding everyone else affected by the same named cause) at real scale.

Built With

Share this project:

Updates

Submission history