The present disclosure relates to computer-implemented methods, software, and systems for adaptive role-based leasing transaction management, including management of tenant inquiries.
Commercial real estate deals can occur in response to a party needing a space to rent. The party can contact a tenant representative for assistance in finding a suitable space to rent. The tenant representative can contact one or more leasing agents. A leasing agent can represent a property owner who is advertising a commercial space for rent.
The present disclosure involves systems, software, and computer implemented methods for adaptive role-based leasing transaction management, including management of tenant inquiries. One example method includes, for example: receiving a request from a first user to access a lease transaction management system; determining a first organization and a first role associated with a current session of the first user; customizing a user interface of the lease transaction management system based on the first organization and the first role associated with the current session, including displaying information for tenant inquiries that the first user is authorized to view based on the first role and the first organization; receiving, through the user interface, first tenant inquiry information for a first tenant inquiry for a first prospective tenant; automatically identifying at least one matching property that matches the tenant inquiry information; and presenting, in the user interface, information about the at least one matching property to the first user.
While generally described as computer-implemented software embodied on tangible media that processes and transforms the respective data, some or all of the aspects may be computer-implemented methods or further included in respective systems or other devices for performing this described functionality. The details of these and other aspects and embodiments of the present disclosure are set forth in the accompanying drawings and the description below. Other features, objects, and advantages of the disclosure will be apparent from the description and drawings, and from the claims.
A cloud application platform and system can provide services and applications that serve the Commercial Real Estate (CRE) industry by providing a centralized location to include and engage all parties in a lease transaction, from tenant inquiries to property tours to move-in to re-upping a future lease. Existing CRE lease processes can be inefficient, time consuming, and lack transparency. The cloud application platform described herein enables users to manage and more effectively advance a deal, which can save time for brokers, lessors, lessees, and other deal participants. The system can provide landlords with key transaction metrics, which can increase user satisfaction. The platform can include a cloud application that utilizes, for example, a frontend, a backend, a data storage layer, and a cloud platform host.
The user can access the system using one of a set of defined roles, which can include, for example, administrator, company owner, broker, leasing team member, or tenant representative, among others. An administrator can register and invite company owners. Once a company account is defined in the system, a company owner can add leasing team members, who can add listings and perform other actions.
For instance, an onboarding process for a new company can be initiated by an administrator. The administrator can assign markets for a company. A company owner can be sent an invitation to join the system. Leasing team members can also be invited join to the system and can add properties and/or listings to a portfolio. Markets can be defined and used when creating a deal for a specific listing. A tenant representative can be invited to join the system during a deal creation process. As another example, a tenant representative can be invited to join the system during a tenant inquiry process that includes providing and discussing tenant needs and identifying potential matching properties. Other role-based actions can be enabled, as described below.
The system can be configured to capture information from tenant inquiries using a tenant inquiry component of the application. A prospective tenant or a tenant representative may contact a broker and express certain interests or needs for a type of property. The broker can use a set of user interfaces provided by the application to capture the needs expressed by the tenant representative and begin a process of identifying properties that may match or satisfy the tenant inquiry/tenant needs. The broker can manually select matching properties and/or the system can automatically identify matching properties. Properties can be matched based on one or more of an availability date, size, cost, property use type, location, and other suitable factors. The inquiry component can manage activities that occur related to prospective properties that have not yet began more formal deal proceedings. For example, in response to a tenant inquiry, multiple potential properties can be identified, and each property can have activities, such as sending of marketing information, tour scheduling, proposals, etc., that occur and that are managed and tracked by the system. A tenant representative can view identified properties and select candidate properties that may be of interest to the tenant.
Inquiries can have a defined workflow, with different activities that can occur within the workflow. An inquiry workflow can interface and in some cases overlap with workflows and stages in more formal deal processes. For example, activities can be occurring for multiple properties in response to a single tenant inquiry—for example, a prospective tenant may have been sent marketing materials for several properties, toured multiple properties, have other tours scheduled, and/or been presented with initial proposals for different potential properties. At a certain point, the prospective tenant may indicate a more formal interest in a particular property, and, at that point, more formal proceedings can occur and a deal workflow can be initiated that includes other, such as more formal, activities for completing a formal deal with the tenant, including deal negotiation, lease activities, closing, etc. While the tenant is considering different properties, the inquiry workflow can be used to manage preliminary activities during the consideration period. The inquiry workflow can be used when multiple properties are being considered by a tenant, so that multiple formal deal processes are not unnecessarily started while a tenant is still deciding on properties.
A deal completion, for more formal proceedings, can go through various stages, or phases. Deal stages can include, for example, tour, proposal, lease, closing, and revenue stages. In each stage, users who have access to the deal can complete tasks. Some or all tasks can be required for a phase. The system can ensure that all required tasks for a phase are completed in order to proceed to a following phase. In some instances, the system can automate additional systems into the completion of a particular task, such as communication systems, legal document management systems, and others, such that accessing a task entry in the described system can cause other systems and applications to be executed, either within or external to the cloud system. Information about the completion of those tasks can then be provided back to the centralized system, and the particular task can be updated, and in some cases, considered completed. A visual indication of which task is currently being performed can be presented to all users, and users associated with the next task can be automatically notified via any suitable communication channel when the prior task has been completed.
Users of a given role can take part in various use cases that have been enabled for the role. For example, an administrator can create companies, invite owners, add markets, add portfolios for companies, add or freeze users, and view reports. As another example, a company owner can add portfolios, add properties, add listings, create deals, add/manage team members, send electronic messages through the system (e.g., send messages to participants of a deal), add notes, and track deal status. Leasing team members can add portfolios, add properties, add listings, respond to and update tenant inquiries, create deals, send electronic messages through the system (e.g., send messages to participants of a deal), add notes, track deal status, invite tenant representatives to join the system, and update/complete deal activities. Tenant representatives can create or provide information for tenant inquiries, view deals, invite other tenant representatives to join the system, track deal status, update/complete deal activities, upload documents, send messages to deal participants, and add clients. Further, each user with an appropriate role for a current deal or inquiry can be associated with particular tasks for that deal or inquiry, such that the proper team members are associated with and prompted for input and/or actions to complete the current task. Any persons associated with the deal or inquiry can have easy and immediate access to information as to the overall status of the deal or inquiry, where the current task list is, and what items have been or are left to be completed.
A user can use a client application 110 to access a server application 112 provided by the application server 102. The user can be, for example, an administrator, company owner, leasing team member, or tenant representative. The client application 110 can access the server application 112 using one or more APIs (Application Programming Interfaces). For instance, a public API 114 can enable a user to login, reset a login password, register for the system, etc. A protected API 116 can be used for inviting users, adding properties, interacting with deals, and other transactional features. The public API 114 can be accessible without authentication. The protected API 116 can be accessed by an authenticated user. A login process can create an authentication token which can be used in subsequent requests to validate authorized usage.
A portal UI (User Interface) generator 118 can generate and provide a user interface to the client application 110. The user interface, and contents displayed within the user interface, can be based on a role of a logged-in user and on states of various transactions to which the user may be authorized as a participant.
The application server 102 can be configured to serve API requests from the client application 110. The requests can be for either static resources (e.g., HTML (HyperText Markup Language), CSS (Cascading Style Sheets), scripts) or dynamic content (e.g., property information, deal information, inquiry information, etc.). For both static and dynamic content, the application server 102 can be configured to not store such data, but rather store data in or retrieve data from a database (or other data storage layer), such as from memory 119 or disk storage. The application server 102 can check HTTP requests for security issues such as cross-site scripting (XSS) and cross-site request forgery (CSRF) by checking a request origin and required tokens in the request.
The application server 102 can process user requests, validate requests, and store data in the database for example. Stored data can include, for example, team documents 120 that are private to a particular team (e.g., a leasing team), deal documents 122 that are accessible by all participants related to a particular deal, user role information 124 used to determine what users have what roles for which transactions, team assignment information 126 (e.g., that specifies which users are on a particular leasing team), images 128 (of properties, etc.), deal transaction data 130, and inquiry data 132.
Deal transaction data 130 can be managed by a deal management engine 134, which can manage a deal through various deal stages, such as tour, proposal, lease, closing, and revenue stages. The deal management engine 134 can enable authorized users to perform certain actions on a deal, at various stages, based on a user's role and authorizations. Similarly, inquiry data 132 can be managed by an inquiry management engine 136, which can manage tenant inquiries. The inquiry management engine 136 can enable authorized users to perform certain actions on an inquiry, based on a user's role and authorizations. The inquiry management engine 136 can provide tenant inquiry user interfaces for capturing tenant inquiry information. The inquiry management engine can automatically identify properties that match the tenant needs expressed in a tenant inquiry. User interfaces provided by the inquiry management engine 136 can enable users, based on roles and permissions, to interface with and update the tenant inquiry, including progressing an inquiry through various inquiry activities and workflows (e.g., tour scheduling, marketing material sending, initial proposal activities, and selecting a prospective matching property as a property for more formal deal proceedings. Brokers and tenant representatives can each view tenant inquiry information, and can perform different actions based on assigned roles and permissions.
The deal management engine 134 can manage deal and other lease transactions. For instance, the deal management engine 135 can manage and track task/action assignment, reassignment, and completion. Tasks or actions for a deal can be done sequentially and/or in parallel. Each user is allowed to view or act on tasks based on privileges and assignments, which can be based on a user's role. A user can have a different role in different contexts. For example, a user can be a real estate agent who acts as a tenant representative for a first property and acts as a leasing agent for a second property.
Stored data can also include logs 138. The system can maintain detailed logs 138 regarding all activities performed on a deal on inquiry, for instance. Actions performed in the system can be logged in the logs 138 for auditing purposes, for example.
The application server 102 can be part of or associated with a cloud platform, for example. Documents, images, and other data can be stored in secure cloud storage locations (or in other location(s)) in an encrypted format. Transactional data can be stored in a database hosted by the cloud platform. Access to application data can be controlled using the cloud/application platforms.
To secure stored data (e.g., “data at rest”), data can be stored in a database layer of the cloud platform. Database servers can be made accessible only to application servers (e.g., the application server 102) and thereby protected from unauthorized usage. Mirror copies of database(s) and/or file storage(s) can be used for data redundancy and backups, and can be stored in separate geographic location(s) than production version(s).
Documents and images can be stored in the database and/or stored in a secured file or object storage service, with a file or object service being an example of a third party service provider to which the application server 102 can interface. Other third party service providers include third party property management platforms or document signing services.
As used in the present disclosure, the term “computer” is intended to encompass any suitable processing device. For example, although
Interfaces 140, 141, and 142 are used by the client device 104, the application server 102, and the third party service provider 105, respectively, for communicating with other systems in a distributed environment—including within the system 100—connected to the network 106. Generally, the interfaces 140, 141, and 142 each comprise logic encoded in software and/or hardware in a suitable combination and operable to communicate with the network 106. More specifically, the interfaces 140, 141, and 142 may each comprise software supporting one or more communication protocols associated with communications such that the network 106 or interface's hardware is operable to communicate physical signals within and outside of the illustrated system 100.
The application server 102 includes one or more processors 144. Each processor 144 may be a central processing unit (CPU), a blade, an application specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or another suitable component. Generally, each processor 144 executes instructions and manipulates data to perform the operations of the application server 102. Specifically, each processor 144 executes the functionality required to receive and respond to requests from the client device 104, for example.
Regardless of the particular implementation, “software” may include computer-readable instructions, firmware, wired and/or programmed hardware, or any combination thereof on a tangible medium (transitory or non-transitory, as appropriate) operable when executed to perform at least the processes and operations described herein. Indeed, each software component may be fully or partially written or described in any appropriate computer language including C, C++, Java™, JavaScript®, Visual Basic, assembler, Perl®, any suitable version of 4GL, as well as others. While portions of the software illustrated in
The application server 102 includes the memory 119. In some implementations, the application server 102 includes multiple memories. The memory 119 may include any type of memory or database module and may take the form of volatile and/or non-volatile memory including, without limitation, magnetic media, optical media, random access memory (RAM), read-only memory (ROM), removable media, or any other suitable local or remote memory component. The memory 119 may store various objects or data, including caches, classes, frameworks, applications, backup data, business objects, jobs, web pages, web page templates, database tables, database queries, repositories storing business and/or dynamic information, and any other appropriate information including any parameters, variables, algorithms, instructions, rules, constraints, or references thereto associated with the purposes of the application server 102.
The client device 104 may generally be any computing device operable to connect to or communicate with the application server 102 via the network 106 using a wireline or wireless connection. In general, the client device 104 comprises an electronic computer device operable to receive, transmit, process, and store any appropriate data associated with the system 100 of
The client device 104 further includes one or more processors 146. Each processor 146 included in the client device 104 may be a central processing unit (CPU), an application specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or another suitable component. Generally, each processor 146 included in the client device 104 executes instructions and manipulates data to perform the operations of the client device 104. Specifically, each processor 146 included in the client device 104 executes the functionality required to send requests to the application server 102 and to receive and process responses from the application server 102.
The client device 104 is generally intended to encompass any client computing device such as a laptop/notebook computer, wireless data port, smart phone, personal data assistant (PDA), tablet computing device, one or more processors within these devices, or any other suitable processing device. For example, the client device 104 may comprise a computer that includes an input device, such as a keypad, touch screen, or other device that can accept user information, and an output device that conveys information associated with the operation of the application server 102, or the client device 104 itself, including digital data, visual information, or a GUI 148.
The GUI 148 of the client device 104 interfaces with at least a portion of the system 100 for any suitable purpose, including generating a visual representation of the sourcing application 110. In particular, the GUI 148 may be used to view and navigate various Web pages, or other user interfaces. Generally, the GUI 148 provides the user with an efficient and user-friendly presentation of business data provided by or communicated within the system. The GUI 148 may comprise a plurality of customizable frames or views having interactive fields, pull-down lists, and buttons operated by the user. The GUI 148 contemplates any suitable graphical user interface, such as a combination of a generic web browser, intelligent engine, and command line interface (CLI) that processes information and efficiently presents the results to the user visually.
Memory 150 included in the client device 104 may include any memory or database module and may take the form of volatile or non-volatile memory including, without limitation, magnetic media, optical media, random access memory (RAM), read-only memory (ROM), removable media, or any other suitable local or remote memory component. The memory 150 may store various objects or data, including user selections, caches, classes, frameworks, applications, backup data, business objects, jobs, web pages, web page templates, database tables, repositories storing business and/or dynamic information, and any other appropriate information including any parameters, variables, algorithms, instructions, rules, constraints, or references thereto associated with the purposes of the client device 104.
There may be any number of client devices 104 associated with, or external to, the system 100. For example, while the illustrated system 100 includes one client device 104, alternative implementations of the system 100 may include multiple client devices 104 communicably coupled to the application server 102 and/or the network 106, or any other number suitable to the purposes of the system 100. Additionally, there may also be one or more additional client devices 104 external to the illustrated portion of system 100 that are capable of interacting with the system 100 via the network 106. Further, the term “client”, “client device” and “user” may be used interchangeably as appropriate without departing from the scope of this disclosure. Moreover, while the client device 104 is described in terms of being used by a single user, this disclosure contemplates that many users may use one computer, or that one user may use multiple computers.
The middleware layer 202 can intercept and validate incoming traffic sent to the server 200, such as to validate whether a request is made by a valid user with appropriate access. An authentication component 208 can determine whether a requestor has a valid authentication token (e.g., that is provided to a user when the user successfully logs in to the application). In some implementations, the authentication component can perform JWT (JSON Web Token) authentication.
In general, various security features can be implemented in the application. For instance, authentication features can be enabled, whereby to use the system, a user needs to provide a username and a password. In some examples, OAuth is used for authentication. Authorization can be implemented, by an authorization component 210, so that users are only given access to interfaces and functionality for which they are authorized. Confidentiality of data can be enforced, whereby sensitive data (e.g., user passwords) is encrypted. Access to documents can be controlled using a secure application programming interface (API). Communication between clients and system server(s) can be encrypted (e.g., using a 2048 bit encryption key at a transport layer).
In further detail, when implementing access control and security, the extent to which data is accessible can be controlled by roles that have been assigned users. Roles can include, for example, system administrator, company owner, leasing team (for portfolios and/or properties), and tenant representative. Some roles enable users having one of those roles to invite other users to the system.
Other security measures can be taken to maintain security for data and the system infrastructure. For example, to protect data in transit, the application can be accessible only via a secured protocol (e.g., HTTPS (HyperText Transfer Protocol Secured protocol, which is based on SSL (Secured Sockets Layer) encryption) https protocol which is based on SSL encryption. In some implementations, a load balancer is used to accept and decrypt HTTPS request, and forward the requests to internal servers. The load balancer can use certificates issued by a certificate authority (CA).
The REST layer 204 can provide REST APIs (Application Programming Interfaces) that are served by the server 200. The REST layer can be modelled according to the platform's main entities (e.g., users 212, companies 214, portfolios 216 (and properties), listings 218, documents 220, deals, inquiries, etc.).
The ORM layer 206 can transform objects into relational database entities (e.g., which can be referred to as “sequelizing” object-based data). Using the ORM layer 206 can result in more domain visibility and development of less boilerplate code.
The server 200 can include or interface with other components, systems, or services. For example, the server 200 can include or use other utilities, including mail utilities, XML (eXtensible Markup Language) processing, image utilities, document signing and services, and messaging services, to name a few examples.
The company owner role 304 can enable team invitation and dashboard viewing activities 316. The leasing team role 306 can enable property adding, inquiry management, and deal management activities 318. The tenant representative role 308 can enable client, inquiry, and deal management activities 320.
In addition to interfacing with the cloud platform 314, the system portal 312 can interface with other services or providers. For instance, the system portal 312 can interface with a document signing service 322. As another example, the system portal 312 can interface with a third party property management platform 324. A data store 326 can store data for the system.
A property listing phase 408 can include an add portfolio activity 410 (which can be performed by an owner or a leasing team member). An add property activity 412 can be performed to add a property to the portfolio. An add listing activity 414 can be performed to create a listing for a property.
A deal creation and tracking phase 416 can include a deal creation activity 418. Once a deal is created, the deal can go through various stages or phases, including a tour stage 420, a proposal stage 422, a lease stage 424, a closing stage 426, and a revenue stage 428. Throughout the deal stages, various deal activities 430 can be performed. For instance, tasks 432 can be completed by various users, documents 434 can be uploaded and viewed, and other activities 436 can be performed, such as note creation, message sending, etc.
Some deals can result from a tenant inquiry. For example, after a property has been listed, the property can be determined to be a match for an inquiry in an inquiry creation stage 438. A tenant inquiry can be created that includes capturing tenant needs for a prospective property. Available properties that match the tenant inquiry information can be identified presented. Various activities can occur related to prospective properties that match the tenant inquiry. For example, tours can occur and proposals can be presented and discussed (the proposals can be, in some cases, less formal than proposals performed in more formal deal stages). A tenant may settle on one of the prospective/proposed properties, and a workflow can shift from tenant inquiry based to more formal deal proceedings, for the selected property.
At 502, a landlord group company is added to a list of companies defined in the system.
At 504, owner permissions are granted to specific individuals associated with the company.
At 506, portfolio data is ingested.
At 508, a determination is made as to whether data was successfully uploaded.
At 510, in response to determining that data was not successfully uploaded, portfolio and property data is manually entered into the system.
At 512, permissions are granted to new users who have been invited to the platform.
At 514, a request is received from a leasing agent user or an asset manager user to instigate a deal.
At 516, a determination is made as to whether the user has access to a property corresponding to the deal.
At 518, in response to determining that the user does not have access to the property, the user is prohibited from creating the deal.
At 520, in response to determining that the user has access to the property, the deal is created.
At 602, login information is received from a user who has an assigned account and an assigned role.
At 604, a determination is made as to whether the user is successfully authenticated based on the login information.
At 606, in response to an unsuccessful login, the use is prompted to re-login (e.g., attempt another login).
At 608, in response to a successful login, a role associated with the user and an account last accessed by the user are identified. Displaying information for a last accessed account or last accessed deal can be optional.
At 610, summary information is displayed based on the user's role and account.
At 612, deals to filter are determined based on a user request. Filtering can be optional.
At 702, selection of a specific deal is received from an authorized user who has a certain role. The user may be presented with a list of deals for which the user is authorized. The list of deals can be generated based on login information and authorization information obtained from a database, for example. The list of deals can include deals that are assigned to the user, or that are associated with the user based on the user's role at a particular company or organization, or for particular properties. The list of deals can be presented to the user and the user can select the specific deal from the list of presented deals.
At 704, a deal detail page is displayed, based on the user role and permissions.
At 706, listing information, completed tasks, and recent activity are displayed, in response to user inputs.
At 708, a determination is made as to whether the user has an assigned task to complete. For example, a query of assigned tasks can be performed to determine whether any completable tasks are assigned to a user. Completable tasks can be tasks that can be completed at the current time. Some tasks are dependent on other tasks, for example, and are marked in a database as completable once dependent task(s) have been completed. Some tasks can be performed in parallel with other tasks. Tasks can be assigned to a user by another user, for example, or automatically based on a set of rules.
In response to determining that the user does not have an assigned task to complete, at 706, listing information, completed tasks, recent activity, or other information remains displayed.
At 710, in response to determining that the user has an assigned task to complete, the user is prompted to complete the assigned task. The user can be prompted in a user interface, for example. As another example, the user may receive an electronic notification (using any suitable communication channel) in another application (e.g., an email application) or a pop-up message on a mobile device. If the notification is presented in another application or on a mobile device, the notification can include a link to access a user interface provided by the centralized system, for access to complete the assigned task.
At 712, a determination is made as to whether the user needs (or has requested) assistance with completing the assigned task.
At 714, in response to determining that the user needs (or has requested) assistance with the assigned task, assistance is enabled (e.g., using one or more of messaging or contact (e.g., other user) invitations.
At 716, after determining that the user does not need assistance, a task completion input is received from the user. The user can provide a task completion input using the user interface of the system, by performing one or more task actions in the user interface or by selecting a user interface control (e.g., a check box) that indicates task completion.
As another example, integration with other systems and operations can occur, to enable task completion, either in whole or in part, by or within outside or external applications. For instance, information may be provided to an external application about a task to be completed. Task information can be provided so that, for example, forms or other inputs of the external application can be populated using task information. Action(s) performed within or by an external application may be simple or detailed, and can be completed in the external application, either automatically or at least in part based on user input from the user. Once completed, a notification or additional action may be performed by the external application, such that the centralized system receives notification or information about the completed task (e.g., a confirmation of completion, or more detailed information, such as a generated or completed form for upload, etc.).
At 718, a determination is made as to whether the user has at least one additional assigned task associated with the selected deal.
In response to determining that the user has at least one additional assigned task associated with the selected deal, the user is prompted, at 712, to complete a next assigned task.
At 802, a deal is created and associated with a core landlord (e.g., owner) and tenant contacts (e.g., tenant representatives).
At 804, the user who is assigned a next workflow task is prompted to complete the task. As mentioned above, the user can be prompted in a user interface of the system or the user may receive an electronic notification in another application (e.g., an email application), or a pop-up message on a mobile device, etc. If the notification is presented in another application or on a mobile device, the notification can include a link to access a user interface provided by the centralized system, for access to complete the assigned task.
At 806, a determination is made as to whether the task has been completed. Task completion can occur as described above for
At 808, in response to determining that the task has not been completed, the task is maintained in an incomplete (e.g., unchecked) state.
At 810, in response to determining that the task has been completed, a determination is made as to whether all tasks in the current stage have been completed.
At 812, in response to determining that not all tasks in the current stage have been completed, the current stage is maintained in an uncompleted state.
At 814, in response to determining that all tasks in the current stage have been completed, the current stage is updated as completed, and a visual indicator associated with a completed status is marked or otherwise indicated.
At 816, a determination is made as to whether all tasks (e.g., all stages) in the deal have been completed.
At 818, in response to determining that not all tasks/stages in the deal have been completed, the deal is maintained in an uncompleted state.
At 820, in response to determining that all tasks/stages in the deal have been completed, a deal status is set to complete.
At 902, a deal is created in the system.
At 904, a determination is made as to whether property or listing files are available to add to the deal.
At 906, in response to determining that no property or listing files are available to add to the deal, the deal is created without property and listing files being included for the deal in the file repository.
At 908, in response to determining that at least one property or listing file is available to add to the deal, the deal is created as being associated with available property and/or listing file(s) that are included in the file repository.
At 910, a user is prompted to complete a next task in a workflow.
At 912, a determination is made as to whether the task is an upload-file task.
At 914, after determining that the task is not an upload-file task, a task-completion selection is received from the user for the task. As mentioned above, the user can provide user input(s) indicating that the task has been completed, the user can perform the task directly in the user interface, or the system can receive a notification or information from another system or application that indicates that the task has been completed
At 916, the task is marked as completed.
At 918, in response to determining that the task is an upload-file task, task completion is disabled until a file is uploaded for the task.
At 920, a determination is made as to whether a file has been uploaded for the task.
At 922, in response to determining that a file has been uploaded for the task, the task is marked as completed.
At 1002, a request is received from a first user to access a lease transaction management system.
At 1004, a first organization and a first role associated with a current session of the first user are determined. The first organization can be a leasing agency, a property ownership group, or a tenant agency, to name a few examples. The first role can be a property owner, a leasing team member, or a tenant representative. The first user can have different roles for different organizations or properties. When the first user is associated with more than one organization, determining the first organization associated with the current session can include receiving selection of the first organization from the first user. As another example, the first organization can be determined based on a website address or a login identifier. The first role can be determined based on the first organization and user identifying information.
At 1006, a user interface of the lease transaction management system is customized based on the first organization and the first role associated with the current session. Customizing the user interface includes displaying information for lease transactions that the first user is authorized to view based on the first role and the first organization.
At 1008, information is received regarding performance of a first lease transaction action for a first lease transaction. For instance, a user input provided to the user interface can be received that indicates completion of the first lease transaction action. The first user can be currently assigned to the first lease transaction action and the user input can be received from the first user. As another example, information about performance of the first lease transaction action can be automatically received from an application. The application can be an email application, a calendar application, or another application that is external to the lease management system, in which the first lease transaction action was performed.
When the information regarding performance of the first lease transaction action indicates completion of the first lease transaction action, a next lease transaction action can be determined. At least one assigned user who is assigned to the next lease transaction action can be determined and a notification can be provided to the at least one assigned user regarding the next lease transaction action, such as in the user interface or using an electronic messaging system.
The first lease transaction action can be a last action of a first stage and determining the next lease transaction action can include: updating a stage status of the first stage to be completed, determining a next stage, and determining a first action of the next stage as the next lease transaction action. Stages can include tour, proposal, lease, closing, and revenue. When the first lease transaction action is a last action of a last stage, a status of the first lease transaction can be updated to be completed when information regarding completion of the first lease transaction action is received.
The first lease transaction action can be an uploading of a document to the lease transaction management system. The document can be a shared document, such as a lease, that is accessible by users who are associated with the first lease transaction. As another example, the document can be a team document, such as a proposal draft, that is accessible by members of a team that includes the first user. The document can be inaccessible by users of the lease transaction management system that are not included in the team. The team can be a leasing team, for example.
At 1010, a status of the first lease transaction action is updated in response to receiving the information regarding the performance of the first lease transaction action. For example, the updated status can be stored in the lease transaction management system. The updated status can be displayed in the user interface, to the first user and other users.
A deal progress pane 1218 includes deal status/progress information that can be filtered, for example, using date filter controls 1220. For instance, an active deal count 1222 and an inactive deal count 1224 respectively indicate that twenty four deals are now in an active state and three deals are in an inactive state.
A stage information area 1226 provides information regarding active deals by stage. For instance, an in-tour count 1228, an in-proposal count 1230, an in-lease count 1232, an in-closing count 1234, an in-revenue count 1236, and a completion-pending count 1238 collectively indicate that eleven deals are in the tour stage, twelve deals are in the proposal stage, and one deal is in the revenue stage.
A graphical indicator 1240 visually indicates stage counts and their relative proportion to other stage counts. For instance, an in-revenue portion 1242, an in-tour portion 1244, and an in-proposal portion 1246 correspond to the in-revenue count 1236, the in-tour count 1228, and the in-proposal count 1230, respectively. A popup count 1248 can appear when the user moves over the in-proposal portion 1246, for example.
A metrics pane 1250 shows task metrics for active deals. For instance, a first count 1252 indicates a count of total inquiries, a second count 1254 indicates a count of inquiries that haven't yet resulted in a tour, a third count 1256 indicates a count of tours scheduled but not yet completed, a fourth count 1258 indicates a count of tours completed that have not yet resulted in an upload of a proposal document, a fifth count 1260 indicates a count of finalized proposals where a lease hasn't yet been uploaded, a sixth count 1262 indicates a count of uploaded but unsigned leases, and a seventh count 1264 indicates a count of leases signed where deals have not yet been completed. Each count can have a graphical and numerical display. For instance, a bar chart 1266 graphically indicates a value for the first count 1252.
For instance, a first row in the deals area 1403 is for a “1515 Olive, unit 0640” property 1416. The market column 1412 lists an applicable market for each deal's property. For instance, the “1515 Olive, unit 0640” property is in a “Downtown Dallas” market 1418. The status column 1414 depicts stage completion and stage progress for each deal. For instance, for the “1515 Olive, unit 0640” property, a tour-completed indicator 1420 indicates that the tour stage has completed and a proposal-progress indicator 1422 indicates that the proposal stage has just started. As another example, in a second row, a tour-completed indicator 1424 and a proposal-progress indicator 1426 respectively indicate that the tour stage has been completed and the proposal stage is 19% complete for a “1515 Olive, unit 0680” property.
A tour stage status item 1717 indicates (e.g., based on a displayed check mark) that the tour stage has been completed for the deal, as does a tour-completed indicator 1718. A date range 1720 indicates date(s) during which tour-stage activities were performed. A proposal stage status item 1722 indicates a completion percentage (e.g., 179%) for the deal for the proposal stage. A date range 1724 indicates a start date and an ongoing status from the proposal stage.
A task area 1726 display task-completion statuses for the proposal stage. For instance, checked-off items 1728, 1730, and 1732 indicate that an upload RFP (Request for Proposal), a draft-and-upload-proposal, and a send file task have been completed. An unchecked item 1734 indicates that a negotiate proposal task has not yet been completed. The unchecked item 1734 is a topmost unchecked item and is therefore a next task. Other unchecked items indicate that other tasks remain for completion. Tasks in the task area 1726 have a task description (e.g., an “Upload RFP” description 1736, or a “Negotiate proposal . . . ” description 1738). Completed tasks are shown with a completion date (e.g., a Aug. 2, 2019 completion date 1740).
An assigned column 1742 displays user identifiers of members who have been assigned to a task. For instance, an indicator 1744 indicates that the user “AR” had been assigned to the completed task associated with the checked-off item 1728 and indicators 1746 and 1748 indicate the user “AR” and the user “SS” are assigned to the task associated with the unchecked item 1734. A new task can be added for the proposal stage by selecting an add button 1750.
The displayed file area 2102 is associated with an upload files tab 2108 that shows files that have been uploaded for a particular task. The file upload user interface 2100 can also display personal files for the current user in response to selection of a my-files tab 2110. Files associated with a property or a listing can be displayed in response to selection of a property-files tab 2112 or a listing files tab 2114, respectively.
In some implementations, the file upload user interface 2100 can display custom information or user interface elements that are particular to a certain type of file. For instance, the file upload user interface 2100 may have been displayed in response to selection of an “upload proposal” task. A checkbox 2116 can be displayed, to enable selection or deselection of an option relating to proposal negotiation (e.g., if the checkbox 2116 is selected, a new counter proposal may need to be uploaded each time a negotiating party responds to a current proposal). After the user has selected a file, the selected file can be uploaded by selecting an upload button 2107.
The tenant inquiry area 4604 currently displays a first inquiry area 4616 that displays information for a first inquiry and a second inquiry area 4618 that displays information for a second inquiry. The first inquiry is for a first tenant ABC Inc. 4620 that has a tenant representative 4622 of Aaron Applebee (e.g., of firm CBRE). The first tenant 4620 has stated a square footage need 4624 of 12,345 square feet. A desired lease commencement date 4626 is Nov. 3, 2020. A desired rent amount 4628 is $8-$12 per square foot. A desired space type 4630 is “office”. An ability to change tenant inquiry information, including tenant needs and desires, can be enabled by selection of an edit item 4631.
As indicated by a note 4632, the first inquiry was made seven days ago (e.g., on Oct. 21, 2020). A desired city 4634 is Dallas. A notes section 4636 indicates that the tenant prefers a property that is next to a hotel, is either in downtown or uptown, and that a desired tour date is November 4.
A properties area 4640 displays information on properties that have been identified as potential matches for the first tenant inquiry. Properties can be automatically identified based on previously provided tenant/tenant representative requirements or desires. A Farrington Industrial Park property 4642 has been identified, for example. The property 4642 has an owner 4644. A status item 4646 indicates that marketing materials have not been sent for the property 4642 in response to the first tenant inquiry. Once property materials have been sent, the status item 4646 can be selected and an indication of marketing materials being sent can be stored in the system.
Property team member icons 4648 for the property 4642 can be displayed. Another candidate property can be added for the first tenant inquiry using an add item 4650. A status indicator 4652 indicates that the property 4642 has an inquiry stage status with respect to the first tenant inquiry.
A McKinney & Hall property 4654 has also been identified (or selected) as a property for the first tenant inquiry. A status indicator 4656 indicates that the property 4654 has a proposal stage status with respect to the first tenant inquiry. A completion indicator 4668 indicates the proposal stage is seven percent complete.
The second tenant inquiry is for an Apple-Lake Highlands Office tenant 4660. A Concentra property 4662 and a Farrington Industrial Park property 4664 have been identified (or selected) for the second inquiry. A status indicator 4666 indicates that the property 4662 has a tour stage status with respect to the second tenant inquiry. A completion indicator 4668 indicates the tour stage is twenty five percent complete for the property 4662 with respect to the second tenant inquiry. A status indicator 4670 indicates that the property 4664 has a tour stage status with respect to the second tenant inquiry. A completion indicator 4672 indicates the tour stage is twenty five percent complete for the property 4664 with respect to the second tenant inquiry.
In response to a performed search for the “sandman” keyword 5002, the user interface 5000 is filtered to show a Sandman Industrial property 5006. In some implementations, a search keyword can match various fields, including a tenant name, a property name, a property address, a tenant representative name, a use type, a city, an owner name, or text in a note, to name a few examples. In some implementations, search matches are determined based on a smaller number of fields (e.g., only a tenant name, a tenant name or a property name, or some other combination of one or more fields).
In response to the search for the “abc” keyword 5102 and application of the filter by the inquiry stage status 5106 and the proposal stage status 5108, the inquiry area 5112 is filtered to show a Farrington Industrial Park property 5114 that has a stage status 5116 of inquiry, for a tenant inquiry for an ABC Inc. tenant 5118, and a McKinney & Hall property 5120 that has a stage status 5122 of proposal, for the tenant inquiry for the ABC Inc. tenant 5118.
Lease commencement date (LCD) information can be specified in a LCD area 5318. For example, an earliest lease commencement date 5320 and a latest lease commencement date 5322 can be entered (or selected). If lease commencement date information is not known at a time of inquiry creation, a TBD (To Be Determined) item 5324 can be selected.
A rent range area 5326 can be used to specify acceptable rents for the prospective tenant. For example, a minimum annual rent PSF (Per Square Foot) 5328 and a maximum annual rent PSF 5330 can be entered. As another example, a minimum monthly rent 5332 and a maximum monthly rent 5334 can be entered. In some implementations, a not-applicable item 5336 can be selected, such as if rent ranges are to be (at least not initially) considered for the inquiry. A desired state 5338 and a desired city 5340 can be entered (or selected).
A notes area 5342 can be used to enter additional notes related to the inquiry, such as to describe other tenant needs or preferences. For example, a note 5344 indicates that the prospective tenant would prefer to be near a bus line, on a ground level, on a corner. The entered tenant inquiry information can be saved in response to selection of a save control 5346. Creation of the tenant inquiry can be cancelled in response to selection of a cancel link 5348. A next inquiry step of selecting properties that may be a match for the prospective tenant can be initiated in response to selection of a select-properties control 5350. Tenant information entered or selected using the user interface 5300 can be saved in response to selection of the select-properties control 5350, before the property selection process begins.
Some or all of the Waco West property 5404, the McKinney & Hall property 5406, the Concentra property 5408, the Farrington Industrial Park property 5410, and the Olive Square property 5412 can be automatically identified by the system as a match for the tenant inquiry. Matching properties can be identified, for example, based on one or more of a lease commencement date, a primary use type, a square foot range, a rent range, a desired location (e.g., state, city, area of city), or based on other factors, such as custom requirements entered when the tenant inquiry is created. In some implementations, the broker can identify and select prospective properties and/or refine or reduce a set of properties automatically selected by the system. For instance, the broker may refine a set of candidate properties based on discussions with the tenant representative, such as to better find a matching property that better or best matches other tenant needs (e.g., tenant needs documented in a notes section).
Team members for a property can update a property's status with respect to the inquiry, and perform other actions. The user can enter or select a team member to associate with the property using a team member control 5902. For example, Bobby Tim 5904 has been selected. An entered or selected team member can be added using an add control 5906. A team area 5908 shows current team members. For example, Maria Sands 5910 and Steve Silver 5912 are current team members. A team count 5914 shows a count of current team members (e.g., currently there are two team members). Current team members can be removed using remove links 5916 or 5918, respectively. The user interface 5900 can be closed using a close link 5920.
A tenant name, a tenant representative name, a tenant representative email, and a tenant representative company can be edited using a tenant name control 6602, a tenant representative name control 6604, a tenant representative email control 6606, and a tenant representative company control 6608, respectively.
For example, a new tenant representative name and tenant representative email address have been entered in the tenant representative name control 6604 and the tenant representative email control 6606, respectively. Edited information can be saved in response to selection of a save control 6610. An edit operation can be cancelled in response to selection of a cancel link 6612.
In some implementations, a user can select a Move Tenant to Inactive link 6906 to mark the tenant inquiry as inactive. A tenant inquiry can be moved to an inactive state if a prospective tenant has put a project on hold, or has communicated a lack of interest (at least temporarily) in completing a deal. As another example, a tenant inquiry can be marked as inactive if a prospective tenant has been unresponsive for a certain period of time. Other reasons can cause a tenant inquiry to be marked as inactive.
At 7702, a request is received from a first user to access a lease transaction management system.
At 7704, a first organization and a first role associated with a current session of the first user are determined. The first organization can be a leasing agency, a property ownership group, or a tenant agency, to name a few examples. The first role can be a property owner, a leasing team member, a broker, or a tenant representative. The first user can have different roles for different organizations or properties. When the first user is associated with more than one organization, determining the first organization associated with the current session can include receiving selection of the first organization from the first user. As another example, the first organization can be determined based on a website address or a login identifier. The first role can be determined based on the first organization and user identifying information.
At 7706, a user interface of the lease transaction management system is customized based on the first organization and the first role associated with the current session, including the displaying of information for tenant inquiries that the first user is authorized to view based on the first role and the first organization.
At 7708, first tenant inquiry information for a first tenant inquiry for a first prospective tenant is received, through the user interface. The first tenant inquiry information can be new tenant inquiry information and the first tenant inquiry can be a new tenant inquiry. As another example, the first tenant inquiry information can be updated tenant inquiry information, the first tenant inquiry can an existing inquiry, and the stored tenant inquiry information for the first tenant inquiry can be updated with the first tenant inquiry information. The first tenant inquiry information can include one or more of a primary use type, a property size specification, a lease commencement date range, a desired location, or a rent specification.
At 7710, at least one matching property that matches the tenant inquiry information is automatically identified. Automatically identifying the at least one matching property can include identifying at least one property that matches updated stored tenant inquiry information for the first tenant inquiry, when the first tenant inquiry information is updated tenant inquiry information. Automatically identifying the at least one matching property can include identifying one or more properties that match one or more of a primary use type, a property size specification, a lease commencement date range, a desired location, or a rent specification of the first tenant inquiry. Additionally or alternatively, a user can select a property as a match for tenant inquiry.
At 7712, information about the at least one matching property is presented, in the user interface, to the first user. The user interface can enable action(s) to be performed, related to the first tenant inquiry or about properties that have been identified for the first tenant inquiry. For example, the sending of marketing materials for the property can be initiated and recorded. A user can indicate whether the tenant has expressed interest in (or has indicated a lack of interest in) a given property. A tenant inquiry can be marked as active or inactive. As described below, a user can select a property for formal deal proceedings, from among multiple candidate properties identified for a tenant inquiry. Other types of actions can be performed.
Information regarding performance of an action relating to the first tenant inquiry can be received, by the application or system. The user interface can be updated to reflect performance of the action relating to the first tenant inquiry. Receiving information regarding performance of the action can include receiving a user input provided to the user interface that indicates completion of the action. The first user may be assigned to the first tenant inquiry and the user input may be received from the first user. Receiving information regarding performance of the first action can include automatically receiving information from an application.
The information regarding performance of the action can indicate completion of the action and a next action for the first tenant inquiry can be determined. At least one assigned user who is assigned to the next action can be determined. A notification can be provided to the at least one assigned user regarding the next action. The notification can be provided in the user interface, as an electronic message, or through some other means. The action can be a last action of a first stage of a tenant inquiry workflow. Determining the next action can include updating a stage status of the first stage to be completed, determining a next stage, and determining a first action of the next stage as the next action. Stages of the tenant inquiry workflow can include inquiry, tour, and proposal.
Different properties associated with the first tenant inquiry can have different stage statuses. For example, a first property can have an inquiry status, a second property can have a tour status, and a third property can have a proposal status. When multiple properties are associated with the first tenant inquiry, a selection of a particular property (e.g., a first property) for formal deal proceedings can be received. For example, a tenant or tenant representative can finalize selection of a property for a lease, from among multiple candidate properties.
In response to receiving selection of a property for formal deal proceedings, a deal workflow process for the property can be initiated and the first tenant inquiry can be marked as completed. A deal workflow process can have at least some different stages than the first tenant inquiry. For example, the deal workflow process can include lease, revenue, and completion stages, among other different stages. In some implementations, a current stage of the first tenant inquiry is mapped to a corresponding stage of the deal workflow process, and the deal workflow process can continue at the corresponding stage of the deal workflow process. For example, a property associated with the first tenant inquiry can be in a proposal stage, and upon selection of the property for formal deal proceedings, a deal workflow process can be initiated for the property in a deal proposal stage. Some of the activities completed for the property in an inquiry proposal stage can be moved to or otherwise associated with corresponding actions of a deal proposal stage, for example. A deal proposal stage (and/or a deal tour stage) can have at least some of the same activities as a corresponding tenant inquiry proposal (or inquiry tour stage), respectively.
At 7802, tenant inquiry information for a tenant inquiry is analyzed to identify a plurality of tenant inquiry parameters. Tenant inquiry parameters can include a primary use type, a property size specification, a desired location, a desired lease commencement date, and a rent specification.
At 7804, a plurality of rules for matching tenant inquiry parameters to candidate properties are identified. Rules may be used to assign different weights for different tenant inquiry parameters. Some tenant inquiry parameters may have higher weight than others, in general, and some tenant inquiry parameters may have a higher weight for a particular prospective tenant, or a particular tenant inquiry, than for other tenant inquiry parameters. For example, unless configured otherwise, a rent parameter may have a higher weight than a property size parameter. As another example, for a particular tenant or a particular tenant inquiry, a property size parameter may have a higher weight than a rent parameter.
The plurality of rules can indicate that tenant inquiry parameters that are marked as required must match a candidate property for the candidate property to be considered a match. For instance, a required tenant inquiry parameter can include a location value that represents a required location for a candidate property. For instance, a tenant may insist that a property be located in the city of Dallas. As another example, a tenant may indicate that a lease commencement date is required, or that the lease commencement date is flexible. A tenant inquiry creation (and/or modification) user interface can enable a user to specify which tenant inquiry parameters are required, to assign weights to tenant inquiry parameters, or to otherwise configure rule(s) for how the tenant inquiry is to be matched to candidate properties.
At 7806, a match score is generated, for each candidate property, based on the identified rules for matching tenant inquiry parameters to candidate properties. The match score for a candidate property can be an aggregate score that is based on a degree of match of each of multiple tenant inquiry parameters to corresponding parameter values for the property. If a candidate property does not meet a required tenant inquiry parameter, the match score for that candidate property can be set, e.g., to zero, or some other value less than the predetermined threshold.
At 7808, a determination is made as to whether at least one candidate property has a match score that exceeds a predetermined threshold. If no candidate properties have a match score that exceeds the predetermined threshold, a notification can be presented. In some implementations, the system enables the user to manually select a property that, for example, a broker may believe to be a potential fit for a tenant, even if the automatically-generated match score for the property does not exceed the predetermined threshold. In some implementations, a same predetermined threshold is used for all tenants and for all tenant inquiries. In some implementations, different predetermined thresholds can be used for different tenants and/or different tenant inquiries. In some implementations, if no candidate properties have a match score that exceeds a first predetermined threshold, a second, lower predetermined threshold can be used and a determination can be made as to whether any candidate properties have a match score that exceeds the second, lower predetermined threshold. For instance, a secondary search can be performed, if a first search does not return results.
At 7810, in response to determining that at least one candidate property has a match score that exceeds the predetermined threshold, the one or more candidate properties that have a match score that exceeds the predetermined threshold are selected as matching properties for the tenant inquiry. As described above, information about the one or more matching properties can be presented, e.g., in a user interface in which a tenant inquiry is being viewed.
A stage area 7914 displays information indicating counts of deals by stages. For example, a tour stage count 7916 and a proposal stage count 7918 indicate that there is currently one deal in a tour stage and one deal in a proposal stage, respectively. The tour stage count 7916 and the proposal stage count 7918 are reflected in a chart 7920, in chart portions 7922 and 7924, respectively.
A current inquiry count 8004 indicates that there is one current inquiry. A moved-to-deal count 8006 indicates that twenty three inquiries have previously been transitioned to respective deals. An inactive count 8008 indicates that no inquiries are currently inactive. The user can search for inquiries using a search control 8010 and add a new inquiry using an add inquiry control 8012.
The inquiry area 8002 is displaying an inquiry for an ABC Corp prospective tenant 8014, with a tenant representative 8016 of D. Dodge from DDD Agency, a requested square footage 8018 of 2,000-10,000 square feet, and a candidate property 8020 of Clayton Plaza. The inquiry for ABC Corp can be deleted using a delete control 8022. The inquiry for ABC Corp can be moved to (e.g., transitioned to) a deal in response to user selection of a move-to-deal control 8024.
A deal type 8108 can be defaulted as “new deal.” Other deal types can include renewal, expansion, contraction, assignment, or termination. A task template 8110 can be used to set up a set of predefined tasks for the new deal. Templates are described in more detail below. A link 8112 can be selected to proceed to a next step of the move-to-deal process.
For example and as shown in the move-to-deal user interface 8102 of
The move-to-deal user interface 8104 of
Other approaches can be used for inquiries and deals. For example, the system can automatically create an inquiry in response to receiving a direct message from a tenant (e.g., an email or some other type of message) that the system determines is inquiry-related. The automatically created inquiry can be created with a same creation date as an initial inquiry related email or message. Content from other messages in a same conversation can be added to the inquiry (e.g., as notes).
The preceding figures and accompanying description illustrate example processes and computer-implementable techniques. But system 100 (or its software or other components) contemplates using, implementing, or executing any suitable technique for performing these and other tasks. It will be understood that these processes are for illustration purposes only and that the described or similar techniques may be performed at any appropriate time, including concurrently, individually, or in combination. In addition, many of the operations in these processes may take place simultaneously, concurrently, and/or in different orders than as shown. Moreover, system 100 may use processes with additional operations, fewer operations, and/or different operations, so long as the methods remain appropriate.
In other words, although this disclosure has been described in terms of certain embodiments and generally associated methods, alterations and permutations of these embodiments and methods will be apparent to those skilled in the art. Accordingly, the above description of example embodiments does not define or constrain this disclosure. Other changes, substitutions, and alterations are also possible without departing from the spirit and scope of this disclosure.
Filing Document | Filing Date | Country | Kind |
---|---|---|---|
PCT/US20/49979 | 9/9/2020 | WO |
Number | Date | Country | |
---|---|---|---|
62897922 | Sep 2019 | US | |
62964004 | Jan 2020 | US |