01 / THE IDEA
A quotation is part of a conversation.
I’m building Common Ground around a moment that is familiar to small engineering and custom-development companies: a customer likes the proposal, but asks for a change before committing.
That change might be a lower price, a smaller upfront payment, a different scope or more confidence that the system will work. I wanted to create a workspace that helps the supplier understand the request before deciding what to offer.
The starting point is “Before your next conversation”: a focused place to review what was said, clarify what is still uncertain, compare practical options and prepare a response.
02 / THE PROBLEM
The price request is only the beginning.
A request for a discount does not always tell us what is making the customer hesitate. It could be uncertainty about technical performance, pressure on cash flow or a genuine limit on the total budget.
At the same time, the supplier has their own constraints. Keeping a team occupied, protecting delivery capacity and avoiding the loss of an opportunity can all influence the decision. I wanted the experience to make room for that judgement while keeping the commercial consequences visible.
My design question was: how can I help someone move from “Should I give a discount?” to “What do we need to understand, and which offer could work for both sides?”
03 / MY APPROACH
Start with the words. Then ask a better question.
I keep the customer’s exact statement separate from possible interpretations. The user can explore a concern about performance, payment timing or budget, or decide that more information is needed.
Each interpretation leads to a different clarification question and next action. A performance concern points towards measurable acceptance requirements. A payment concern leads to a discussion about milestones and cash flow. A budget concern prompts a closer look at what belongs in the scope.
I made confirmation and rejection explicit. Selecting an interpretation does not make it true, and playing a scripted reply does not automatically resolve the concern.
One complete conversation to explore
I used a fictional proposal for two custom inspection units with an eight-week delivery period. The customer asks for a 10% discount, while the supplier privately worries about losing the order. This gives the prototype a concrete decision to work through.
04 / COMMERCIAL JUDGEMENT
Make the consequences easy to compare.
I placed three offers alongside their estimated costs and margins so the user can see what changes before preparing a response.
| Option | Price | Full cost | Margin |
|---|---|---|---|
| Full project | ₹10,00,000 | ₹7,50,000 | 25% |
| 10% discount | ₹9,00,000 | ₹7,50,000 | 16.7% |
| Separate paid pilot | ₹4,50,000 | ₹3,30,000 | 26.7% |
With a supplier minimum of 20%, the discounted offer falls below the configured boundary. The calculation uses the current price and estimated full cost; possible future orders contribute nothing to today’s revenue or margin.
The paid pilot introduces a different commitment: a smaller scope with proposed measurable acceptance conditions. It does not promise the two production units at a lower price. Any subsequent production order needs its own scope and quotation.
I also kept cost estimates editable. A verified change in delivery cost should change the comparison, while assumptions and missing information remain available for review.
05 / SPACE TO THINK
Private reflection. A considered response.
When the user chooses a discount, I ask what is driving the concession. Changed scope, revised costs, a confirmed commitment and concern about losing the order each deserve a different follow-up.
I keep this reflection private. The customer-facing draft and export contain the proposed offer and response, while internal notes and concession reasons stay out. The user can edit the response and save demo revisions before continuing the conversation.
A compact timeline brings together the customer statement, the current concern, the proposed option and the unresolved question. Even when a simulated customer shows interest, that question stays open until the user explicitly marks it resolved.
06 / WHERE I WANT TO TAKE IT
Build judgement through decisions and outcomes.
This prototype lets someone work through a complete fictional negotiation: clarify a concern, compare offers, inspect scope and cost, prepare a response and see how a follow-up question changes the conversation.
The replies are predefined branches. I’m not presenting them as live AI analysis, predictions or evidence of how a real customer would react. The prototype also keeps its demo state separate from real quotations.
My next step would be to connect the experience to the existing application’s costing, scope, quotation and revision workflows. Beyond that, I want to explore how domain expertise, reviewed decisions and actual outcomes can help teams make better-informed choices over time.
The direction is to support the person making the decision: help them ask clearly, see the trade-offs and choose an agreement they can deliver sustainably.
Explore the prototype ↑