Sales flexibility.
Pricing boundaries.

A salesperson needs to assemble an offer. An administrator needs it to respect the product catalog, discount limits and approved terms. The customer needs a document clear enough to act on. These are connected jobs, but they do not need the same interface or permissions.

Revora began with a product hypothesis: there may be room between flexible spreadsheets and complex configure-price-quote tools for a more focused quoting workflow. A spreadsheet lets someone change almost anything; that flexibility also makes it difficult to distinguish an intentional exception from an accidental override.

I did not treat that hypothesis as proven market demand. It gave me a concrete design question: how could the product make an approved quote easier to create than an incorrect one?

My starting evidence was the evolving product brief, workflow discussions, design explorations and implementation constraints. This was founder-led discovery—not a completed interview study. I used that material to identify questions the interface had to answer before adding more screens.

The role split and required quote behavior gave me a testable scope. Problem frequency, fit with existing tools and willingness to adopt remained hypotheses. My work connected that framing to information architecture, interface decisions and design QA—not fictional personas or estimated time savings.

The catalog, rules and templates feed the quote journey. Keeping those setup tasks separate lets the builder focus on the offer in front of the salesperson. This map groups the current navigation by responsibility; it does not imply that every role sees every destination.

I organized the product around responsibilities rather than demographic personas. Administrators establish commercial boundaries. Sales uses that configuration to build a customer-specific offer. Giving both roles the same unrestricted editor would make the distinction cosmetic.

The original flow makes the dependencies explicit.

My Admin flow maps selecting a discount rule, setting limits and messages, validating the configuration and saving it. The Sales flow then maps customer information, products, live calculations and a validity decision. Invalid input leads to inline feedback; valid input can become a draft or move into export review.

Explore the original flow board ↗

The key distinction is between working, correcting, saving and committing a customer-facing document. Validation happens during pricing and again on the server; it is not an extra task sales must remember.

The original board explored a broader workspace: onboarding checklists, template browsing, multiple export formats and export history. The current product narrows the key journey into a guided builder and PDF review. The flow’s decision boundaries survived; not every early branch became a shipped capability.

Implementation also exposed the difference between a visible option and a supported calculation. The most important evolution was therefore not decorative. It was toward explicit support boundaries: fixed/per-seat prices and supported discounts on the core path; unsupported taxable, tiered, prorated and usage-based calculations blocked rather than quietly producing an unreliable quote.

Figma supported flow and interface exploration; ChatGPT helped explore UI directions and Codex supported implementation. Not every shipped screen began as a completed Figma frame. My responsibility was to specify behavior, judge the generated output, connect states and inspect what actually shipped.

Generated output is not research evidence. It makes the product testable. The separate Revora Design System study covers reusable foundations; this story concerns the product decisions those foundations serve.

The shipped interface connects administrative configuration to quoting. The rule list makes ownership visible; the builder applies that configuration; the preview shows what leaves the workspace. These are current product captures, not polished mockups presented as production.

Configure once. Apply during quoting.

Administrators manage versioned rules. Sales should not need to rediscover those policies for each offer. Broader rule categories remain visible in navigation; that does not mean every category is supported by the calculation engine.

Give each quote an approved starting point.

Only published templates are offered in the builder. Template selection brings configuration into the quote before sales starts editing, while the stepper explains what comes next.

Show the effect of each permitted change.

In this sample, three units at $19.99 produce a $59.97 subtotal. A 12.5% discount becomes $7.50 after rounding, leaving $52.47. The same amount appears in the saved preview. This is a correctness example, not a revenue or impact metric.

Review the offer as the customer will see it.

The final preview shown at the beginning of this story keeps editing controls separate from the customer document. Recipient, terms, expiry and total can be checked before export. A saved draft is not the same state as a generated PDF.

Open the live product ↗ · Access is controlled. Ask me for a walkthrough to explore both roles without publishing account credentials.

The pre-pilot technical review tested supported calculations, discount boundaries, role separation, workspace isolation, saved-quote persistence and PDF output. Its documented lifecycle check covered configuring a quote, correcting an invalid discount, saving, signing in again, reopening the record and generating its PDF.

During this case-study review, I also inspected the live sandbox and reproduced the pricing states shown above. This is product and technical verification. It does not establish that a sales team finds the workflow intuitive, adopts it regularly or saves time using it.

Next, I would observe administrators configure an offer and salespeople complete it without coaching. I would watch where they hesitate, whether they understand a warning versus a block, and whether the preview gives them confidence to export. Those are proposed validation questions, not completed findings.

Revora changed how I think about simplifying enterprise work. Removing controls is not enough. A simpler interface has to preserve the business meaning of what remains: who owns a price, what a warning permits, when a document becomes final, and why a historical record should not change.

The strongest part of this work is the connection between those decisions and a running, inspectable workflow. The weakest part is the evidence I do not yet have: independent user behavior and adoption. I would rather make that boundary clear than turn a technical pass into an invented business outcome.

Next, I would improve rule-message specificity, test the five-step sequence with target users, and resolve the release gates before widening scope. The ambition is still a fast quoting experience. The lesson is that speed is only valuable when the person using it can trust the result.