Skip to content
Product Lab
Product case studyLive product in active use

OfferIntel

A live real estate platform used by real users. OfferHub collects and compares offers and carries an accepted offer through to closing, with OfferIntel's aggregated market intelligence underneath.

Market intelligence · Offer management · Transaction workflow · Product strategy

Live product. OfferIntel is a real, deployed platform created by Azmera, drawing on her brokerage and transaction-operations experience. It is live at myofferintel.com and in active use by real users. This case study is based on the product's own source code and internal product documentation. "Implemented" means a capability exists in the product; "Shipped" is used only where operating records show it running for users. Metrics are proposed measures, and no user counts, revenue or performance results are reported.

Labels used below:ShippedImplementedProposedNon-goal

01

Problem

A home sale passes through three disconnected stages: offers, the transaction, and ownership afterward. Each lives in a different tool, and none of them share a single record. A property's final sale price shows where a negotiation ended, not how it unfolded.

  • Offers arrive by text, email and PDF, and listing agents compile them by hand before a deadline
  • Terms beyond price (financing, earnest money, inspection and appraisal contingencies, escalation, settlement timing) shape how sellers weigh offers but are rarely recorded in a comparable form
  • An accepted offer should start the closing process; instead the same details are re-entered into another system
  • Inspection reports, repairs and warranties are scattered once the file closes, so the next owner starts over
  • What a team learns about competitive offers stays in individual inboxes instead of becoming shared market context
  • Offer information is commercially sensitive, so any solution has to respect confidentiality, licensing rules and brokerage obligations
02

Users

These roles come from the product's access model, where each person sees only their own part of a deal. The needs come from the workflow and Azmera's brokerage experience, not from a formal user study, and no user counts are reported.

  • Listing agents: set up a listing, share one offer link, compare offers and respond
  • Buyer's agents: submit and revise offers through the link, track offer status, and start a transaction from the buyer side even when the listing agent does not use the platform
  • Team leads and brokerage admins: team and brokerage dashboards, member management and scheduled internal briefs
  • Transaction participants (coordinators, lenders, title, inspectors, appraisers, insurers): a stripped-down view showing only their own milestones and the property basics
  • Buyers and sellers: a client portal with milestones, deadlines and notes to their agent; sellers benefit indirectly from a clear, read-only summary of competing offers
  • Title partners: bulk upload of closed transactions that feed aggregated market statistics
  • Homeowners: a Home Passport for the property after closing
03

Discovery

Discovery drew on Azmera's hands-on experience in brokerage and transaction operations, then on building the product itself. The product documentation shows how the core definitions were settled. No interview study or survey results are reported here.

  • What counts as one offer, and what is a revision? Each change to an offer is saved as a numbered version recording which fields changed
  • Is an offer the same thing as a transaction? No. Offers exist before acceptance, many per listing; a transaction exists only after acceptance, exactly one per accepted offer
  • Who may see what? Least access by role. For example, the appraisal report and appraised value are visible only to the buyer, the buyer's agent and the appraiser, not even the listing agent
  • How are outcomes documented? Accepting an offer records the accepted terms, and closed outcomes are anonymized into market statistics
  • Open question: data contributed by participating agents and title partners may not represent the whole market, so ZIP codes with thin data are labeled low-confidence rather than shown with false precision
04

PRD

Requirements as built. "Implemented" means the capability exists in the product's code and database; it does not by itself confirm how widely each capability is used. Non-goals are deliberately excluded.

  • ImplementedListing setup with a secure offer link: buyer's agents submit without an account, entering price, financing type, down payment, earnest money, inspection terms, appraisal, financing and home-sale contingencies, escalation increment and cap, seller subsidy, closing date and offer expiration, plus pre-approval or proof of funds
  • ImplementedOffer statuses (submitted, revised, withdrawn, rejected, accepted, expired) with a numbered revision history
  • ImplementedSide-by-side comparison of price, earnest money, contingencies, escalation and closing timeline, used in both the agent's view and the seller's read-only summary
  • ImplementedOne response flow to decline, counter, request highest and best, or invite backup offers; acceptance records the accepted terms
  • ImplementedAI-assisted offer summaries, offer comparisons and draft response emails that work only from recorded offer data and leave decisions to the agent
  • ImplementedTransaction workspace created automatically from the accepted offer, or started by the buyer's agent, with buyer, seller and shared milestones, due dates and an activity feed
  • ImplementedRole-based participant model (11 roles) with least-access visibility, and a client portal for buyers and sellers that keeps them out of agent tools
  • ImplementedMarket intelligence combining agent-entered outcomes, anonymized accepted offers and title-partner uploads: a competitive pressure index, outcome distribution, offer-to-list trends, earnest money and contingency patterns, ZIP comparisons and weekly briefs
  • ImplementedHome Passport opened for the property at closing, holding systems, maintenance, improvements, documents and contractors
  • Non-goalDeal-level instructions, predictions of which offer will win, or client advice
  • Non-goalStoring personal data, MLS data or transaction paperwork such as purchase agreements, loan documents or wire instructions (only completion status is tracked)
  • Non-goalActing as a CRM or a transaction-coordination service
05

Prioritization

The main product decisions and the trade-offs behind them, taken from the product's documentation and build history.

  • Capture data inside the workflow: the offer workspace was built so market data comes from work agents already have to do, not from extra data entry
  • Free workflow, paid intelligence: OfferHub is free for agents, while market intelligence is subscription-only and requires license verification
  • Make the transaction its own record: an internal gap analysis found the first transaction screen only existed on top of an accepted listing, so transactions became their own records with participants, milestones and permissions
  • Compliance over precision: escalation figures are shown as ranges or frequencies, never exact amounts, and "outcome distribution" is used instead of "win rate"
  • Record what happened, don't store paperwork: completion status is tracked, but sensitive documents are not stored
  • Not now: automated recommendations that would stand in for professional judgment
06

Wireframes

Screenshots are not published here, to avoid exposing client or transaction data. The key screens as they exist in the product are listed below. The live product is at myofferintel.com.

  • Listing and offer link
  • Offer comparison
  • Offer detail and revisions
  • Seller offer summary
  • Transaction workspace
  • Client portal
07

Roadmap

Milestones are dated from when each capability first appears in the product's database history, an internal build record rather than public launch dates. Remaining items are proposals from the product's own gap analysis.

  • ImplementedDec 2025: market-intelligence foundation with accounts, roles and agent-entered offer outcomes
  • ImplementedMay 2026: title partner program with partner organizations, invitations and bulk closed-transaction uploads
  • ImplementedJun 2026: OfferHub offer workspace with listings, the offer link, revisions and combined market data
  • ImplementedJul 2026: transactions as their own records, side-aware milestones and Home Passport
  • ImplementedAug 2026: client portal, limited access for invited agents, security hardening and version 2.0 of the master product document
  • Implemented2026: asset-manager disposition portal (portfolio dashboard, disposition room, offer comparison and approval chains) with a sample-data demo
  • ProposedOne organization model covering lenders, inspectors, insurers and title companies alongside brokerages
08

Metrics

Proposed measures for evaluating OfferIntel. The product is live and in use, but no measured results are reported here.

  • ProposedShare of a listing's offers received through the offer link rather than by email or text
  • ProposedCompleteness of recorded offer terms (financing, contingencies, earnest money, closing timeline)
  • ProposedTime from offer deadline to seller decision
  • ProposedShare of accepted offers that become a transaction workspace without details being re-entered
  • ProposedShare of milestones completed by their due date
  • ProposedShare of ZIP codes with enough contributed data to remove the low-confidence label
09

Launch & Lessons

OfferIntel is live at myofferintel.com and in use by real users. No user counts, revenue or performance outcomes are reported here. The items below come from the product's operating records and from building it.

  • ShippedSign-up for licensed agents, with license verification and admin approval before full access
  • ShippedMonthly OfferIntel Market Pulse email; each issue is refreshed, previewed and approved before release
  • An offer is not a transaction: separating the two made permissions, milestones and the hand-off to closing much clearer
  • Least access has to be designed role by role, not added afterwards
  • Compliance language is a product requirement: every analytical view carries a historical-context disclaimer
  • Data from participating transactions may not represent the whole market, so its limits have to be stated, not hidden