US20140100905A1

US20140100905A1 - Home tour and open house scheduler

Info

Publication number: US20140100905A1
Application number: US14/047,820
Authority: US
Inventors: April Alexander; Jennifer Chao; Darren Yeung; Vincent Chang; Ben Lasley; Ben Fulton; Jansen Sheng; James Demichele; Thomas Young; Shrenik Devasani; Navtej Sadhal; Luke Misenheimer; Haiyun Helen Weng; Hamilton Nguyen; Timothy Woo; Seth Goldenberg; Chung Lai; Justin Yan; Meghan Kilgore; Julia Teitelbaum
Original assignee: Individual
Current assignee: Individual
Priority date: 2012-10-05
Filing date: 2013-10-07
Publication date: 2014-04-10
Also published as: US20140143644A1; US20140100956A1; US20160337481A1; US9406082B2; US9706011B2; US20140344112A1; US20140236768A1; US20180007169A1; US20140101235A1

Abstract

A computer-implemented method includes providing to a user access, via an electronic network, to a memory device on which are stored listings of parcels of real property. A selection of a set of the stored listings is received from the user via the electronic network. In response to receiving the selection, at least a portion of a first itinerary is generated including an indication of at least one time at which the user will receive permitted physical access to at least one parcel of real property associated with the selected set of stored listings. The first itinerary is then provided to the user.

Description

PRIORITY CLAIM
The present application claims priority from U.S. Provisional Application No. 61/710,606, filed Oct. 5, 2012, which is incorporated by reference as if fully set forth herein.

BACKGROUND

Real estate transactions often involve a buyer, a seller, one or more agents (e.g., a listing agent for the seller and buyer's agent for the buyer), and numerous service providers (e.g., escrow professionals, appraisers, home inspectors, lenders, and so forth. In a typical purchase transaction, the seller lists a property using a listing server, often through a listing agent, while buyers go through a search process to identify potential properties to buy. Once the buyer identifies a property the buyer wants to buy, the buyer makes an offer to the seller, potentially each through their respective agents. The seller may either accept the offer, counteroffer at a different price or other terms, or reject the offer. Once an offer or counteroffer has been accepted, the transaction is typically considered pending and on the way to closing pending inspections, resolving various contingencies, securing funds from a lender, and so forth.
Because of the many events and parties involved in a real estate transaction, it is often difficult for prospective buyers and sellers to organize times at which the prospective buyer may tour a seller's property. Buyers need to react quickly to new listings, price drops, and open houses. They also need to coordinate with their agent (and possibly with co-buyers) on events like inspections, contingency removal, loans, and so on. Sellers also need to coordinate with their agent on events like changes to their listing, buyer inspections, and so forth. Keeping track of all of these details or otherwise trying to efficiently schedule property viewings by a potential purchaser can be overwhelming, if not impossible.

BRIEF DESCRIPTION OF THE DRAWING

Preferred and alternative embodiments of the present invention are described in detail below with reference to the following drawing figures.

FIG. 1 is a schematic view of an exemplary operating environment in which an embodiment of the invention can be implemented;

FIG. 2 is a functional block diagram of an exemplary operating environment in which an embodiment of the invention can be implemented;

FIG. 3 illustrates a process according to an embodiment of the invention;

FIG. 4 illustrates a process according to an embodiment of the invention; and

FIGS. 5-9 are screenshots illustrating functionality of an embodiment of the invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

This patent application is intended to describe one or more embodiments of the present invention. It is to be understood that the use of absolute terms, such as “must,” “will,” and the like, as well as specific quantities, is to be construed as being applicable to one or more of such embodiments, but not necessarily to all such embodiments. As such, embodiments of the invention may omit, or include a modification of, one or more features or functionalities described in the context of such absolute terms.
FIG. 1 illustrates an example of a computing system environment 100 in which an embodiment of the invention may be implemented. The computing system environment 100, as illustrated, is an example of a suitable computing environment; however it is appreciated that other environments, systems, and devices may be used to implement various embodiments of the invention as described in more detail below.
Embodiments of the invention are operational with numerous general-purpose or special purpose computing system environments or configurations. Examples of well-known computing systems, environments, and/or configurations that may be suitable for use with embodiments of the invention include, but are not limited to, personal computers, server computers, hand-held or laptop devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like.
Embodiments of the invention may be described in the general context of computer-executable instructions, such as program modules being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Embodiments of the invention may also be practiced in distributed-computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.
With reference to FIG. 1, an exemplary system for implementing an embodiment of the invention includes a computing device, such as computing device 100. The computing device 100 typically includes at least one processing unit 102 and memory 104.
Depending on the exact configuration and type of computing device, memory 104 may be volatile (such as random-access memory (RAM)), nonvolatile (such as read-only memory (ROM), flash memory, etc.) or some combination of the two. This most basic configuration is illustrated in FIG. 1 by dashed line 106.
Additionally, the device 100 may have additional features, aspects, and functionality. For example, the device 100 may include additional storage (removable and/or non-removable) which may take the form of, but is not limited to, magnetic or optical disks or tapes. Such additional storage is illustrated in FIG. 1 by removable storage 108 and non-removable storage 110. Computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules or other data. Memory 104, removable storage 108 and non-removable storage 110 are all examples of computer storage media. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by device 100. Any such computer storage media may be part of device 100.
The device 100 may also include a communications connection 112 that allows the device to communicate with other devices. The communications connection 112 is an example of communication media. Communication media typically embodies computer-readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, the communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, radio-frequency (RF), infrared and other wireless media. The term computer-readable media as used herein includes both storage media and communication media.
The device 100 may also have an input device 114 such as keyboard, mouse, pen, voice-input device, touch-input device, etc. Further, an output device 116 such as a display, speakers, printer, etc. may also be included. Additional input devices 114 and output devices 116 may be included depending on a desired functionality of the device 100.
According to one or more embodiments, the combination of software or computer-executable instructions with a computer-readable medium results in the creation of a machine or apparatus. Similarly, the execution of software or computer-executable instructions by a processing device results in the creation of a machine or apparatus, which may be distinguishable from the processing device, itself, according to an embodiment.
Correspondingly, it is to be understood that a computer-readable medium is transformed by storing software or computer-executable instructions thereon. Likewise, a processing device is transformed in the course of executing software or computer-executable instructions. Additionally, it is to be understood that a first set of data input to a processing device during, or otherwise in association with, the execution of software or computer-executable instructions by the processing device is transformed into a second set of data as a consequence of such execution. This second data set may subsequently be stored, displayed, or otherwise communicated. Such transformation, alluded to in each of the above examples, may be a consequence of, or otherwise involve, the physical alteration of portions of a computer-readable medium. Such transformation, alluded to in each of the above examples, may also be a consequence of, or otherwise involve, the physical alteration of, for example, the states of registers and/or counters associated with a processing device during execution of software or computer-executable instructions by the processing device.
As used herein, a process that is performed “automatically” may mean that the process is performed as a result of machine-executed instructions and does not, other than the establishment of user preferences, require manual effort.
Referring now to FIG. 2, an embodiment of the present invention may take the form, and/or may be implemented using one or more elements, of an exemplary computer network system 200. The system 200 includes an electronic client device 210, such as a personal computer or workstation, tablet or smart phone, that is linked via a communication medium, such as a network 220 (e.g., the Internet), to an electronic device or system, such as a server 230. The server 230 may further be coupled, or otherwise have access, to a database 240 and a computer system 260. Although the embodiment illustrated in FIG. 2 includes one server 230 coupled to one client device 210 via the network 220, it should be recognized that embodiments of the invention may be implemented using one or more such client devices coupled to one or more such servers.
The client device 210 and the server 230 may include all or fewer than all of the features associated with the device 100 illustrated in and discussed with reference to FIG. 1. The client device 210 includes or is otherwise coupled to a computer screen or display 250. The client device 210 may be used for various purposes such as network- and local-computing processes.
The client device 210 is linked via the network 220 to server 230 so that computer programs, such as, for example, a browser, running on the client device 210 can cooperate in two-way communication with server 230. The server 230 may be coupled to database 240 to retrieve information therefrom and to store information thereto. Database 240 may have stored therein data (not shown), such as real-property listings, that can be used by the server 230 to enable performance of various aspects of embodiments of the invention. Additionally, the server 230 may be coupled to the computer system 260 in a manner allowing the server to delegate certain processing functions to the computer system. In an embodiment, the client device 210 may bypass network 220 and communicate directly with computer system 260.
Still referring to FIG. 2, and in operation according to an embodiment of the invention, a user (not shown) of the client device 210 desiring to electronically and/or automatically schedule a tour of one or more homes for sale, which one or more homes may or may not be hosting an open house, uses a browser application running on the client device to access web content, which may, but need not, be served by the server 230. Specifically, by employing an appropriate uniform resource locator (URL) in a known manner, the user may navigate to a website hosted by the server 230.
FIG. 3 illustrates a process 300 according to an embodiment of the invention. The process 300 is illustrated as a set of operations shown as discrete blocks. One or more steps of the process 300 may be implemented in any suitable hardware, software, including instructions embodied within components, firmware, or combination thereof. The order in which the operations associated with the process 300 are described is not to be necessarily construed as a limitation.
At a block 310, the user is provided access, via an electronic network, to a memory device on which are stored listings of parcels of real property. For example, upon navigating to the website, the user may, in a conventional manner, ensure personal credentials to login to an account maintained by, for example, the administrators of the website. Subsequently, the user may sort through and view MLS listings stored in database 240. In a conventional manner, the user may select one or more of the MLS listings of homes, including listings stored in database 240 of homes that are not offered for sale at the time the user navigates to the website, that the user is interested in purchasing for inclusion in a “wish list” associated with the user's account.
At a block 320, a selection of a set of the stored listings is received from the user. For example, the user may submit to the server 230 a set of one or more listings from the wish list associated with parcels of real property that the user desires to visit in what may be referred to herein as a “tour” of such parcels. An embodiment may provide the user with the ability to indicate a “top-priority” parcel to be included in a tour and on which the development of an itinerary, discussed in greater detail below, may be based. Additionally, for each parcel selected by the user, an embodiment may provide suggestions of other parcels located within a predetermined distance and being similar in price and/or amenities. In an embodiment, if one of the parcels selected for the tour becomes subject to a pending sale, or otherwise becomes unavailable, before the user undertakes the tour, the user's wish list may be consulted and a “backup” parcel may be chosen therefrom and suggested to the user as a substitute parcel for the tour.
At a block 330, at least a portion of an itinerary is generated in response to receiving the selection. The itinerary may include an indication of at least one time at which the user will receive permitted physical access to at least one parcel of real property associated with the selected set of stored listings. For example, in response to receiving from the user the selection of parcels that the user desires to include in the tour, a tour itinerary is generated that includes a tour appointment time of finite duration (e.g., 3 PM to 6 PM), on a date selected by the user, during which the user will be admitted to the selected parcel(s). The starting time and duration of the appointment time, according to alternate embodiments, may or may not be initially suggested by the user. In the latter case, the start time and duration of the appointment time may be suggested to the user based on, for example, the quantity and location of the parcels included in the tour.
The itinerary may also include the identity of an agent who will accompany the user on the tour, and order in which the selected parcel(s) will be visited, and a schedule of time periods within the appointment time during which each parcel will be respectively visited and/or during which access to each parcel will be granted. In various embodiments, one or more of the determination, for purposes of generating the itinerary, of appointment time start and duration, the agent, the order of parcel visitation and the time period allotted for visitation of each parcel may be manually made by a representative of the website administrator using one or more of server 230 and computer system 260 and/or made automatically by one or more of the server and computer system.
Regardless of whether the choice of agent is determined manually or automatically, such determination may be based on an electronic record of agent availability, which may be stored in database 240. That is, each eligible agent may post to database 240 their own respective schedule of availability that may be manually or automatically consulted to determine which agents may be available to accompany the user on the tour during the appointment time chosen or requested by the user. Additionally, using a graphical user interface according to an embodiment, the agent may specify conditions under which the agent will make herself available to accompany a user on a tour. For example, the agent may specify that a certain price threshold for each parcel included in the tour must be met before the agent is willing to conduct the tour. The agent may specify that he is only willing to conduct a tour if the tour is the first one taken by a particular user, or if the tour is a second or subsequent tour taken by a particular user. Consequently, the tour itinerary would be generated, manually or automatically, based on these conditions.
Additionally, regardless of whether the appointment time and/or time periods are determined manually or automatically, such determinations may be based on one or more of the following exemplary factors, each of which may be embodied in a numerical score or other data type:
Market—for example, a particular metropolitan city within which the parcels requested to be included in the tour are located;
Service region—for example, a particular neighborhood or region of the market city within which the parcels requested to be included in the tour are located;
Number of homes included in the tour;
Number of single-family homes included in the tour;
Number of condominiums included in the tour;
Total square footage of all parcels included in the tour and/or square footage of one or more individual parcels included in the tour;
Number of tours the user has previously completed;
Number of homes on the tour that the user has previously toured;
Relative duration of the user's previous tours;
Price of one or more parcels included in the tour;
Characteristics, such as, for example, geographic location and sale close rate, of the agent leading the tour;
A calculation of travel time between or among the parcels included in the tour; and
Whether the tour occurs on a weekday or weekend and/or by day of the week on which the tour occurs.
In an embodiment, and based on a predetermined threshold distance between or among the parcels included in the tour, the itinerary may be generated to include two different appointment times, each perhaps on separate days, as a solution to logistical difficulties associated with traveling such distances.
At a block 340, the itinerary is provided to the user. For example, the server 230 and/or the computer system 260 provides the tour itinerary to the user. The tour itinerary may be provided to the user via one or more of a website, short message service (SMS) message, e-mail or other appropriate notification method requested by the user. If the itinerary requires time to develop, such as may be the case when the availability of one or more parcels requested for the tour must be confirmed, the user may, in real-time or otherwise, receive or be given access to updates on the state of the itinerary. An embodiment may allow listing agents to log in to the website and indicate for storage in database 240 specific time when does during which a particular parcel will be made available for touring. Subsequently, these stored time windows may be consulted in the process of generating the itinerary.
In an embodiment, more than one itinerary may be generated. As such, the itinerary provided to the user may, in effect, be merely a suggested itinerary. For example, if the user is dissatisfied with one or more of the appointment time/duration or agent selection, the user may, using a graphical user interface associated with the website, select from one or more other available appointment times/durations and/or agents.
FIG. 4 illustrates a process 400 according to an embodiment of the invention. The process 400 is illustrated as a set of operations shown as discrete blocks. One or more steps of the process 400 may be implemented in any suitable hardware, software, including instructions embodied within components, firmware, or combination thereof. The order in which the operations associated with the process 400 are described is not to be necessarily construed as a limitation.
At a block 410, a user is provided access, via an electronic network, to a user interface enabling the user to view listings of parcels of real property stored on a memory device and provide a selection of a set of the stored listings. For example, upon navigating to the website, the user may, in a conventional manner, ensure personal credentials to login to an account maintained by, for example, the administrators of the website. Subsequently, the user may sort through and view MLS listings stored in database 240. In a conventional manner, the user may select one or more of the MLS listings of homes, including listings stored in database 240 of homes that are not offered for sale at the time the user navigates to the website, that the user is interested in purchasing for inclusion in a “wish list” or “favorites” set associated with the user's account.
In an embodiment, the user may select the stored listings by selecting a city, a neighborhood within a city, or other subregion of the city from one or more menus presented in the user interface. Consequently, all listed parcels located in the selected city or neighborhood/subregion would, in effect, be included in the selected set of stored listings.
At a block 420, the selected set is received by the server 230, for example.
At a block 430, the user is provided access, via the electronic network, to a user interface enabling the user to (a) view a set of dates and at least one indication of a quantity of open houses hosted on each date of the set of dates at parcels associated with the selected set of listings, (b) provide a selection of a date on which the user desires to attend (i.e., tour) multiple open houses hosted on the selected date, and (c) provide a selection of a time window on the selected date during which the user desires to attend the multiple open houses. For example, as illustrated in FIG. 5, the user may access a webpage 500 that includes a calendar 510 including day indicators 515 that are selectable with a conventional pointer device by the user. In the illustrated embodiment, each day shown in the calendar 510 includes an indicator 520 of the number of open houses occurring on that day and involving parcels included in the selected set of listings, as well as an indicator 530 of a time window within which such open houses occur. The number of day indicators 515 included in the calendar 510 may be adjustable by the user.
In an embodiment, the day indicators 515 may be populated with open house information, as illustrated in FIG. 5, supplied by one or more listing agents. This may be achieved by enabling the listing agents to login to the website and employee a user interface to input an indication of a date and time window in which an open house will be hosted.
As illustrated in FIG. 6, upon selecting an indicator 515 of the day on which the user desires to conduct an open house tour, the user may access a webpage 600 that includes a drop-down menu 610 that allows the user to indicate the desired time window within which to conduct the tour. The time window selected by the user may be composed of contiguous or non-contiguous blocks of time.
In an embodiment, and as illustrated in FIG. 7, the user, by accessing a webpage 700, may indicate an address from which the user desires to commence the tour of open houses. Additionally, the user may be able to indicate their intended mode of transit (e.g., walking, by car, etc.). This selection of a starting address and mode of transit will be used as a basis for the generation of an open house tour itinerary as discussed in greater detail below.
At a block 440 the selected date and time window are received by the server 230, for example.
At a block 450, and in response to receiving the selected date and time window, an itinerary including an indication of a suggested sequence of attendance of open houses of a set of the multiple open houses and suggested time periods within the time window on the selected date during which each open house of the set of the multiple open houses may be attended is generated. For example, one or more of the server 230 in computer system 260 may generate the itinerary based on a calculation of travel time between or among the parcels of the selected set hosting open houses and may include an additional predetermined amount of time as a “buffer.” The algorithm employed to generate the itinerary may optimize based on distance or, alternatively, may optimize based on waypoints. Because of the finite duration of the time window selected by the user, the finite amount of time during which any given open house is hosted, and distances between the parcels at which open houses are being hosted on the selected day, all open houses occurring within the selected time window on the selected day may not be included in the itinerary. In an embodiment, the duration of the suggested time periods may be adjustable by the user.
In an embodiment in which the computer system 260 generates the itinerary, the computer system may perform the following algorithmic steps. First, the computer system 260 determines the day and time window selected by the user. Next, the database 240 is consulted to identify all open houses scheduled to occur during at least a portion of the selected time window. Next, a determination of “outlier” open houses is made. An open house qualifies as an outlier if its ending time is at least 45 minutes (i.e., the default allotment setting for time spent at an open house plus travel time to the open house) later than the latest previous open house ending time and still within the selected time window. As such, it is an open house that is guaranteed to be scheduled because there are no conflicts within its time slot. Next, the outlier open houses are designated as lowest priority for purposes of their inclusion in the itinerary. Next, the open houses occurring during the selected time window are scheduled according to the following factors in descending order qualifying importance: (a) earliest start time of the open house, (b) shortest duration of the open house, and (c) priority (i.e., importance) of the open house as may be indicated by the user. Next, review the open houses that now populate the itinerary and substitute higher-priority open houses for lower-priority open houses. It should be noted that the above-described algorithmic steps would likewise be performed in embodiments in which the server 230 alone or a combination of the server and computer system 260 generates the itinerary.
At a block 460, the itinerary is provided to the user. For example, the server 230 and/or the computer system 260 provides the tour itinerary to the user. The tour itinerary may be provided to the user via one or more of a webpage 800, such as is illustrated in FIG. 8, SMS message, e-mail or other appropriate notification method requested by the user. As illustrated in the example of the webpage 800 of FIG. 8, the itinerary may include a sequential list 810 of the open house times and locations, as well as a map 820 illustrating the proposed route to be taken during the open house tour.
As illustrated in FIG. 9, after receiving the itinerary, the user may access a webpage 900 that can enable the user to prioritize or reprioritize the open houses that are included in the itinerary. Such prioritization may be achieved, for example, by “dragging and dropping” icons representing one or more open houses. After prioritizing one or more open houses, the user may request that the itinerary be re-generated. In an embodiment, before any itinerary is generated, the user may designate a set of the open houses as “favorites,” in which case such favorite set will automatically be highly prioritized. Alternatively, the user may, by using the website, indicate a preference that the algorithm used to generate the itinerary place a greater emphasis on maximizing the number of open houses attended rather than attempting to ensure that specific ones of the open houses are attended. Additionally, the algorithm may more highly prioritize open houses that are listed by or otherwise associated with the administrator of the website.
An embodiment may include a user interface (not shown) accessible to the user after the open house tour has been conducted and enabling the user to indicate which homes they actually saw on the tour, and enter notes on them. Tracking the homes seen by the user enables the administrator of the website to ignore those homes when the user plans the next tour (although the user may override this setting).
While the preferred embodiment of the invention has been illustrated and described, as noted above, many changes can be made without departing from the spirit and scope of the invention. Accordingly, the invention is not limited except as by the appended claims.

Claims

What is claimed is:

1. At least one computer-readable medium on which are stored instructions that, when executed by at least one processing device, enables the at least one processing device to perform a method comprising the steps of:

providing to a user access, via an electronic network, to a memory device on which are stored listings of parcels of real property;

receiving, via the electronic network, from the user a selection of a set of the stored listings;

in response to receiving the selection, generating at least a portion of a first itinerary including an indication of at least one time at which the user will receive permitted physical access to at least one parcel of real property associated with the selected set of stored listings; and

providing the first itinerary to the user.

2. The medium of claim 1, wherein the parcels of real property are offered for sale at the time of user access to the memory device.

3. The medium of claim 1, wherein the first itinerary is provided to the user via a short message service message.

4. The medium of claim 1, wherein the first itinerary includes a finite duration during which the user will receive the permitted physical access.

5. The medium of claim 1, wherein at least a portion of the first itinerary is manually generated.

6. The medium of claim 4, wherein the duration is determined based on the square footage of at least one parcel associated with the selected set.

7. The medium of claim 4, wherein the duration is determined based on the geographic region within which the at least one parcel associated with the selected set is located.

8. The medium of claim 4, wherein the duration is determined based on data characterizing execution by the user of at least one previously generated itinerary different from the first itinerary.

9. The medium of claim 1, wherein the first itinerary includes identification of at least one agent to accompany the user during the physical access to the at least one parcel.

10. The medium of claim 9, wherein generating the first itinerary comprises accessing an electronic record of the availability of the at least one agent to accompany the user at the at least one time indicated by the first itinerary.

11. The medium of claim 1, wherein generating the first itinerary comprises calculating a travel time between first and second parcels associated with the selected set.

12. At least one computer-readable medium on which are stored instructions that, when executed by at least one processing device, enables the at least one processing device to perform a method comprising the steps of:

providing to a user access, via an electronic network, to a user interface enabling the user to view listings of parcels of real property stored on a memory device and provide a selection of a set of the stored listings;

receiving, via the electronic network, the selected set;

providing to the user access, via the electronic network, to a user interface enabling the user to (a) view a set of dates and at least one indication of a quantity of open houses hosted on each date of the set of dates at parcels associated with the selected set of listings, (b) provide a selection of a date on which the user desires to attend multiple open houses hosted on the selected date, and (c) provide a selection of a time window on the selected date during which the user desires to attend the multiple open houses;

receiving, via the electronic network, the selected date and time window;

in response to receiving the selected date and time window, generating an itinerary including an indication of a suggested sequence of attendance of open houses of a set of the multiple open houses and suggested time periods within the time window on the selected date during which each open house of the set of the multiple open houses may be attended; and

providing the itinerary to the user.

13. The medium of claim 12, wherein the user selection comprises an indication of at least one of a city and a neighborhood.

14. The medium of claim 12, further comprising providing a user interface that enables the user to provide an indication of an address from which the user desires to begin attendance of open houses of the set, wherein the suggested sequence and suggested time periods are based on the indicated address.

15. The medium of claim 12, wherein the user interface comprises a website.

16. The medium of claim 12, wherein the itinerary is generated based on a calculation of travel time between a parcel hosting a first open house of the set and a parcel hosting a second open house of the set.

17. The medium of claim 12, wherein the itinerary is generated based on a user designation of an open house of the multiple open houses as being high-priority.

18. The medium of claim 12, wherein the method further comprises the step of providing to at least one listing agent access, via the electronic network, to a user interface enabling the listing agent to input an indication of a date and time window in which an open house will be hosted at a parcel associated with the selected set of listings.

19. The medium of claim 12, wherein the method further comprises the step of providing to the user access to a user interface enabling the user to prioritize attendance at a first open house of the multiple open houses over a second open house of the multiple open houses.

20. The medium of claim 12, wherein the duration of the suggested time periods is adjustable by the user.