Building a deal management system that reduced setup time by ~92%.
About the company
Tap Invest is a marketplace for fixed-income investment options for HNIs and UHNIs, offering products across Invoice Discounting, Asset Leasing, Bonds, Fixed Deposits, and Fractional Real Estates.
Tap Invest is further divided into 2 verticals. Tap Invest serves retail investors who invest in the deals available on the platform. On the other hand, Tap Capital is the B2B vertical that gives companies a platform to raise operational debt. All the deals on Tap Invest come from Tap Capital.
For this case study, I’ve focused on the deal creation on our platform and solving cases which occur in day-to-day work of deal creation & management.
Context: This is Part 2 of the Roots case study. Part 1 covered the client module case study and explained how we moved client onboarding and inventory management from Sheets and Drive into one system. This part explains what happens next: how the customer success team turns that inventory into deals.
The Investor Success (IS) team will use the Deal Module to create, manage, and publish deals. The Investment (Credit/Risk) team and Management review and approve deals at different stages.
Problem Brief
Deal creation is the most important process in the business. Every detail must be correct. But the process was completely manual.
There was no system for creating deals. Every deal was injected as raw JSON directly into the server, and every detail required constant back-and-forth between the Investment team and the Investor Success (IS) team. The process depended on people, memory, and messages — with real money on the line.
The seven core problems
| Problem | What was happening | Design challenge |
|---|---|---|
| Fully manual, high-stakes process | Every detail of every deal had to be correct, yet the entire process ran on constant coordination between the Investment and IS teams with no system to catch what humans missed. | How might we make correctness a property of the system instead of a product of coordination? |
| JSON injection & engineering dependency | With no tooling, deals were hand-written as JSON and injected directly through the server — requiring the Product and Tech teams for every deal, and every fix. | How might we let a non-technical team create and publish deals safely, without engineering in the loop? |
| Half a day per deal with no certainty | Creating a single deal took half a day of coordination and manual work, and even then there was no assurance it was error-free. Slow and unreliable — the worst of both. | How might we cut deal creation time drastically while increasing confidence in correctness? |
| Deals created on inventory alone | If inventory existed, a deal could be made even when securities or NACH were missing, or the sanction limit was already fully utilized. This over-utilization exposed the company to serious risk from a recovery standpoint. | How might we make deal eligibility — not just inventory availability — a hard precondition for deal creation? |
| Uncontrolled exceptions | Sometimes the business had a genuine reason to issue money despite an unmet condition — but with no formal exception process, this loophole was abused. | How might we allow legitimate exceptions while making every one of them visible, deliberate, and accountable? |
| Fragile live deals | Errors while filling in details were frequent, forcing many deals to be taken down. If investors had already paid, their money had to be refunded to their accounts — turning an internal mistake into a very bad user experience. | How might we catch errors before publishing, and make post-launch changes non-destructive? |
| No deal management or customization | The IS team had no way to tailor the deal experience — no better offers for heavy investors, no special offers for first-time users, no scheduling deals ahead of time, and no way to keep a deal internal to the platform. | How might we let the IS team control who sees which deal, when it goes live, and on what terms? |
Baseline & Goal
Before designing anything, I wanted to understand the real workflow and experience it — and set a baseline that the new system had to beat before we could call it successful.
How I gathered the baseline
I sat down with the Investor Success team and made a single deal from start to finish. Here’s how one deal’s day actually looked:
- ~1 hour chasing data from the Analyst team: First, the IS team had to gather everything investors might want to see before investing. This included the company logo, a short write-up about the company, and the company’s reports.
- 2–3 hours in the sell-side planning meeting: The team decided how much of the client’s inventory to sell in this deal. And while the Tap Invest app shows deals, most deals were actually closed manually, by the Relationship Manager (RM) team calling and texting investors to take up the deal. So this planning wasn’t just a formality — it shaped real, person-by-person outreach.
- 3+ hours filling out the JSON: A template existed, but every value had to be entered by hand. And because every detail had to be accurate with no room for mistakes, this took at least three hours of focused, uninterrupted work.
- At the end of the day, it was handed off to Tech/Product, who put the JSON into the server to make the deal live on the platform.
Total: one full working day to create a single deal, with no guarantee — even then — that it was error free. For a team whose entire job was keeping deals live for investors, this was the bottleneck.
Goals
- Reduce TAT: Cut deal creation from a full day to about 30 minutes, by pulling client data automatically from the Client Module (no more one-hour data chase) and replacing 3+ hours of JSON entry with a structured form.
- Zero engineering dependency: The IS team creates, verifies, and publishes deals entirely on their own — no JSON handoff, no waiting on Tech/Product.
- Zero product errors reaching investors: Every deal passes structured validation and human verification before going live. No more taking deals down and giving refunds after people have already invested.
- Give IS control over the deal experience: Scheduling, visibility, and investor-level customization handled by the team itself, directly from the platform.
- Full adoption: 100% of deals created through Roots, with no fallback to JSON.
These became the benchmarks for every design decision that followed.
Solution
Note: I have used IS for Investor Success and IA for Investment Analyst from here on.
With a clear understanding of the problem and the process, I started working on the Deal Module and divided it into three stages:
- Deal Creation — where the IS team creates deals from clients that have inventory available.
- Maker & Checker — where Analysts and Management verify the details of a deal and decide whether it can go live.
- Deal Status — a single place to track every deal: sent for verification, approved, live, scheduled, internal, or past.
Creating a Deal
Problem:
- Writing JSON by hand was critical, high-stakes work for the IS team. It took hours and even then, errors still slipped through.
- There was no check on which clients’ inventory was actually ready for a deal and which wasn’t.
- Every deal depended on other teams.
Solution: Deals are organized at the company level, just as the team was used to. This gives the IS team a better overall view and better planning of what to make a deal on, and how. From a management standpoint, we also solved a tricky edge case: what happens when someone tries to create a deal for a company that doesn’t have the required sanction letter or securities.
Key design decisions
- Predefined details instead of free-form input: Manually filling in JSON was the main cause of mistakes. Most details now come directly from the system, which removed many of these errors from the start. The team only fills in what’s genuinely new — the deal name, the amount, when to make it live, and for how long.
- A simple layer of verification after creating a deal: Review used to happen in chats and spreadsheets. Now, once a deal is created, it’s automatically sent to the Analyst team for verification.
- Exceptions aren’t blocked — they’re escalated. For exceptional cases, we don’t stop deal creation. Instead, the request goes to Management; only if they review and approve does the deal move on to Analyst verification. So we never block the team from creating a deal — we just added a layer of friction so an unwanted deal can’t be created easily.
Maker & Checker
We were introducing a brand new system, and even though the system itself validates data, we still had to make sure every deal going live on the platform is error free. So we added two-factor checking of deals, in two steps:
- Management Verification: Any deal marked as exceptional comes here first. Someone from Management reviews and approves it before it can move forward.
- Analyst Verification: Every normal deal created by the IS team, and every exceptional deal cleared by Management, comes here. An Investment Analyst rechecks the details and marks the deal approved for going live.
Once approved, the IS team can make the deal live at whatever time works best.
Deal Status
This stage didn’t exist before. It exists because of the new system. The old process had no stages to track: a deal was either a JSON file in someone’s hands or live on the platform. But once deals started moving through creation, verification, and approval, the team needed one place to see where every deal stands.
Deal Status is that place: a single tracking view where every deal sits by its state — whether it is sent for verification, approved, live, scheduled, internal, or a past deal. At a glance, the IS team knows what is waiting on Management, what has cleared Analyst verification, what is live right now, and what is coming up. No asking around, no digging through chats.
Managing Live Deals
Problem: Once a deal went live, there was no way to change it, take it down, or schedule it without depending on Tech/Product. And if a live deal had any issue, the team had to put in the same full effort all over again to recreate it.
Solution: The deal live page gives the IS team direct control over published deals:
- Toggle visibility: hide a deal from the Tap Invest app instantly, at any time, without destroying it or triggering refunds.
- Custom visibility: show a deal only to specific, selected users, enabling targeted or early-access offerings.
What used to be a destructive, investor-facing operation became a reversible, invisible one.
Results
Deal creation without engineering
- Before: Every deal ended with a JSON handoff to the Tech/Product team, who injected it through the server to make it live.
- After: The IS team creates, verifies, and publishes deals entirely self-serve.
- Result: Engineering involvement in routine deal operations dropped to zero.
Faster deal turnaround
- Before: A full working day per deal — ~1 hour chasing data, 2–3 hours of planning, 3+ hours of JSON entry, then the engineering handoff.
- After: <5 mins per deal creation and a few seconds to make the approved deal live.
Errors caught before going live, not after
- Before: Mistakes were discovered on live deals; the only fix was take-down + recreate, sometimes with investor refunds taking 2–3 days.
- After: Predefined terms, condition checks (NACH, securities, sanction limits), and mandatory Investment verification catch issues before publishing. Cutting the errors to zero automatically eliminates the reason for issuing refunds to investors.
Reflection
- Constrain the input, and you have already prevented most errors. Replacing free-form JSON with predefined terms and structured selection did more for data quality than any amount of validation messaging could.
- Make the checkpoint structural, not procedural. People forget process steps; systems don’t. Moving Investment verification and management approval into the flow meant compliance stopped depending on discipline.
- Design the exception path with as much care as the happy path. The Deal Blocker flow is where the real business risk sat — and where a rigid “computer says no” would have pushed the team back to workarounds.
