Glime for RevOps

Glime for RevOps

You own the policy everybody agrees with until the last week of the quarter. Glime makes that policy something the server enforces rather than something you chase.

What breaks today

The policy is a document, not a control

The discount matrix lives in a wiki page, a slide from last year's kickoff, and one manager's memory. Nothing in the quoting path reads it, so compliance depends on people remembering a rule while a deal is slipping.

Approvals happen where you cannot reconstruct them

A 32% discount gets waved through in a DM. Six months later Finance asks who approved it and the honest answer is that the thread has scrolled away. The approval happened; the evidence did not.

Changing the rule is a configuration project

Moving the manager threshold from 15% to 20% means editing an automation somebody else built, in a tool that will not tell you what else depends on it, and hoping the test deal you ran covers the edge cases.

What Glime does about it

  • The ladder is product behavior, not a flow you maintain — thresholds and roles are settings; the ordering, the role gate, and the refusals are enforced by the API for every tenant.
  • Nothing routes around it — a rep approving their own quote gets a 403, an out-of-order approval gets a 409, and past the ceiling nothing finalizes at all. That holds regardless of what the client sends.
  • Editing a pending quote resets its chain — approvers only ever sign off on the numbers in front of them, so "approved, then repriced" stops being a category of exception you have to police.
  • A tenant-scoped audit log — every submit, approve, reject, and finalize with actor and timestamp, exportable when Finance or an auditor asks.
  • Migration is a CSV, not a program — accounts, contacts, deals, and products come in through the in-app mapper, and records keep stable URLs afterwards.

How the approval ladder works → · Draft your own policy →

At a 50–200 person company

RevOps at this size is one person — sometimes half a person — and the discount policy is one of nine things they own. That changes what a good tool looks like. Nothing here needs a dedicated administrator, the ladder ships working, and the parts you would otherwise have to build and then keep alive (the ordering, the role gate, the audit write) are not yours to maintain.

Take a 120-person SaaS company: fourteen reps, about 60 quotes a month, two thirds of them carrying some discount, and a median discount of 8% on the ones that do. Put those numbers through the model the policy builder prints on its own page and the default 10/20/35/50 ladder routes roughly 10 quotes a month to a Sales Manager, 5 to a Director, and 1 to Finance, refusing less than one at the ceiling — which leaves about 44 that never touch an approver at all. Modelled, not measured: put your own quote volume and median discount into the builder and the estimate changes with them.

  • Managers are the first rung, because there is no deal desk yet — at this size the Sales Manager band absorbs most of what routes and the Finance rung is the CFO personally. Both are roles you assign in Settings, not an org chart you have to invent first.
  • The rollout is a week, and most of it is data — import accounts, contacts, and the catalog by CSV, set the thresholds to the policy you already run informally, invite the two managers. Teams generally have a governed quote on day two or three.
  • The first month tells you the policy you actually have — the audit log is the honest version of the discount matrix, which at this size has usually never been written down anywhere.

What you can measure in the first month

MetricWhy it is the one to watch
Approval latencyTime between submit and final decision, per rung of the ladder — the number that tells you whether governance is costing you deals.
Share of quotes that self-serveQuotes closed under the self-serve band and never routed. If this is low, your first threshold is set too tight.
Version churnHow many times a quote is repriced before it is accepted. Automatic v1 → vN means you can count it instead of guessing.
Exceptions grantedApprovals above the previous rung, by approver. Discount creep is visible as a trend rather than a quarter-end surprise.

What Glime will not do for you

Glime is not a configuration engine. If your catalog needs constraint solving across thousands of interdependent options, the tools on our Conga and Oracle comparisons are built for that and we are not. Glime is built for teams whose hard problem is the discount, not the configuration.

Questions revenue operations leads ask

Can we start with the policy we already run?

Yes, and it is usually the right first move. Set the thresholds to what you do today — including the ones nobody has written down — and let a quarter run. Enforcing the current policy tends to be the finding; changing it is the second conversation. The policy builder will draft the wording from your numbers.

How much of this is configurable versus fixed?

The thresholds, the roles they map to, the margin floor, and the ceiling are yours. The guarantees — ordering, the role gate, no self-approval, the audit write — are not configurable, which is the point. A rule you can switch off under pressure is not a control.

Where to go next

See it in the sandbox

The product is the demo. Open a live, read-only workspace — no signup — or start a free 14-day trial.

Open live sandbox Start free trial