RevOps use case
Deal desk
A non-standard deal needs several sign-offs. Three of them arrive as Slack replies, one of them lives in an email thread, and all of them end with someone asking "any update?" in a channel.
Where it breaks today
Most deal approval workflows were never designed. They grew. A rep needs a discount beyond the standard band, a custom payment term or a non-standard clause, so they post in a channel and tag whoever approved the last one.
Legal replies in a thread. Finance replies by email. Security asks a question nobody answers for two days. The rep chases all three, the deal slips a week, and the terms that were finally agreed live in a screenshot.
At quarter end, nobody can say which deals carried which exceptions, or who signed them off.
What it does
Deal desk works the way your team already does.
One request, routed in order
Legal, security and finance see the deal when it's their turn, not all at once in the same channel.
Terms written back automatically
Approved terms land in the CRM as fields, not as screenshots.
An auditable trail
Every approval is recorded with who approved what, and when.
Status without chasing
The requester can see where their deal is, so nobody has to ask.
How it works
- 1.The rep raises a request from the opportunity, with the deal details pulled from the CRM record.
- 2.The app works out which approvals this deal needs, using your rules: discount depth, contract length, non-standard clauses, data requirements.
- 3.Each approver is asked in turn, in the tool they already use, with the context they need to decide.
- 4.Questions and conditions stay attached to the request, so the next approver sees them.
- 5.Approved terms are written back to the CRM as fields.
- 6.The requester and their manager can see where the deal stands at any point.
Before and after
| Step | Today | With a deal desk app |
|---|---|---|
| Raising a request | A Slack post and a tag | One request from the opportunity |
| Who approves | Whoever replied last time | Set by your rules, in order |
| Status | "Any update?" | Visible to the requester |
| Approved terms | Screenshots and threads | CRM fields |
| Audit | Rebuilt from memory | Who approved what, and when |
Questions
We already have approvals in our CRM or CPQ. Why this?
Keep them if they work. Teams usually come to us when the real approval process has outgrown the configured one, and the exceptions run through Slack and email. We build around the process your team follows today, including the parts no tool covers.
Do we need Salesforce?
No. The tools shown are examples. The app runs on the CRM and messaging tools you already have.
Who maintains the approval rules when they change?
We do. Hosting, monitoring and changes to the process are part of the service, so a new threshold or a new approver doesn't need your engineering team.
How long does it take?
A working version in days, on your real data, and production by week four. The pilot is one workflow, fixed scope and fixed fee.
Where does our deal data live?
In your systems and your accounts. Apps come with SSO, role-based access and audit logs by default.
Other use cases
Other workflows we build.
Your best people are doing the work your software should be doing.
Track builds that software, designed around how your team actually works, running on the tools you already have. A working app in days, in production within four weeks. The longer that workflow runs by hand, the more it costs you.