Feature · Workflow Program

A workflow program that ships the ten motions every revenue team runs.

A workflow program is not a tool. It is the deliberate set of ten or twelve repeatable motions a revenue team runs week after week, each with a named owner, a measurable SLA, and a documented change log. Strkr builds the platform under that program: the triggers, actions, approvals, documents, messaging, AI, and reporting that turn a sticky-note list of motions into running automation. The ops lead stops hand-maintaining a program and starts operating a system.

Start free trial See pricing
What a workflow program actually looks like

Ten motions, ten owners, ten measurable SLAs.

The ops lead who runs a working workflow program sits with a sheet of paper and lists the ten motions the business depends on week after week. Inbound lead routing. Outbound cadence launch. Discount approval. Renewal brief generation. Closed-won provisioning. QBR prep. Churn save plan. Expansion play. Data hygiene sweep. Compliance archival. Each motion gets a named owner, a defined trigger, a defined action set, a measurable SLA, and a change log. The program is the discipline of running those ten motions with the same seriousness an engineering team runs a dozen production services. Strkr builds the platform under that discipline.

Named owner

A person for every motion.

Every flow in the library carries a named owner. Changes route to that owner. Questions about an existing step land on that owner. The common failure where a motion runs for two years and nobody can explain who owns it or why it changed last March does not surface because every flow has a human attached.

Defined trigger

The specific event that starts the motion.

Every motion carries a defined trigger: a record change, a schedule, an external webhook, an assistant pattern. The trigger is documented alongside the flow definition. The ops lead reading a motion for the first time knows exactly when it fires.

Measurable SLA

A time window the motion is expected to hit.

Every motion carries an SLA: inbound routing hits the owner within 10 minutes, discount approval resolves within 24 hours, renewal brief ships 120 days before close. The SLA renders on the metrics panel. Breaches surface in the admin alert.

Change log

A readable history of why the motion exists.

Each flow carries a change log alongside its version history. The owner writes a short note on each publish explaining the reasoning. The seventh ops person to inherit the program understands the full context in two minutes instead of two days of archaeology.

Metrics panel

Runs per day, failure rate, average duration.

Each motion carries its own metrics: runs per day, failure rate, average duration, SLA attainment. The ops lead running a weekly program review sees the shape of each motion in one glance. The common failure where metrics live in a separate analytics tool does not happen.

Review before publish

Pending changes gate behind an approval.

A change to a core motion sits in review until the owner and a reviewer approve the diff. The pending version is testable in a sandbox. The live motion never silently changes under a deal in flight.

Rollback

One click back to any prior version.

If a change ships and breaks a downstream expectation, rollback is one click. The affected motion reverts to the chosen prior version. The audit log records the rollback with the user and the reason.

Documentation attached

The runbook lives on the flow, not in a wiki.

Each motion carries its runbook on the flow surface: what it does, what fires it, what happens if it fails, who to page. The documentation is one click from the flow definition. The common failure where the runbook lives in a wiki three navigation steps away and goes stale within a quarter does not happen.

Audit log

Who built, who edited, who ran, who approved.

Every change to a motion definition and every execution of a motion instance lands in the audit log. SOC 2 and HIPAA reviewers walk the full trail. The compliance posture ships inside the program itself.

The ten motions revenue teams actually run

From inbound routing to compliance archival, covered.

The ten motions a mid-sized revenue team runs are remarkably consistent across businesses. The specifics vary. The shapes repeat. Strkr ships a template for each one so the ops lead stands up the program in a week instead of a quarter. The first inbound routing flow deploys on Monday. The discount approval chain goes live on Tuesday. The renewal brief fires on Wednesday. The ops lead stops rebuilding the wheel from scratch and starts tuning the ten motions to the specific business.

Inbound routing

Form submit to assigned owner in under a minute.

A form submit scores the lead, routes to the right owner using named-account rules and territory logic, creates the first task with a 10-minute SLA, and alerts the owner on Slack. The ninety-minute response window becomes the ten-minute response window.

Outbound cadence launch

Multi-channel sequences wired to lead sources.

Outbound cadences launch based on lead source, segment, and persona. Email, SMS through Strkr Messaging, and task-based touches sequence across business days. The sequence pauses on reply and resumes on specific events.

Discount approval

Rule-driven routing with delegates and escalation.

Discount requests route to the regional manager, legal, security, and finance based on deal attributes. Parallel steps where possible. Delegated authority during PTO. Timed escalation after a configurable window. The chain runs in hours instead of days.

Renewal brief

120 days out, the paperwork drafts itself.

When a renewal falls inside 120 days of its end date, the flow drafts the renewal brief, generates the renewal order form, opens the renewal opportunity in the right stage, and schedules a CSM prep task.

Closed-won provisioning

Closed Won fires a dozen downstream actions.

An opportunity moving to Closed Won generates the signed order form, posts to the onboarding Slack, provisions the account in the product, emails the welcome sequence, creates the CSM kickoff task, and books the kickoff meeting.

QBR prep

One click, a live-data brief, every quarter.

Hit Generate QBR on an account. The flow assembles a six-section brief: relationship summary, usage story, open opportunities, support history, renewal timeline, and expansion recommendations. Every section pulls from live data.

Churn save plan

A score drop fires a save plan.

An account health score dropping across a tier threshold notifies the CSM, generates a save-plan brief, drafts a champion outreach, and adds the account to the manager watchlist. The red flag turns into a tracked motion.

Data hygiene sweep

A nightly check against the ten common gaps.

A nightly flow sweeps for incomplete records, invalid field combinations, orphaned child records, and decayed contacts. Issues post as lightweight tasks in the owner queue. The pipeline looks clean on the dashboard because it is clean on the records.

Compliance archival

Signed artifacts and consent events, retained correctly.

Signed documents, consent records, opt-out events, and audit log entries archive per tenant retention policy. The compliance team runs the yearly review without a half-quarter of data gathering.

How to actually ship a working program

The playbook most teams never write down.

The ops leaders who stand up a working workflow program share a playbook. They start with the one motion that costs the most hours per week. They ship the template, measure the SLA, iterate, and move to the next motion. They never try to ship ten motions at once. They never let a motion run for a month without a named owner. They write the runbook as they build. Strkr builds the platform under that playbook, with the templates, metrics, and change-management primitives that let a two-person ops team ship ten motions in a quarter.

Start with the biggest leak

The one motion that costs the most hours per week.

The ops lead picks the one motion that currently costs the team the most hours per week in manual work. Usually inbound routing or discount approval. Ship that one motion first. The ROI shows up on week two. Momentum builds for the second motion.

One motion a week

A sustainable rhythm beats a heroic sprint.

Ship one motion per week. Measure the SLA. Fix the two edge cases. Document the runbook. Then move to the next motion. The common failure where an ops team ships ten half-built motions in a month and six fail does not happen.

Owner on day one

No motion ships without a named human.

Every motion gets a named owner before it ships. The owner is on the hook for the SLA, the change log, and the quarterly review. The common failure where a motion runs orphaned for a year and nobody can explain why it keeps firing does not surface.

Runbook as you build

Document the motion while the context is fresh.

The runbook writes while the motion is being built, not six months later. What fires it, what it does, what happens if it fails, who to page, how to roll back. Attached to the flow surface, not buried in a wiki.

Metrics in the first week

If you cannot measure it, you cannot run it.

Every motion has a metric on the metrics panel from day one: runs per day, failure rate, average duration, SLA attainment. The common failure where a motion runs for six months before anyone instruments it does not happen.

Quarterly review

Walk every motion once a quarter.

The ops lead reviews every motion once a quarter: still used, still correct, still fast enough, still the right owner. Retire the motions that no longer earn their keep. The library stays clean.

Change management

Edit, review, publish, measure, iterate.

Every change to a motion goes through sandbox editing, reviewer approval, publish with a diff view, measure the SLA for a week, iterate if needed. The common failure where a well-meant edit breaks a live motion gets caught at the review.

Shared library

Reusable subflows for the common shapes.

The opt-out check, the consent log, the notification routing, the retry policy all live as shared subflows. Edit the subflow once, every motion that references it inherits the change. The institutional knowledge compounds.

Ownership rotation

A motion survives when the owner moves on.

When the owner of a motion changes roles or leaves, the handoff includes the runbook, the change log, and the metrics history. The next owner steps in without reconstructing the context. The program outlives any individual contributor.

Governance, measurement, and the quarterly program review

The discipline that makes the program a program.

The difference between a workflow program and a pile of flows is governance. The ops lead who runs a program measures SLAs week after week, reviews motions quarterly, retires the dead ones, documents the live ones, and writes the yearly roadmap for what gets automated next. Strkr builds the governance surface so the ops lead runs the program the same way a product leader runs a roadmap: visible, measurable, and owned.

Program dashboard

Every motion, one view, status at a glance.

The program dashboard shows every motion with its owner, SLA attainment, runs per week, failure rate, and last update. The ops lead running a weekly review opens one dashboard. The common failure where the program lives in a spreadsheet nobody updates does not happen.

SLA tracking

A target, a measurement, a trend line.

Every motion carries an SLA target. The metrics panel shows attainment week over week with a trend line. SLAs that miss consecutively trigger an admin alert. The ops lead sees the motion drifting before the business notices.

Quarterly review

A walk through every motion, every quarter.

The quarterly review walks every motion: still used, still correct, still owned, still measured. Retired motions move to the archive. New motions join the roadmap. The program evolves instead of accumulating.

Retirement path

A motion retires without stranding records.

A motion retires by running its outstanding executions to completion, blocking new executions, and marking itself deprecated. The common failure where retiring a motion strands a dozen records mid-execution does not happen because the engine respects in-flight state.

Compliance view

The ops program is also the compliance program.

The audit log, the opt-out handling, the consent capture, the retention windows all live in the same program. SOC 2 and HIPAA reviewers walk the same surface the ops team already runs. One review, one program.

Cost per motion

What each motion costs to run.

The metrics panel shows the cost per motion: AI invocations, external API calls, SMS sends. The ops lead running an efficiency review sees which motions earn their keep and which deserve a retune.

Reliability tracking

Error budgets per motion.

Each motion can carry an error budget: 99.5 percent success rate, 99.9 percent, or custom. Attainment tracks against the budget. Burned budgets trigger an admin alert and route to the on-call ops lead.

Roadmap view

What is live, what is pending, what is next.

The program roadmap shows motions by status: live, in review, in sandbox, in planning. The ops lead presents the roadmap to leadership once a quarter without a separate deck build.

Permissions on the program

Who runs what, visibly.

Program permissions follow the Strkr role model. The ops lead owns the program. Function leads own their motions. Builders edit flows. Operators run flows. Executives view metrics. The responsibility chain is explicit.

How the workflow program plugs into the rest of Strkr

The program earns its keep by connecting to everything.

A workflow program that lives in a separate tool is a glue layer. A workflow program that lives inside the CRM is the operating system of the revenue org. Strkr builds the second shape. Every motion in the program reads from and writes to the same records every other function uses. The permission model, the audit log, the messaging layer, the document stack, and the assistant all compose natively. The ops lead stops managing seams and starts running the business.

CRM native

Every motion reads and writes the same record.

Every motion in the program reads from and writes to the full CRM data model. The permission model, the audit log, and the compliance posture apply uniformly across every motion.

Native messaging

SMS and MMS as a first-class action.

Strkr Messaging is a native action in every motion. Delivery, opt-out, and consent events log automatically. The compliance posture inherits from the platform.

Native documents

Templates, approvals, signature, archive.

The document stack is native. Proposal generation, approval routing, signature, and archival all run as actions inside the program.

Native assistant

Strkr AI as a motion-level primitive.

The assistant runs inside motions as a native action. Drafts, summaries, extractions, suggestions, and scores all live as flow actions with no credit meter.

Native reporting

Every motion is a reportable dataset.

Every motion execution lands in a reportable dataset. The ops lead builds dashboards for program-level attainment, cost per motion, and reliability trends.

Open APIs

Webhooks in, REST out, every event.

Every event emits a webhook. Every motion and every record is readable through REST. External systems integrate without a middleware vendor in the path.

Flat seat pricing

No per-run fee, no per-step fee.

Strkr charges flat per seat. No per-run fee. No per-step fee. No per-contact tier. A high-volume program does not multiply the bill.

Compliance posture

HIPAA BAA, SOC 2 Type II in progress, GDPR aware.

The compliance posture applies uniformly across every motion. Regulated workloads do not require a separate stack.

Said simply

One platform, every motion, every function.

One record, one audit log, one permission model, one compliance posture, one assistant, one messaging layer, one document stack. The ops lead stops integrating tools and starts operating a program.

A workflow program revenue teams can actually run.

Ten motions, ten owners, ten SLAs, one platform. Templates for the common shapes. Governance built in. Open the admin surface on your real business and see how a sticky-note program becomes a running system by the end of the first week.

Start free See pricing
Common questions

What buyers ask about this feature.

What is a workflow program and how is it different from a workflow tool?

A workflow program is the deliberate set of ten or twelve repeatable motions a revenue team runs week after week, each with a named owner, a measurable SLA, a documented runbook, and a quarterly review. A workflow tool is the canvas you draw a flow on. The distinction matters because the program is the discipline that makes automation stick. Flows that run without owners accumulate drift. Flows that run without SLAs accumulate slow failures. Flows that run without runbooks accumulate tribal knowledge. Strkr builds the governance primitives (owners, SLAs, runbooks, metrics, change logs, reviews) alongside the canvas so the program is a running system, not a sticky-note list.

How many motions does a typical revenue org actually run?

Most mid-sized revenue orgs run ten to twelve motions that cover the vast majority of weekly automation work: inbound routing, outbound cadence launch, discount approval, renewal brief, closed-won provisioning, QBR prep, churn save plan, data hygiene sweep, compliance archival, and expansion play. The specifics vary by business. The shapes repeat across industries. Strkr ships templates for each one so the first motion deploys in a day and the full program stands up in a quarter.

How do we track SLAs and know when motions are drifting?

Every motion carries an SLA target (inbound routing hits the owner within 10 minutes, discount approval resolves within 24 hours, renewal brief ships 120 days before close). The metrics panel shows attainment week over week with a trend line. SLAs that miss consecutively trigger an admin alert routed to Slack, email, or SMS through Strkr Messaging. The program dashboard surfaces every motion and its attainment on one view, so the ops lead running a weekly review opens one dashboard instead of chasing numbers across six tools.

How do we handle change management on motions that are live?

Every change to a motion goes through sandbox editing, reviewer approval, publish with a diff view, and measurement for a week. The pending version is testable against sample records before it goes live. Rollback to any prior version is one click. The audit log records every edit, every approval, and every rollback with the acting user and timestamp. The common failure where a well-meant edit to a live flow breaks the overnight run gets caught at the diff review instead of at the overnight page.

What happens when the owner of a motion leaves or changes roles?

The handoff includes the runbook, the change log, and the metrics history, all attached to the flow surface. The next owner steps in without reconstructing the context. The program outlives any individual contributor because the institutional knowledge lives on the flow, not in a head. The quarterly review process catches orphaned motions (missing owner, no runbook, no metrics) and routes them for reassignment or retirement before they drift.

Does the workflow program ship on every tier or is it an add-on?

The workflow program (templates, metrics panel, SLA tracking, program dashboard, versioning, change log, runbook attached) ships on every paid tier at no extra charge. Strkr charges flat per seat with no per-run fee, no per-step fee, and no per-contact tier. Strkr Messaging usage bills at a transparent per-message rate separate from the seat. There is no premium automation SKU and no implementation partner requirement to stand up the program, because the primitives are the same system as the CRM.

Related features

Pair this with...

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