Feature · CRM Reporting

CRM reporting on the live record, not on last night's export.

The gap between what a CRM shows and what the business asks a BI tool is the gap this feature closes. Strkr ships a reporting engine that queries the live database the pipeline runs on, respects every permission the user model enforces, and ships with the specific dashboards sales operations teams ask for every quarter. No external BI tool, no overnight ETL, no reconciliation ritual between the CRM number and the dashboard number.

Start free trial See pricing
The reporting capability every CRM owes its users

What a credible reporting engine actually ships.

A CRM reporting engine lives or dies by three capabilities: query any field on any object with reasonable syntax, respect the permission model at the query layer, and refresh fast enough to be useful during a conversation rather than after it. The useful subset of reports a revenue team needs is bounded (pipeline by stage, forecast by owner, activity by rep, win rate by segment, cycle time by product) and the engine should ship the whole subset as templates on day one. Strkr clears every bar: ten standard dashboards shipped as templates, a self-serve report builder for custom reports, and sub-second refresh on the live database.

Live data

The report reflects the record right now.

A report in Strkr reads from the live database on query. Nothing is cached longer than a few seconds. A deal moved stage three minutes ago appears in the current stage on the report. No overnight batch, no sync job, no "data as of 4am" footer that erodes trust in the number.

Permissions enforced

The user sees only what the user can see.

The permission model applies at the query layer. A rep running a pipeline report sees only their own deals. A manager running the same report sees the team. A CRO sees everything. Field-level permissions mean a deal with a confidential field hides the field in the report when the user cannot see it on the record.

Self-serve builder

Pick an object, pick fields, pick a chart.

The report builder is self-serve. Pick an object (deal, lead, account, contact, custom object), pick the fields to include, pick the aggregation (count, sum, average, min, max), pick the chart type. No SQL, no cube definition, no data model to learn.

Shared library

Saved reports visible to the team.

Reports save to shared folders scoped by permission. The sales ops team maintains the canonical report library. Reps run from the shared library, customize for their specific view, and save a personal copy if they want it. No report proliferation chaos.

Scheduled snapshots

A report delivered on cadence.

Any report can schedule to a PDF or spreadsheet export delivered on a weekly, monthly, or quarterly cadence to a distribution list. The snapshot links back to the live report for drill-in. Executive teams get a predictable cadence without a separate operations ritual.

Drill-down

Click a bar, see the records behind it.

Every aggregate on a chart drills down to the underlying records. Click the "Enterprise segment, Negotiation stage, 23 deals" bar and the 23 deals open in a sorted table. The report is a navigation surface, not just a display surface.

Filters at every level

Scope the view without a new report.

Filters apply at the dashboard level and the tile level. A user can scope a shared dashboard to a specific territory, segment, product, or time range without saving a new copy. The scoped view does not disturb other users on the same shared dashboard.

Comparative views

This period versus last period.

Any time-based report supports period comparison: this quarter vs last, this year vs last. The overlay shows both periods in the same chart with the delta per bar or per point. Executives read trend conversations in seconds.

Export anywhere

CSV, PDF, PowerPoint, or scheduled email.

Every report exports to CSV for a spreadsheet, PDF for a print-safe snapshot, PNG for a slide deck, or scheduled email for an executive distribution list. The export carries the current filter state so what the user sent is what the user saw.

The pipeline reports every sales team runs

The standard set the shipping templates cover.

A revenue team runs the same ten reports every week with minor variations. The pipeline report by stage. The forecast report by owner. The deal velocity report. The win-loss report. The activity report. The win rate by segment. The cycle time by product. The slipping deal report. The stale deal report. The pipeline coverage report. Strkr ships every one of these as a template out of the box, built on the data model that comes with the CRM. The admin opens the template, customizes the filters, and the report is production-ready in the first hour.

Pipeline by stage

Dollars and count at each stage.

The canonical pipeline report shows total open ARR and deal count at each pipeline stage, with a secondary bar for weighted ARR based on stage conversion probability. Filters for owner, segment, product, and close date range. The core sales ops working view.

Forecast by owner

Commit, best case, pipeline, by rep.

The forecast report shows each rep's committed deals, best-case deals, open pipeline, and quota attainment. Rolls up to the manager and the VP. The number the sales leader uses in the weekly forecast call lives here.

Deal velocity

Days to close by stage.

The velocity report shows median days-in-stage for every pipeline stage, broken by segment and product. A stage with increasing days-in-stage over quarters is a bottleneck signal the sales ops lead investigates before it damages the forecast.

Win-loss

Close rate and reason trends.

The win-loss report shows closed deals split by win and loss, with the reason distribution for each. Trends over quarters surface shifts in competitive patterns or product-fit changes. The CRO reads the report before product strategy conversations.

Activity leaderboard

Calls, emails, meetings, by rep.

The activity report shows outbound volume per rep: calls, emails, meetings, SMS messages. The report answers the input-side of the pipeline conversation. Low activity on a rep with low pipeline is a coaching trigger. High activity on a rep with high pipeline is a scaling signal.

Win rate by segment

Which segments convert, which do not.

The win rate report splits closed deals by segment (enterprise, mid-market, SMB), by industry, by product, and by lead source. The segment with the highest win rate often deserves marketing budget redistribution. The report drives strategic conversations with grounded numbers.

Cycle time by product

How long each product takes to close.

The cycle time report shows median days from opportunity opened to closed-won by product line. Products with longer cycles need more pipeline coverage to hit the same revenue target. The report feeds the capacity planning conversation.

Slipping deals

Deals whose close date moved out.

The slipping deal report lists open opportunities whose expected close date has moved out by more than one period since the opportunity opened. Pattern slippage on a specific rep or product is a signal that the forecast is softer than the number suggests.

Pipeline coverage

Pipeline $ vs target, by period.

The coverage report shows open pipeline divided by the remaining revenue target for the current quarter. A healthy ratio is typically 3x or 4x depending on the win rate. Below the threshold triggers a demand-generation push. The CRO watches the number weekly.

The report builder for custom reports

The ninety percent of reports templates do not cover.

The canonical reports cover the standard questions. Every business has questions outside the standard set: a specific custom object, a specific joined relationship, a specific aggregation across two record types. The useful CRM reporting tool makes the custom build fast enough that the ops team ships the custom report in the hour the executive asked for it rather than the week after. Strkr's report builder uses the schema that already defines the CRM, so field pickers, filters, and aggregations are schema-aware and type-safe out of the box.

Any object

Standard or custom, any object queryable.

The report builder reads every standard object (deal, lead, account, contact, campaign, activity) and every custom object defined in the tenant. A custom object for "renewal," "quote," or "project" is a first-class source for a report, with its own fields and relationships.

Related joins

Deal joined to account joined to industry.

The report builder follows the schema relationships. Report on deals with a filter on the deal's account industry. Report on activities with a filter on the activity's related account tier. The joins are implicit from the schema, no SQL knowledge required.

Aggregation primitives

Count, sum, average, min, max, median.

The aggregation layer supports the standard functions: count, sum, average, min, max, median. For numeric fields, the full set is available. For categorical fields, count and distinct count. The right aggregation for the question is one picker click.

Grouping

Group by any field, including dates by period.

Group a report by any field. For date fields, group by day, week, month, quarter, year. For numeric fields, group by range buckets. For categorical fields, group by value. The grouping layer handles the common cases and the uncommon ones in the same picker.

Calculated fields

Derived values from the schema.

A calculated field adds a derived value to the report: deal ARR divided by stage probability, days since last activity, win rate against account tier. The expression editor is a visual builder, not a formula language. Non-developers add calculated fields without learning SQL.

Filters

Any field, any comparator, any value.

Filters apply to any field on any object. Comparators match the field type (dates get date-aware comparators, strings get text-aware comparators). Multiple filters combine with AND, OR, and NOT. The filter builder is a visual composer.

Sort and limit

Top ten, bottom ten, any order.

Reports can sort on any field, limit to a specific count (top ten, bottom twenty), and paginate for large result sets. The combination of sort and limit covers the specific "show me the top N by Y" questions executives ask constantly.

Visualization types

Table, bar, line, pie, funnel, cohort.

The chart library covers the common visualization types: tables, bar charts, line charts, pie charts, funnels, cohort grids, scatter plots, geographic maps. The chart type matches the data shape; the picker suggests sensible defaults for a given query.

Save and share

The custom report joins the shared library.

Save a custom report to the shared library, scope the share by role or team, and it becomes a template others can run and customize. The ops team maintains the official versions; individual users save personal copies without disturbing the official.

Dashboards: the surface the team actually opens

A dashboard is a composed set of reports with filters shared.

A single report answers one question. A dashboard answers the five or six questions a specific role has in a specific moment. The sales leader's Monday morning dashboard answers: how is pipeline pacing, which deals slipped, where is forecast risk, which reps need coaching, which deals need escalation. The sales rep's daily dashboard answers: my pipeline today, my activity today, my open tasks, my meetings. Strkr builds dashboards as composed sets of reports with shared filters, consistent refresh, and a design language that matches the rest of the CRM.

Composed tiles

Multiple reports on one surface.

A dashboard is a layout of tiles, each tile backed by a saved report. The tiles share filters so changing the time range at the top of the dashboard scopes every tile. The composition answers a role-specific question set in one view.

Role-based templates

Sales rep, manager, CRO, each a template.

The dashboard library ships role-based templates: sales rep daily, sales manager weekly, CRO executive, sales ops operational, marketing manager, customer success weekly. Each template is a starting point the admin customizes for the specific tenant.

Shared filters

One filter, every tile scopes.

A time range filter at the top of a dashboard scopes every tile. A segment filter scopes every tile. A rep filter scopes every tile. Users interact with the dashboard as a unified lens on the data, not as a set of independent tiles.

Permission inheritance

What the user can see shapes what the dashboard shows.

A sales rep opening the shared sales dashboard sees only their own data because the permission model applies at the query layer. The same dashboard for a manager shows the team. The dashboard definition is shared; the data each user sees is scoped. No separate per-role dashboards.

Live refresh

The dashboard shows the current state.

The dashboard refreshes on load and on filter change. For heavy dashboards, a cache layer keeps load times under two seconds while invalidating on record writes. The user sees the current state, not a stale snapshot.

Drill-through

A tile clicks to the detail record.

Every tile on a dashboard clicks through to either the detail report or the underlying records. The sales leader seeing a surprising number on the forecast tile clicks through to the specific deals that moved and reads the context without a side query.

Pinned and shared

A dashboard shows for every user on the team.

A pinned shared dashboard shows on every team member's home page without a separate per-user setup. The shared dashboard is a team artifact. Users can pin additional personal dashboards without changing the shared one.

Mobile layout

The dashboard reads on a phone.

Every dashboard has a mobile layout that stacks tiles vertically with the full data. The sales leader opens the forecast dashboard on their phone before a meeting and the key numbers are legible. The desktop layout is wider; the data is the same.

Scheduled delivery

A dashboard delivered as a weekly digest.

A dashboard can schedule to a weekly PDF digest delivered to a distribution list. The CRO gets the weekly summary at 7am Monday with the data as of midnight Sunday. The digest links back to the live dashboard for drill-in.

Strkr AI inside the reporting layer

The assistant that answers the question the dashboard did not anticipate.

Reports and dashboards cover the questions the ops team anticipated. The assistant covers the questions the ops team did not. A sales leader asks "which of my reps' deals most need coaching this week" and the assistant pulls the data, applies the heuristics, and returns a sorted list with reasons. A CRO asks "what explains the slip on this quarter's forecast" and the assistant walks through the forecast change, identifies the specific deals, and summarizes the pattern. The assistant is a first-class reporting surface, not a chat window.

Natural-language queries

Ask the question, get the data.

Ask "show me enterprise deals in negotiation that have been quiet for over seven days." The assistant parses the query, builds the report, and shows the results. Save the report if useful. The language-to-report path shortens the time from question to answer.

Dashboard narrative

A paragraph summarizing what moved.

A dashboard tile can carry a narrative paragraph drafted by the assistant. "Pipeline this week is up 4 percent from last week, driven by two large enterprise opens; forecast is at 92 percent of target with three deals slipping into next quarter." The executive reads the paragraph alongside the chart.

Anomaly detection

What is unusual this week.

The assistant watches the standard dashboards and flags anomalies: a rep's pipeline doubled unexpectedly, a segment's win rate dropped sharply, a product's cycle time extended. The flags land on the ops dashboard with the suggested investigation path.

Coaching lists

Which reps need which conversations.

The assistant produces a coaching list for sales managers: which reps have deal-stage issues, which have activity gaps, which have forecast risk. Each entry has the specific signal driving the recommendation. The manager walks into the 1:1 with the right agenda.

Deal risk explanations

Why the risk score moved on this deal.

When a deal's risk score changes, the assistant explains the move. "Risk moved from 32 to 68 because stakeholder count dropped, discount depth increased, and the champion stopped replying to emails." The explanation is in the record, visible to the rep.

Forecast commentary

A plain-English forecast summary.

Alongside the forecast tile, the assistant drafts a plain-English commentary: "The current forecast is 2.3M against a 2.5M target. The gap is three deals in late stages that could close either side of quarter-end. The highest-probability close is X; the biggest risk is Y."

Ad hoc analytics

Answer a one-off exec question quickly.

An executive asks a specific question in a meeting. The ops lead opens the assistant drawer, asks the question, and the assistant pulls the data and formats the answer. The question goes from asked to answered within the meeting, not after it.

Historical context

How did this metric trend over the last year.

The assistant can pull historical context on any metric: "How has our win rate on the enterprise segment trended over the last four quarters" returns the data, the chart, and a paragraph of context. Trend conversations become one-click.

Permission-respecting

The assistant sees what the user sees.

The assistant runs under the user's permission context. A rep asking a question gets answers scoped to their own data. A manager asking the same question gets team data. The permission model applies to the assistant's outputs, which keeps sensitive data from leaking across role boundaries.

CRM reporting on the live record, with the assistant drafting what the dashboard did not anticipate.

Ten standard dashboards ship as templates. The self-serve builder covers every custom report. Scheduled snapshots deliver PDFs to executives weekly. Strkr AI answers the ad hoc questions in natural language. All on one platform, respecting permissions, no BI tool needed.

Start free See pricing
Common questions

What buyers ask about this feature.

Do we still need a BI tool like Looker or Tableau on top of Strkr's CRM reporting?

For the vast majority of revenue-operations reporting questions, no. Strkr's reporting engine covers the standard pipeline, forecast, activity, win-loss, cycle time, and coverage reports, plus the self-serve builder for custom reports across any standard or custom object. The engine queries the live database with permission enforcement at the query layer, so the CRM record and the reported number are always the same number. External BI tools remain useful when you need to join CRM data with external datasets (ERP financials, product usage telemetry, marketing automation data from a non-Strkr source) at scale, or when a dedicated analytics team wants to run complex transforms outside the operational database. For the questions a revenue team asks in a weekly cadence, Strkr's native reporting usually replaces the need for a BI tool on top of the CRM.

How does Strkr handle reporting on custom objects?

Custom objects are first-class citizens of the reporting engine. If your tenant defines a custom object for "renewal," "quote," "project," "subscription," or anything else specific to your business, it appears in the report builder's object picker alongside standard objects like deals and accounts. All the same reporting primitives apply: filters on any field, groupings by any field, aggregations through count/sum/average/min/max/median, joins through the schema relationships, charts of every supported type. The permission model also respects custom object field-level permissions, so a reporting user sees only the custom-object fields they have access to on the record view. Dashboards can mix tiles from custom objects and standard objects in one view, which is useful for teams whose business model requires custom primitives outside the standard CRM schema.

Can we schedule reports to be delivered to executives automatically?

Yes. Any report or dashboard can schedule to a delivery cadence (daily, weekly, monthly, quarterly) and format (PDF, CSV, PNG for slide decks, scheduled email with inline images). The distribution list accepts internal users and external email addresses, with permission scoping on which recipients see which data. The scheduled version respects the recipient's permission context, so a CRO on the distribution gets the CRO-level view, and a manager on the same list gets the manager-level view, from the same scheduled job. The scheduled PDF links back to the live report for recipients who want to drill in. Executives tend to prefer the weekly or monthly cadence; ops teams tend to run the daily cadence on operational dashboards. The schedule is configured once and runs automatically with the data refreshing on each delivery.

How does the AI assistant work inside the reporting layer, and does it respect permissions?

The assistant integrates with the reporting layer in three ways. First, natural-language queries: ask "show me enterprise deals in negotiation that have been quiet over seven days" and the assistant builds the report. Second, dashboard narrative: a tile on a dashboard can carry a Strkr-AI-drafted paragraph summarizing what moved. Third, anomaly detection: the assistant watches the standard dashboards and flags unusual patterns with the signal driving the flag. All three capabilities respect the user's permission context. A rep asking a natural-language query gets answers scoped to their own data. A manager gets team data. A CRO gets everything. The permission enforcement happens at the query layer before the assistant sees the data, so the assistant cannot leak information across role boundaries. Field-level permissions apply the same way: a confidential field hidden on the record is hidden in the assistant's outputs.

Can we build dashboards that show different data to different users on the same dashboard definition?

Yes, and this is one of the specific advantages of a reporting engine built inside the CRM rather than bolted on top of it. The permission model enforces at the query layer, so a single shared dashboard shows one data set to a rep (their own deals), a different data set to a manager (their team), and a different data set to the CRO (everything). The dashboard definition is one artifact. The data each user sees is scoped by their role, their team, their territory, their segment, or any other dimension the permission model considers. This eliminates the "I need my own version of the dashboard" proliferation that happens in BI tools without the right permission model, and keeps the shared dashboard as the single source of truth for the team.

What is the performance like on large datasets, say a pipeline with 50,000 open deals?

The reporting engine is designed for operational scale, which for most revenue teams means millions of records across the standard objects. A 50,000-deal pipeline is well within the comfortable operating range for sub-second dashboard loads on common queries. For heavier dashboards (many tiles, complex joins, large time ranges), a smart cache layer keeps load times under two seconds while invalidating on record writes so the user always sees fresh data within a few seconds of a change. For truly massive datasets (billions of activity records across years of history), the engine applies time-partition optimizations and index strategies that keep the common operational queries fast while the deep historical queries run slightly longer. For edge cases that require external compute (joining with datasets outside the CRM, running complex transforms), the Strkr open API exposes the data for an external BI tool to query, but those cases are rare for the standard revenue-operations reporting workload.

Related features

Pair this with...

Sales Reporting Sales Dashboard CRM Dashboard KPI Dashboard Sales Analytics Dashboard Software

Try it free. Bring your team next week.

No sales call, no migration consultant, no four-month implementation. Enter your card, get 14 days of the full Pro tier, cancel any time before day 14 with zero charge. Spin up a workspace, import your CSV, and have something useful before lunch.

Start free trial See pricing