Deal tracking that answers every question before the Monday standup.
Strkr tracks every open deal through stage-based progression, calibrated win probability, days-in-stage age, a complete timeline and audit trail, a per-field change log, attached documents on the record, and a mandatory next-step owner. One deal page, one audit shape, one answer to "where does this deal stand right now."
The seven questions a sales manager asks about every open deal.
Deal tracking is not a kanban board with pretty colors on it. It is a system of record that answers seven questions on every open deal, in every stage, every day of the quarter. Which stage is this deal in and when did it get there. What is the probability it closes, and is that number calibrated or vibe-based. How many days has it been sitting where it is sitting. What has happened on this deal, in order, since it opened. Which fields changed, when, and by whom. What documents are attached, with what versions, from what source. And whose job is the next step. If the deal page cannot answer those seven questions in a glance, the Monday standup turns into a thirty-minute archaeological dig through notes, emails, and screenshots. Strkr answers all seven, inline, on every deal, without a manager having to construct a dashboard, run a report, or ask a rep to "check and get back to me." The checklist below is the one buyers should walk every CRM through before signing a seat agreement.
Stage progression
Every deal has a current stage and a stage history.
The current stage is a single enum field, pipeline-scoped, with the entry timestamp pinned on arrival. Behind that one field, Strkr keeps the full ordered history of stage transitions: when the deal entered Discovery, when it moved to Proposal, when it slipped back to Discovery, when it finally hit Negotiation. The history is the deal, not a side effect of the deal. Every stage number managers quote in a QBR is backed by the exact timestamp of the transition that got the deal there.
Win probability
A calibrated number, not a stage-mapped guess.
Most CRMs quietly set win probability to the stage-default: Discovery is 10 percent, Proposal is 40, Negotiation is 70, and the number lies the moment a rep moves a deal to the next stage prematurely. Strkr computes a per-deal probability from stage, days-in-stage, engagement signal, stakeholder count, discount depth, and the historical close rate of comparable deals, then shows both the stage-default and the computed number side by side so the rep and the manager can see the gap.
Days-in-stage
The age of the deal in its current stage, in days.
The deal page shows days-in-stage as a prominent chip, color-coded against the typical cycle time for that stage in this tenant. A Proposal that has been sitting for twenty-eight days when the typical cycle is nine days gets a red chip. A Negotiation that moved in two days gets a green chip. Reps see the age without opening a report. Managers filter their pipeline on "stale" with a single click and get the exact set of deals that need a push today.
Deal timeline
Every event on the deal, in chronological order.
Open the Timeline tab and see every event: calls, emails, meetings, stage changes, field edits, document attachments, task completions, note additions, assistant actions. The timeline is deduplicated across activity sources (Gmail and Outlook sync into one view, Zoom and Teams meetings land in the same strip) and filterable by actor, type, and date range. Managers reviewing a lost deal can scroll three months of history without opening a separate tool.
Change log
Field-level audit of every edit, with before and after.
The Change Log tab is the stricter cousin of the Timeline. It lists every field that changed on the deal: who edited it, what it was before, what it became, when the edit landed, and whether the actor was a human user, an assistant, or an automated flow. Finance teams reviewing a renewal and compliance teams reviewing a lost deal can both answer "when did amount drop from $240k to $180k" without a database query.
Document attach
Proposals, contracts, and decks live on the deal.
Attach a Google Doc, a Dropbox link, a PandaDoc proposal, a DocuSign envelope, or an uploaded PDF directly to the deal record. The attachment carries source metadata (where it came from), a version pointer (which revision), and a status chip for e-signature artifacts (sent, viewed, signed, declined). Reps stop pasting document URLs into note bodies. Managers stop asking "where is the latest proposal."
Next-step owner
Every open deal has a mandatory next step and owner.
The Next Step field is required on every open deal: a sentence describing the action, an owner user, and a due date. Deals without a next step surface on the manager's dashboard as a dedicated "needs next step" count. Reps cannot save a deal update without the field. The result is that pipeline reviews stop opening with "what are you doing on this one" because the deal page already says.
Stakeholder map
Every contact involved, with their role on the deal.
The Stakeholders panel lists every contact associated with the deal, tagged with a role (economic buyer, champion, user, blocker, legal, procurement), engagement score, and last-touch date. Reps and managers see the stakeholder picture without a side-bar hunt. Deals with fewer than two stakeholders raise a flag because single-threaded deals close at a materially lower rate than deals with a champion plus an economic buyer, which the dashboard surfaces as a measurable risk tier.
Forecast category
Commit, Best Case, Pipeline, Omitted - rep-called, model-checked.
Every open deal carries a forecast category the rep sets by hand (Commit, Best Case, Pipeline, Omitted) and a model-called category Strkr AI assigns from the data. When the two disagree, the deal lands on the manager's "disagreements" queue. The forecast is not a single number arrived at magically. It is a diff view between what the rep believes and what the data suggests, line by line, deal by deal, with the rep still in the driver seat.
How stage progression works in Strkr
Stages that are a system of record, not a kanban toy.
Most sales teams treat stages as a visual metaphor: cards move across a board, screenshots get taken, the quarter ends. The stage model inside Strkr is a strict state machine. Every stage transition writes a row with timestamp, actor, and the full before-and-after shape of the deal at the moment of the move. Entry criteria can be enforced per stage (required fields, required attachments, required stakeholders) so a deal cannot slip into Proposal without a dollar amount, a close date, and an attached scope document. Exit criteria can be enforced the same way. The result is that the stage column on any report is backed by evidence, not vibes. The upshot for managers is that pipeline coverage, slip rate, and stage conversion all become reliable numbers rather than directional guesses. The upshot for reps is that the system catches malformed deals before the manager has to.
Pipeline-scoped stages
Different pipelines, different stage sets, one audit shape.
A new-business pipeline has Discovery, Proposal, Negotiation, Closed Won, Closed Lost. A renewal pipeline has Preparation, Negotiation, Executed, Churned. A partnership pipeline has its own set. Strkr scopes stages to the pipeline the deal lives in, so the enum values on the deal page always match the sales motion. Underneath, the audit shape is identical, so cross-pipeline reports still work.
Entry criteria
Required fields and attachments gate the transition.
Admins configure per-stage entry criteria: Proposal requires amount and close date, Negotiation requires an attached draft, Closed Won requires a signed contract. The rep attempting to move the deal gets an inline validation message, not a silent-save-and-report-later. The pipeline tightens without the manager having to pursue hygiene one deal at a time.
Backward transitions
A deal that slips back is a deal, not a bug.
The state machine allows backward moves because real sales motions have them. A deal moves to Negotiation, procurement blocks it, the deal moves back to Proposal to re-pitch. Strkr records the direction (forward, backward) on every transition and reports on backward-slip rate per stage, per rep, per quarter, so sales ops can see where coaching needs to concentrate.
Stage age pinned on entry
The clock starts when the deal arrives in the stage.
Days-in-stage is computed from the exact timestamp the deal entered the current stage, not from the created-at of the record and not from a nightly job that rounds to midnight. Reps who move a deal to Negotiation at 3 PM Tuesday see days-in-stage increment at 3 PM Wednesday, not at 11:59 PM Tuesday or 3 AM Wednesday. The number is precise.
Stage history view
The strip above the deal shows every move.
A horizontal strip at the top of the deal page shows every stage the deal has occupied, in order, with duration in each stage underneath. Managers reviewing a deal see at a glance that it sat in Discovery for 68 days before moving quickly through the rest, which is a different coaching conversation than a deal that moved briskly through Discovery and then got stuck in Negotiation for 90 days.
Expected cycle overlay
Compare the deal's pace against the tenant median.
The stage strip overlays the tenant's median duration per stage underneath the deal's actual duration. A rep sees that the typical Proposal in this tenant lasts 12 days and this deal has been in Proposal for 38 days, right on the deal page. The overlay refreshes nightly from the rolling 90-day window of closed deals, so the comparison tightens as the pipeline matures.
Automatic stage-change notifications
Managers get pinged on moves that matter.
Admins set rules for which stage transitions page which users. A deal above $100k moving to Closed Won pings the sales leader. A strategic account moving backward pings the account director. Notifications are rule-driven rather than firehose, which is how they stay useful at scale. Reps are not generating stage-move spam into Slack and inboxes just because the system supports it.
Programmatic transitions
Flows can move deals under human review.
A Flow can be configured to move a deal to Negotiation when a specific signed document lands, or to Closed Lost when the primary contact unsubscribes and the deal has gone stale. The transition writes with the Flow's identity, not a user's identity, so the Change Log is honest about automation. Humans still own the critical transitions by default.
Won-and-lost reasons
Required at Closed Won and Closed Lost.
Deals cannot transition to Closed Won or Closed Lost without a reason selected from a configurable enum, plus a free-text note. The result is clean win-loss analytics that cover every closed deal in the quarter, not the subset the rep remembered to annotate. The reason set is admin-managed, so sales ops can refine it over time without engineering lift.
Win probability, days-in-stage, and age
The numbers on the deal, with the receipts attached.
The win-probability field in most CRMs is either a stage-default enum (10, 25, 40, 60, 90) or a free-form number the rep edits in a side-bar. Both patterns produce a forecast that lies. Strkr's approach is explicit: a stage-default is still visible, because it is a useful anchor, but alongside it the deal page shows a model-called probability computed from a short list of signals the manager can inspect. The signals are the deal's stage, its days-in-stage against the tenant median, the number of stakeholders attached to it, the recency of last activity, the engagement score of the primary contact, the discount depth implied by the amount against product list price, and the historical close rate of deals that looked like this one at this stage. The output is a number plus a one-sentence reason. The rep argues with the reason. The manager sees the argument. The forecast tightens.
Dual-column display
Stage-default next to model-called, always.
The deal page shows the stage-default probability (e.g. "Proposal = 40%") in grey and the model-called probability ("Model = 22%") in color. The gap between them is the signal. A green deal shows the model-called above the stage-default. A red deal shows it below. Managers glance at the pipeline grid and know immediately which deals are being called too hot by their stage alone.
One-sentence reason
The number comes with its argument.
Every model-called probability ships with a sentence: "Discounted 32% below list, single-threaded, 47 days in stage, last activity 11 days ago." The sentence is retrieved from the live record, not generated hallucinatorily. Reps can click any phrase to open the underlying field or event. The reasoning is auditable, which is the only form of model trust that scales past demo day.
Days-in-stage chip
Color-coded against the tenant median per stage.
A chip on the deal header shows "21d in Proposal" with a color that reflects how that number compares to the median Proposal duration for this tenant. Under median = green. Within one standard deviation = yellow. Beyond one standard deviation = red. The chip is on the page without a report, and the pipeline list sorts by it with a single click.
Total deal age
How long since the deal opened, period.
In addition to days-in-stage, every deal shows total age (days since created) prominently. A 180-day-old deal that has only been in one stage looks different from a 180-day-old deal that has moved through four stages. The combination of total age plus stage age plus stage history is what tells the real story of pace.
Stall alerts
A nightly process surfaces stalled deals.
Every night Strkr runs the stall query: deals above a configurable amount, with days-in-stage above a configurable multiple of the median, and no activity in a configurable number of days. The output lands on the manager's dashboard as a numbered list, with the right question to ask about each deal pre-written. The stall list drives Monday coaching, not vibes.
Probability history
How this number moved over the life of the deal.
A small sparkline on the deal page shows the model-called probability over the deal's life. Managers reviewing a lost deal see the probability trending down for two weeks before the loss. Reps reviewing a won deal see the probability stabilizing after a stakeholder was added. The trajectory, not just the current value, is the signal.
Timeline, change log, and audit trail
Everything that happened, in order, with before and after.
The honest definition of an audit trail is that it answers the question "what happened on this deal" without requiring a database query, a BI tool, or an email to the rep. Strkr's deal page has two tabs that together form the audit layer: the Timeline, which is a chronological feed of every event on the deal, and the Change Log, which is a field-level record of every edit. Reviewing a closed-lost deal six weeks after the fact is a scroll and a filter, not an archaeological dig. Reviewing a renewal that unexpectedly dropped in amount is a one-click answer to "when did amount change and who changed it." The audit shape is identical whether the actor was a human user, a Flow automation, or Strkr AI, so one review query covers all three categories.
Timeline tab
Deduplicated chronological event feed.
Calls, emails, meetings, stage changes, field edits, document attachments, task completions, note additions, assistant actions. The Timeline is the one view managers use to understand a deal. Events are deduplicated across sources (one email that landed in Gmail and the Strkr sidecar shows once, not twice) and tagged with actor, type, and context, which keeps the feed readable even on multi-month deals.
Change Log tab
Field-level before and after, every edit.
Every field edit writes a row to the Change Log: the field name, the previous value, the new value, the actor, the timestamp. The Change Log is filterable by field, by actor, by date range. Compliance teams reviewing an unusual close terms edit, finance teams reviewing an amount decrease, and managers reviewing a stage move all use the same tab, filtered differently.
Actor classification
Human, Flow, Assistant - never conflated.
Every row in the audit layer tags the actor type: a user by name, a Flow by its configured name, or Strkr AI by its assistant handle. A manager reviewing a deal sees which decisions came from the rep, which came from automation, and which came from the assistant. The three are distinct and inspectable. The pattern applies to writes in the UI, writes from the API, and writes from assistant actions equally.
Immutable rows
The audit layer cannot be edited retroactively.
Rows in the Timeline and the Change Log are append-only. A user cannot delete a row to hide an edit. A manager cannot rewrite history. Soft-delete at the deal level does not erase the audit trail; it preserves it for the retention window. The guarantee is that any question about "what actually happened" has a honest answer, always.
Retention policy
Configurable per tenant, with a sensible default.
By default Strkr retains the full audit layer for the life of the record. Enterprises with stricter data retention policies can configure a retention window per object (deals, contacts, documents) that archives rows after the specified duration. The archive is still queryable by admins with the appropriate permission, so legal holds and discovery requests still work.
Export to compliance
One click produces a CSV for the auditor.
An admin reviewing a deal for compliance or legal reasons can export the full Timeline and Change Log to CSV with one click. The export carries the actor identities, the timestamps in UTC, and a signed hash so the auditor can confirm the file has not been edited since export. The pattern beats emailing the rep for screenshots, which is the pattern most CRMs still rely on.
Related record cross-link
Events on contacts and accounts show up on the deal.
An email sent to a contact associated with the deal shows up on the deal Timeline, not just on the contact page. A support ticket opened by the champion shows up on the deal Timeline, not just on the account page. The deal is the context, so the deal is the view. Reps and managers do not have to open three records to understand one deal.
Filter and search inside the deal
Find a specific event in a 300-event deal.
Deals that have been open for a quarter accumulate hundreds of events. The Timeline supports a search box plus a filter popover (type, actor, date range, direction) so managers can drill to "every email from procurement in the last 30 days" in two clicks. The feature is table stakes for large-deal review and absent from most competitor products.
Mentioned stakeholders highlighted
Email mentions and note mentions become badges.
When a stakeholder is named in a note or an email body, Strkr highlights the mention and badges the stakeholder on the Timeline row. A manager scrolling the Timeline sees instantly which conversations involved the economic buyer and which were in-the-weeds with technical users. The badges are a UI affordance, not a model guess, and the mapping is reversible.
Documents and next-step ownership
The proposal is on the deal, and so is whose turn it is.
Deal rooms, document portals, and side-bar attachments all solve the same problem: where does the latest proposal live, and who has to do something next. Most CRMs solve neither well. Attachments disappear into note bodies as pasted URLs that go stale. Next steps live in rep heads or in a dedicated task tool nobody opens. Strkr pulls both back onto the deal record where they belong. Documents attach with source metadata and version pointers, and the e-signature artifacts carry a status chip that reflects reality. Next steps are a mandatory field with a sentence, an owner, and a due date, enforced at save time. Managers reviewing a deal see at a glance whose turn it is and what the current paperwork says, without opening DocuSign, PandaDoc, Google Drive, or Dropbox in a separate tab.
Attachment sources
Native integrations, not pasted URLs.
Attach from Google Drive, Dropbox, OneDrive, SharePoint, PandaDoc, DocuSign, HelloSign, or an uploaded PDF. Each attachment carries source metadata: which cloud, which folder, which file ID, which version. If the source document moves or is renamed, Strkr follows it. If the source document is deleted, Strkr flags the attachment as broken. The pattern beats pasted URLs by a wide margin on reliability.
E-signature status chip
Sent, Viewed, Signed, Declined - in color.
A PandaDoc proposal attached to the deal carries a live status chip that reflects the e-signature state: Sent (grey), Viewed (yellow), Signed (green), Declined (red), Expired (dim). The chip refreshes via webhook within seconds of the status change. Reps stop asking "did the client see it yet." Managers filter the pipeline on "viewed but not signed in 7 days" to find the deals that need a follow-up push.
Version pointer
The attachment always points at the latest revision.
When the source document is edited (a Google Doc revision, a PandaDoc version bump), the attachment on the deal updates its version pointer and surfaces a small "updated 3h ago" badge. The pattern avoids the "which draft is current" confusion that eats deal time. A manager opening the deal always sees the current draft, not the one that was attached in week one.
Next-step field
A required sentence, a required owner, a required date.
Every open deal must have a Next Step before save: a one-sentence description, an owner user, and a due date. The field is enforced at the API and the UI, so no mechanism bypasses it. Deals that are missing it on save bounce the rep back with an inline message. Managers reviewing the pipeline see "whose turn is it" as a column, not as a verbal update.
Overdue next-step surfacing
Next steps with past-due dates get flagged.
A deal whose Next Step due date has passed without the owner marking it complete gets a red flag on the pipeline grid and shows up on the manager's dashboard as a dedicated count. The incentive is for reps to either mark the step done or update the step with a realistic new date. The flag is persistent until the state is resolved, which is how real accountability lives in software.
Document generation
Produce a proposal from the deal in two clicks.
Click "Generate Document" on the deal, pick a template, and Strkr builds a proposal, quote, or contract with the deal's amount, product mix, stakeholder names, close date, and tenant branding merged in. The output drops onto the deal as a PandaDoc or DocuSign envelope ready to send. The round trip from deal update to proposal in client inbox is a minute, not an afternoon.
Attachment permissions
A document attached to a deal honors deal visibility.
If a user cannot see the deal, they cannot open the attached document even if the underlying cloud link is public. Strkr enforces access at the attachment proxy, not at the cloud. The pattern closes the hole where a shared Dropbox link accidentally exposes sensitive pricing to the wider org. Compliance teams review access once and the answer applies tenant-wide.
Attachment search
Find the proposal by content, not just by filename.
Attached PDFs and Google Docs are indexed by content, so a manager searching for "mutual indemnification" across the pipeline finds every deal with a document that contains the clause. The index refreshes on upload and on version bump, and respects permissions, so a user can only search deals they can see. The feature saves legal and sales ops hours during contract review and renewal preparation.
Next-step reassignment
Hand off cleanly when ownership moves.
When a Next Step owner changes, Strkr pings the new owner, logs the reassignment on the Timeline, and keeps the sentence intact unless the new owner edits it. The pattern beats "verbal handoff on a Slack huddle" because the audit trail reflects the move. Managers reviewing a complex deal see every ownership change the deal went through, not just the current state.
Deal tracking at the pipeline level
The individual deal is the atom. The pipeline is the molecule.
Deal-level tracking is table stakes. Pipeline-level tracking is where sales ops lives. Strkr rolls every per-deal field up into pipeline-level views and reports: coverage against quota, slip rate per stage, stage conversion per rep, time-to-close per segment, forecast accuracy over trailing quarters. The rollups are not reports written by hand. They are live aggregations of the same records a rep sees on the deal page, so the pipeline-level number and the deal-level number always match. The decoupling that happens on most CRMs, where the pipeline report lives on a BI tool refreshed nightly and disagrees with the deal page, does not happen here. Managers who want to drill from a pipeline KPI to the ten deals driving it click once and land on the filtered list. Reps who want to see their own pipeline against their quota click once and see the number plus the deals plus the gap. The whole stack is one data model, not three.
Pipeline grid
Every open deal, sortable, filterable, groupable.
The pipeline grid is the default view for managers. Deals are rows, with columns for stage, amount, probability, days-in-stage, next step, owner, close date, and any custom field admins have added. Group by stage for a kanban, group by rep for a per-rep view, group by segment for an ICP view. The grid is the one page managers live in during pipeline review.
Coverage against quota
Pipeline value divided by remaining quota, per rep.
Every rep has a quota by period. The pipeline dashboard shows pipeline coverage (weighted by probability or unweighted, admin-configurable) against the remaining quota in the period, per rep and in aggregate. Managers see coverage below the healthy threshold flagged red, which is the single most useful number in the pre-QBR review and the one that drives coaching decisions.
Slip rate
How often deals slip past their called close date.
Slip rate is the percentage of deals that closed later than their initial close-date forecast. Strkr reports slip rate per rep, per stage, per segment, over trailing periods. Reps with chronically high slip rates get coached on their forecasting discipline, not on their closing skills, which is a different conversation that saves managers time and reps frustration.
Stage conversion
What percentage of deals move from X to Y.
For each pair of adjacent stages, Strkr reports the conversion rate: 100 deals entered Proposal, 60 moved to Negotiation, 30 moved to Closed Won. The conversion is reported per rep, per segment, over trailing periods. Managers find the stage where their team is losing deals and concentrate coaching there, rather than coaching the whole funnel equally.
Time-to-close
Median days from opened to Closed Won, per segment.
Time-to-close is the median duration from deal creation to Closed Won, per segment, per rep, per period. The number drives capacity planning (how long will this quarter's pipeline take to close) and forecast sanity (deals called to close faster than the median need an argument). The decomposition into per-stage durations closes the "why" gap behind a single aggregate.
Pipeline movement report
What changed in the pipeline this week, in dollars.
Every Monday morning the pipeline movement report lands on the manager's dashboard: dollars added by stage, dollars moved forward, dollars moved backward, dollars closed, dollars lost. The report is the executive summary of the week in one tile and the dig-into-the-deals link under it. Executives reviewing pipeline health get the shape, not a thousand-row CSV.
Forecast accuracy
Trailing forecast calls vs. actual results.
Strkr archives the forecast call at the start of each period (committed deals, best-case deals, pipeline deals) and compares it to the actual closed-won number at period end. The accuracy percentage is reported per rep, per segment, per period. Reps with low accuracy get coached on calibration. Reps with consistent accuracy get leaned on more during the next period's plan.
Multi-pipeline support
New business, renewal, expansion - same deal page.
Separate pipelines for separate motions, with separate stages, separate required fields, and separate forecast categories. The underlying deal record is the same shape, so cross-pipeline reports (total ARR influenced, total revenue impact) still work. The pattern beats the "one giant pipeline with 20 stages" shape that most CRMs ship as the default and that nobody actually uses.
Saved filters
The views managers actually look at, bookmarked.
Managers save frequently used filters as personal views: "my team's stalled Negotiation deals," "deals above $100k with no activity in 14 days," "deals missing a next step." The saved views appear in the sidebar for one-click access. The pattern makes the pipeline grid feel like a dashboard without the sales ops team having to build and maintain one.
Deal tracking that answers every question before the manager has to ask.
Stage progression, calibrated win probability, days-in-stage age, full Timeline and Change Log, document attach with e-signature status, and a mandatory next-step owner. Every open deal, every pipeline, every tier. Start a trial, import your pipeline, and run your next Monday standup off the Strkr pipeline grid.
Every deal shows two numbers side by side: the stage-default probability (e.g. "Proposal = 40%") and a model-called probability computed from a short list of signals the manager can inspect. The signals include the deal's stage, days-in-stage against the tenant median, number of stakeholders attached, recency of last activity, engagement score of the primary contact, discount depth implied by the amount against product list price, and the historical close rate of comparable deals in this tenant. The output is a number plus a one-sentence reason retrieved from the live record, so the reasoning is auditable and the rep can argue with it.
What is the difference between the Timeline and the Change Log on a deal?
The Timeline is a chronological event feed: calls, emails, meetings, stage changes, document attachments, task completions, note additions, assistant actions. It is the view managers use to understand a deal end to end. The Change Log is the stricter cousin: a field-level record of every edit, with the field name, the previous value, the new value, the actor, and the timestamp. The Change Log answers "when did amount drop from $240k to $180k and who changed it," while the Timeline answers "what happened on this deal over the last six weeks." Both are append-only, both tag the actor type (human user, Flow automation, Strkr AI), and both can be exported to CSV for compliance review.
Can I attach proposals, contracts, and e-signature envelopes to a deal?
Yes. Strkr supports native integrations with Google Drive, Dropbox, OneDrive, SharePoint, PandaDoc, DocuSign, HelloSign, and direct PDF upload. Each attachment carries source metadata (which cloud, which folder, which file ID), a version pointer that follows the source document as it is edited, and a live status chip for e-signature artifacts (Sent, Viewed, Signed, Declined, Expired) that refreshes via webhook. Document attachments honor deal visibility, so a user who cannot see the deal cannot open the attached document even if the underlying cloud link is public. Attached PDFs and Google Docs are indexed by content, so a manager can search the pipeline for a specific clause like "mutual indemnification" and find every deal whose documents contain it.
Why is the next-step field mandatory on every open deal?
Pipeline reviews that open with "what are you doing on this one" waste thirty minutes per standup. Strkr requires every open deal to carry a Next Step before save: a one-sentence description, an owner user, and a due date. The field is enforced at the API and the UI, so no path bypasses it. Deals with overdue next steps get flagged red on the pipeline grid and surface on the manager's dashboard as a dedicated count, which turns "whose turn is it" into a column rather than a verbal update. Reassignments log cleanly on the Timeline so the audit trail reflects every ownership change the deal went through.
What is days-in-stage and how is it computed?
Days-in-stage is the number of days a deal has spent in its current stage, computed from the exact timestamp the deal entered the current stage. It is shown as a prominent chip on the deal header, color-coded against the tenant median duration for that stage: under median is green, within one standard deviation is yellow, beyond one standard deviation is red. The median overlay refreshes nightly from the rolling 90-day window of closed deals, so the comparison tightens as the pipeline matures. Managers filter the pipeline grid on "stale" with a single click to find the deals that need a push today, and the stall query runs nightly to surface stalled deals on the manager's dashboard with the right question to ask about each one.
Can Strkr enforce entry criteria on stage transitions?
Yes. Admins configure per-stage entry criteria: Proposal requires amount and close date, Negotiation requires an attached draft proposal, Closed Won requires a signed contract, Closed Won and Closed Lost require a reason selected from a configurable enum plus a free-text note. The rep attempting to move the deal gets an inline validation message rather than a silent save followed by a report later. Backward transitions are allowed because real sales motions have them, and Strkr records the direction (forward, backward) on every transition so sales ops can report on backward-slip rate per stage, per rep, per quarter. Programmatic transitions by Flows and Strkr AI write with the automation's identity so the Change Log is honest about which decisions came from humans and which came from the system.
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.
We use cookies.
Essential cookies keep the site working. If you accept, we also enable Google Analytics
so we can see which pages help and which don't. Reject to opt out entirely. Details in our
Privacy Policy.
