JP7454144B2 - Activity management method using chat and management server - Google Patents

Description

The present invention relates to an activity management method using chat and a management server.

As background technology in this technical field, there is Japanese Patent Application Publication No. 2017-224207 (Patent Document 1). This bulletin states, ``When setting the rent for a rental property, self-managing landlords refer to the structure information and subjective evaluation of the rental property, so self-managing landlords may be subject to extreme deviations from the market rent for similar properties in the surrounding area. You can easily set the rent by yourself aiming for the maximum profit that can be expected without any loss.In addition, in order to manage the ranking information regarding the real estate agent and each sales person who request customers for real estate property, self-managed landlord Can be selected for a ranking brokerage business or each sales representative suitable for each rental property when requesting a rental property. Furthermore "Since the information is stored by rank, it is possible to easily find the operator suitable for each rental property from among multiple operators." (See summary).

Additionally, there is Japanese Patent Application Publication No. 2017-138932 (Patent Document 2). This bulletin states, ``The authentication unit 14 authenticates the system user, and if the system user authenticated by the authentication unit 14 is a business person, the first authority is granted to the system user authenticated by the authentication unit 14. When the user is a customer, an authority granting unit 15 that grants a second authority different from the first authority, a customer information registration unit 16 that registers customer information, and ownership information that associates customer information and property information. an ownership information registration unit 17 that registers ownership information, an ownership information storage unit 18 that stores ownership information registered by the ownership information registration unit 17, and a page generation unit 19 that generates a management web page for each customer. and a simulation execution unit 20 that executes a simulation based on the information.''

JP2017-224207A Japanese Patent Application Publication No. 2017-138932

Patent Document 1 describes a system for managing rental income properties. Furthermore, Patent Document 2 describes a mechanism for executing a profitability simulation of an investment property. However, none of the patent documents considers methods of communicating with customers.
Therefore, the present invention provides a mechanism for managing activities of assets owned by an owner using chat.

In order to solve the above problems, for example, the configurations described in the claims are adopted.
The present application includes multiple means for solving the above problems, but one example is an activity management method using chat, which stores a list of activities that require confirmation from the owner of the real estate property. receives the selection of the real estate property, receives the selection of the activity from the activity list, acquires real estate property information regarding the activity of the selected real estate property, and receives an activity card into which the acquired real estate property information is input. The activity card is generated and posted to a chat where messages are exchanged with the owner.

According to the present invention, it is possible to provide a mechanism for managing activities of assets owned by an owner using chat.
Problems, configurations, and effects other than those described above will be made clear by the following description of the embodiments.

1 is an example of a configuration diagram of the entire asset management system 1. FIG. This is an example of the hardware configuration of the management server 101. This is an example of the hardware configuration of the owner terminal 102. This is an example of the hardware configuration of the asset management company terminal 103. This is an example of user information 500. This is an example of topic category information 600. This is an example of activity category information 700. This is an example of activity master information 800. This is an example of activity detailed information 900. This is an example of message information 1000. This is an example of access token information 1100. This is an example of asset management information 1200. This is an example of a chat screen 1300. This is an example of a topic creation screen 1400. This is an example of an activity details input screen 1500. This is an example of an activity card preview screen 1600. This is an example of an activity card posting screen 1700. This is an example of an activity denial screen 1800. This is an example of an activity approval screen 1900. This is an example of an activity details screen 2000. This is an example of a notification setting screen 2100. This is an example of an activity list screen 2200. This is an example of an activity details screen 2300. This is an example of an activity master screen 2400. This is an example of an activity master addition screen 2500. This is an example of a chat screen 2600. This is an example of an activity details screen 2700. This is an example of an activity approval screen 2800 and a denial screen 2850. This is an example of a post-rejection chat screen 2900. This is an example of an activity list screen 3000. This is an example of an activity filter screen. This is an example of an asset management screen 3200. This is an example of an activity card posting process flow 3300. This is an example of an activity card display/answer processing flow 3400. This is an example of an owner confirmation response reception processing flow 3500. This is an example of an activity card list display processing flow 3600.

Examples will be described below with reference to the drawings.
FIG. 1 is an example of a configuration diagram of the entire asset management system 1. As shown in FIG.
The asset management system 1 includes a plurality of owner terminals 102 and a plurality of asset management company terminals 103, each of which is connected to a management server 101 via a network. Note that each terminal can send and receive information via the network, regardless of whether the network is wired or wireless.
The owner terminal 102 is a terminal used by an owner of assets such as investment real estate.
The asset management company terminal 103 is a terminal used by an asset management company that manages assets.

Each terminal of the asset management system 1 and the management server 101 may be, for example, a mobile terminal such as a smartphone, a tablet, a mobile phone, or a personal digital assistant (PDA), or may be a glasses-type, wristwatch-type, clothing-type, etc. It may also be a wearable terminal. Alternatively, it may be a stationary or portable computer, or a server placed on a cloud or network. In addition, the function may be a VR (Virtual Reality) terminal, an AR terminal, or an MR (Mixed Reality) terminal. Alternatively, it may be a combination of these multiple terminals. For example, a combination of one smartphone and one wearable terminal can logically function as one terminal. Further, information processing terminals other than these may also be used.

Each terminal of the asset management system 1 and the management server 101 each have a processor that executes an operating system, an application, a program, etc., a main storage device such as a RAM (Random Access Memory), an IC card, a hard disk drive, or an SSD (Solid State Drive). state drive), auxiliary storage devices such as flash memory, communication control units such as network cards, wireless communication modules, and mobile communication modules, touch panels, keyboards, mice, voice input, and input based on motion detection using image capture by the camera unit. It includes an input device and an output device such as a monitor or display. Note that the output device may be a device or terminal that transmits information to be output to an external monitor, display, printer, device, or the like.

The main storage device stores various programs, applications, etc. (modules), and when a processor executes these programs and applications, each functional element of the overall system is realized. Note that each of these modules may be implemented in hardware by integrating them or the like. Further, each module may be an independent program or application, or may be implemented as a part of a subprogram or function within one integrated program or application.

In this specification, each module is described as an entity (subject) that performs processing, but in reality, a processor that processes various programs, applications, etc. (modules) executes the processing.
Various databases (DB) are stored in the auxiliary storage device. A "database" is a functional element (storage unit) that stores a data set so that it can handle any data operation (e.g., extraction, addition, deletion, overwriting, etc.) from a processor or an external computer. The method of implementing the database is not limited, and may be, for example, a database management system, spreadsheet software, or a text file such as XML or JSON.

FIG. 2 is an example of the hardware configuration of the management server 101.
The management server 101 is configured of a server placed on a cloud, for example.
The main storage device 201 stores programs and applications such as an activity management module 211, a data registration management module 212, and an asset registration management module 213. When the processor 203 executes these programs and applications, the management server 101 Each functional element is realized.

The activity management module 211 provides a chat function with the owner terminal, and also manages activities for assets such as real estate owned by the owner. The following describes the activity management of real estate properties, but it is not limited to real estate, but can be applied to a wide range of asset management, including movable assets such as automobiles, jewelry, and jet aircraft, and financial assets such as stocks, securities, and savings.

Activities are various confirmation items that need to be confirmed by the owner for assets such as real estate properties to be managed. For example, we report, propose, and notify the owner regarding eviction reports, tenant recruitment, restoration to original condition, construction, renewal, income and expenditure reports, delinquency reminders, taxes, repair proposals, sales appraisal proposals, and others, and the owner confirms and approves them. This refers to the matters that need to be obtained.
Note that "confirmation" is sometimes used to include confirmation and approval.

The data registration management module 212 registers and manages user information, information regarding activities, and the like.
The asset registration management module 213 registers information on assets held by owners and asset management companies in the asset management information 1200 and manages the information. Further, information on these assets is displayed on the owner terminal in cooperation with the owner asset management module 310 of the owner terminal 102.

In this embodiment, the activity management module 211 provides the chat function, but the chat function may be provided by a separately configured chat management module. Alternatively, the chat function may be provided by a chat management module of a chat management server configured separately from the management server 101.
Asset registration management may be provided by an asset registration management module of an asset information management server configured separately from the management server 101.

The auxiliary storage device 202 includes a main DB 220.
The main DB 220 includes user information 500, topic category information 600 that is information related to activities, activity category information 700, activity master information 800, activity detailed information 900, message information 1000 that is information related to chat, and access information that is information related to authentication. It stores token information 1100, asset management information 1200 about assets to be managed, and the like.

FIG. 3 is an example of the hardware configuration of the owner terminal 102.
The owner terminal 102 is configured of a terminal such as a smartphone, a tablet, a notebook PC, or a desktop PC.
The main storage device 301 stores programs and applications such as an owner asset management module 310, and each functional element of the owner terminal 102 is realized by the processor 303 executing these programs and applications.

The owner asset management module 310 cooperates with the asset registration management module 213 of the management server 101 to display property information, current value, cash flow, etc. of assets such as real estate owned by the owner.
The auxiliary storage device 302 stores owner asset management information 320, which is information about assets owned by the owner.

FIG. 4 is an example of the hardware configuration of the asset management company terminal 103.
The asset management company terminal 103 is configured of a terminal such as a smartphone, tablet, notebook PC, or desktop PC.
The main storage device 401 stores programs and applications such as a management company asset management module 410, and when the processor 403 executes these programs and applications, each functional element of the asset management company terminal 103 is realized. .

The management company asset management module 410 cooperates with the asset registration management module 213 of the management server 101 and transmits property information, revenue information, etc. of assets such as real estate managed by the asset management company to the management server 101. Additionally, confirmation information regarding the owner's activities with respect to the real estate property is received.
The auxiliary storage device 402 stores management company asset management information 420, which is information about assets managed by an asset management company.

5 to 12 show various information stored in the management server. Although it is assumed that all or some of these are stored in a JSON format file, the invention is not limited to this. It may also be configured to be stored in a relational database or a non-relational database.
FIG. 5 is an example of user information 500.
The user information 500 stores information regarding users whose activities are managed by the activity management module 211. For example, information such as the owner of real estate is stored.

The user information 500 includes a user ID 501, a user display ID 502, a position 503, a location 504, an attribute tag 505, etc., and a value as exemplified by a sample value 540 is input to each field name 530.
The user ID 501 is a unique ID such as an automatically generated hash value, and is a primary key that is referenced from other information.

The user display ID 502 is the ID of the user displayed on the screen of the management server 101, the owner terminal 102, etc., and is an automatically generated unique ID such as USER-1234, for example.
Job title 503 indicates the user's job title or role.
The location 504 indicates the user's location, language, region, and the like.
The attribute tag 505 indicates a tag attached to each user's attribute. For example, it is possible to tag someone with the fact that they are from a Tokyo office, or that they are from Shibuya Ward.

FIG. 6 is an example of topic category information 600.
Topic category information 600 stores a list of topics (items) to which conversations that occur in chat belong.
The topic category name 601 indicates the content of the topic. For example, topics such as eviction report, tenant recruitment, restoration to original condition, construction, renewal, income and expenditure report, delinquent payment reminder, tax, repair proposal, sale appraisal proposal, etc. are stored.
The topic category ID 602 is a unique ID assigned to each topic. For example, a hash value or the like is stored.

FIG. 7 is an example of activity category information 700.
The activity category information 700 stores a list of categories to which each activity used by the activity management module 211 belongs.
The activity category name 701 indicates the type to which the activity card belongs. For example, expense approval, rental condition approval, etc. are stored.
The activity category ID 702 is a category ID, a primary key referenced from other information, and a unique ID that is automatically generated.

FIG. 8 is an example of activity master information 800.
Activity master information 800 stores the contents of each activity. Information on commonly used activities is stored in advance, but users and administrators can also add new activities.
Activity master name 801 indicates the name of the activity master. If the information is entered by the user, it can be freely written.

Activity master type 802 indicates the type of activity master. It is selected from preset values, and stores, for example, approval, notification, contract, etc. The approval type (Approval) is for sending an approval request to obtain approval for confirmation items from the owner. Receive input of approval (Approval) or denial (Decline) from the owner. The notification type (Notice) is for sending a confirmation request to the owner to confirm the confirmation items. An input of a confirmation button is accepted from the owner. The contract type (Contract) is for sending an electronic approval request to obtain electronic approval from the owner. Receive electronic approval input from the owner using the electronic contract service.
Activity category ID 803 indicates the category of activity. The value of activity category ID 702 of activity category information 700 is referred to.
Activity master purpose 804 indicates the purpose of the activity master. Users and administrators can write freely.

Title 805 indicates a title used for a chat message sent in connection with the activity. You can write freely.
Content 806 indicates the text content of the chat message sent in connection with the activity. Although predetermined contents are written, you can also write freely. For example, as described in the sample value 823, room cleaning costs, wallpaper replacement costs, tatami replacement costs, door lock change costs, etc. are entered as predetermined examples of expenditures.
Destination user 807 indicates the user to whom the activity card is sent.

Attachment 808 indicates a path to a file that is sent as an attachment.
The display ID 809 is an ID of an activity displayed on the screen of the management server 101, owner terminal 102, etc., and is a unique ID that is automatically generated, such as ACT-1234, for example.
Activity master ID 810 indicates a unique ID generated for the activity master.
Deletion flag 811 indicates whether the activity master has been deleted.

FIG. 9 is an example of activity detailed information 900.
The activity detailed information 900 stores detailed information of each activity.
Activity message content 901 indicates the content of the activity. The message is updated and stored by inputting the amount, adding a description, etc. to the information called up from the activity master.
For example, in the example of sample value 940, amounts are input and stored as expenses for room cleaning costs, wallpaper replacement costs, tatami replacement costs, and door lock change costs read out from the activity master content 806.

These amounts may be input by the user or the administrator, but the data registration management module 212 or asset registration management module 213 may collect past activities for the same real estate property owned by the owner and past asset management information. , the asset management information 1200, etc., may be acquired from past information stored in the main DB 220 and input based on the information.
In addition, the value is calculated based on not only real estate properties owned by the same owner, but also information on the same properties owned by other owners, properties similar to the input target property, properties surrounding the input target property, etc. It is also possible to enter a configuration in which the following information is entered.

The activity message sending date 902 indicates the date and time when the message corresponding to the activity was sent.
Status 903 indicates the status of the activity. For example, information such as approval and denial is stored.
User ID 904 indicates the user who sent the activity.

Activity master ID 905 indicates the ID of the activity master. The activity master ID 810 of the activity master information 800 is referred to.
Message ID 906 is an ID indicating a message sent in response to an activity. Message ID 1007 of message information 1000 is referred to.

FIG. 10 is an example of message information 1000.
Message information 1000 stores the contents of messages sent and received on chat.
Message content 1001 indicates the content of the message. For example, as in the sample value 1040, messages exchanged with the owner are stored.
User type 1002 indicates the type (attribute) of the user who sends the message. For example, a PM (property management company) operator, owner, etc. are stored.
The expansion area 1003 is an area that can be expanded freely.

The read date and time 1004 stores the timestamp of the date and time when the message became read.
Sender ID 1005 indicates the ID of the user who sent the message. The value of the user ID 501 of the user information 500 is input and referenced, or the value of the token ID 1102 of the access token information 1100 is input and referenced.
Topic category 1006 indicates which topic the message belongs to. The value of the topic category ID of the topic category information 600 is referred to.
Message ID 1007 indicates a unique ID generated for each message.

FIG. 11 is an example of access token information 1100.
Access token information 1100 is a token used for user authentication.
Authentication token 1101 indicates a randomly generated token.
The token ID 1102 is a unique ID that is automatically generated and is a primary key.

FIG. 12 is an example of asset management information 1200.
The asset management information 1200 stores information about assets such as real estate owned by an owner and assets such as real estate managed by an asset management company.
For example, information for specifying assets such as asset ID 1201, name 1202, address 1203, and asset type 1204, revenue information for these assets, current value, cash flow, etc. are stored.
The asset management information 1200 stores information regarding a large number of assets using a relational database or the like, but the storage format is not limited to this.

FIG. 13 is an example of a chat screen 1300.
The activity management module 211 of the management server 101 displays a list of chat exchanges 1303 regarding each asset owned by a specific owner 1302 among information 1301 regarding the plurality of owners being managed.
When the activity management module 211 receives a user's instruction to display a specific property, the activity management module 211 displays the chat exchange regarding the specific property in the chat window 1310. A chat window 1310 displays a message 1304 from an operator operating the management server 101 and a corresponding message 1305 from the owner in a chat format.

Operators can create chat rooms, called multiple topics, for owners. For example, topics can be created freely, such as "Regarding taxes" or "Regarding repairs to property A." When the operator selects an owner and clicks the topic creation button 1330, a topic creation screen 1400 is displayed.
If the operator wishes to notify the owner of confirmation items such as approval, notification, contract, etc., the operator selects the activity creation button 1320 and performs activity card posting processing.

FIG. 14 is an example of a topic creation screen 1400.
When the operator presses the topic creation button 1330, the activity management module 211 displays a topic creation screen 1400.
The operator inputs a topic 1401 on a topic creation screen 1400 and selects a target topic from a topic category 1402. Note that in response to the selection of the topic category 1402, the corresponding topic name may be automatically input into the topic 1401.
The activity management module 211 receives selection of target assets from the operator. The operator selects the asset owned by the owner from the asset selection area 1403 using a pull-down menu.

FIG. 33 is an example of an activity card posting process flow 3300.
When an operator operating the management server 101 needs to check with the owner of a real estate property, the activity management module 211 generates an activity card and makes an inquiry to the owner via chat. Note that, in addition to the operator of the management server 101, an operator of the asset management company may make inquiries using the management company asset management module 410 via the activity management module 211.

When the operator presses the activity creation button 1320, the activity management module 211 displays the activity selection screen 1550 (step 3310).
The activity management module 211 receives the selection of an activity from the operator (step 3320).
The bolded portion 1551 and the like are activity categories and are predefined by the system. The thinned portion 1552 is predefined by the system, but can be edited by the operator, and new activities can also be added.

Note that when the topic category 1402 is selected, the activity management module 211 may be configured to display only a list of activities belonging to this topic category on a pop-up screen. For example, when the topic category 1402 "Recruiting Tenants" is selected, an activity selection screen 1550 pops up, and "Approval for Leasing Criteria" is selected under "Leasing" 1551. Activities 1552 such as "Property inquiries,""Applicationnotice," and "Application approval" are displayed to be selectable, and a selection from the operator is accepted.
Note that after selecting the category, the content to be confirmed may be selected according to the category, such as "approval of conditions for resident recruitment", confirmation of conditions for resident recruitment, etc., such as approval, notification, contract, etc.

The activity management module 211 displays the activity details input screen 1500 regarding the selected activity (step 3330), and receives input of detailed information from the operator (step 3340).
FIG. 15 is an example of an activity details input screen 1500.
Activity title 1510 is a title indicating an overview of the activity.
Property information 1501 indicates information about a property. It can be changed on this screen.
The target room number 1502 indicates the target room owned by the owner in the property.
The message 1503 describes the content of the message that the user wants to convey to the user when the activity card is sent.
Attachment 1504 indicates an attached document to be sent with the activity card.

Inquiry title 1512 displays the title of the content of the inquiry. In the inquiry content 1511, contents for which the owner wants to confirm are entered, and numerical information for confirmation is entered.
For example, an example of the activity details input screen 1500 is an input for an activity of obtaining "approval of occupancy conditions." As the occupancy conditions of the inquiry content 1511, amounts, figures, and text such as rent, management fee, security deposit, key fee, key money, advertisement, etc. are entered and approved by the owner.
In this inquiry content 1511, past information of the corresponding property stored in the asset management information 1200 is called up and input. It is also possible to overwrite and update the input information.

In addition, information on the occupancy conditions of other rooms in the same real estate property managed by the asset registration management module 213 is acquired from the asset management information 1200, and the activity management module 211 analyzes this. It is also possible to present new occupancy conditions adjusted based on the occupancy conditions of the room. In this case, highlight only the differences from past occupancy conditions by changing the color, make a proposal to the owner, and ask for confirmation.
For example, if the current rent was 101,000 yen, but the rent for another room has increased to 103,000 yen, the rent proposed to the owner should be changed to 103,000 yen and highlighted in red. You can generate a highlighted activity card and ask the owner for approval.

Other possible methods include determining the proposed rent from the average rent of similar properties in the same area, or determining the proposed rent based on trends in rent increases or decreases from the past to the present.
In this embodiment, multiple assets managed by multiple asset management companies are managed in an integrated manner by the management server 101, so that owners can receive information based on integrated information spanning multiple properties. You can modify the content of your inquiry for confirmation and make a proposal.

When the send button 1520 is pressed, the activity management module 211 generates an activity card based on the input information and the input information called from the asset management information (step 3350). A pre-send confirmation screen may be displayed if necessary.
When the operator confirms the contents of the activity card, the activity management module 211 posts the generated activity card to the chat where messages are exchanged with the owner (step 3360).

FIG. 17 is an example of an activity card posting screen 1700.
In a chat where messages are exchanged between the owner and the operator, an activity card 1702 is posted along with a message 1701 from the operator. The content entered in the message 1503 on the activity details input screen 1500 is posted and displayed as a chat message 1701. Note that it is also possible for the operator to input a message during a normal chat.
The activity card 1702 includes an activity title 1703, a display ID 1704, contents 1705, and an attachment 1706.
These pieces of information are stored in corresponding items of the activity master information 800.

Regarding sending and receiving activity cards on chat, an approve button 2720 and a reject button 2730 are displayed on the activity card on the owner's chat screen, but an approve button and a reject button are displayed on the operator's chat screen. No display. In the case of chat, the same message is normally displayed on both the sending and receiving sides, but in this example, the operator does not approve or disapprove, so in order to avoid confusion, the operator does not display the approval or disapproval button. Make it. However, these buttons may be displayed on the operator side.

FIG. 18 is an example of an activity denial screen 1800.
This is an example of a screen that is displayed after the owner selects Decline from the confirmation button 1707 and performs the activity card display/answer process 3400.
The activity management module 211 displays the comment written by the owner at the time of rejection as a chat message 1801.
Furthermore, the activity management module 211 displays the details and reasons for the denial as a response screen 1802.

FIG. 19 is an example of an activity approval screen 1900.
This is an example of a screen that is displayed after the owner selects Approve from the confirmation button 1707 and performs the activity card display/answer process 3400.
The activity management module 211 displays the approved content as a response screen 1901.
At the time of approval, since the owner is not specifically asked to enter a comment, no message is displayed, and only a message indicating that the approval has been received is displayed. However, the owner may optionally enter a comment and the comment may be posted as a message in the chat.

FIG. 35 is an example of an owner confirmation response reception processing flow 3500.
The activity management module 211 receives the response information (answer screen) sent via chat by the owner asset management module 310 of the owner terminal 102 (step 3510).
The activity management module 211 analyzes and imports the response information (step 3520), and updates the status 903 of the activity detailed information 900 based on this content (step 3530).

FIG. 20 is an example of an activity details screen 2000.
View detailed information for activities that have been submitted or approved, denied, or confirmed by the owner.
The activity details screen 2000 displays the owner's confirmation details 2004, activity card 2003, activity details 2002, etc. as the activity history 2001 that has been exchanged with the owner.

FIG. 21 is an example of a notification setting screen 2100.
The activity management module 211 displays a notification when a message or confirmation response is sent from the owner for an activity in a category selected in the notification category 2101.

FIG. 22 is an example of an activity list screen 2200.
FIG. 36 is an example of an activity card list display processing flow 3600.
The activity list screen 2200 is displayed when the activity list display button 2201 is selected.
The activity management module 211 accepts conditions for narrowing down the list of activities to be displayed (step 3610). For example, narrowing down can be performed based on information such as owner name 2202, category name 2203, activity name 2204, status 2205, read/unread 2206, and creation date 2207.

The activity management module 211 acquires corresponding activity information from the activity master information 800 and the activity detailed information 900 according to the narrowing down conditions (step 3620).
The activity management module 211 displays the acquired information on the activity list screen 2200 (step 3630).

An example of the activity list screen 2200 is an example of displaying a list of activities related to leasing for a specific owner. Among the plurality of real estate properties 2211 owned by this owner, those whose category 2212 is Leasing are extracted, and the current status 2214 of each activity 2213 is displayed in a list.
According to this embodiment, it is possible to display and manage the current status list of each activity while communicating with the owner by linking with chat, making the real estate management work of the operator easier and more efficient. It becomes possible.

FIG. 23 is an example of an activity details screen 2300.
Activity details screen 2300 is displayed when a specific activity is selected in activity list screen 2200.
The activity history 2302, owner confirmation status 2304, and activity details 2303 of the selected activity are displayed.

FIG. 24 is an example of an activity master screen 2400.
The operator of the management server 101 can aggregate activities for each activity category. The activity management module 211 acquires the corresponding activity information from the activity master information 800 and the activity detailed information 900 for activities filtered by the same conditions as the activity list screen 2200, and displays the aggregated information for each activity master item 2401. do.
The number of sent items 2402, the number of items approved by the owner 2403, the number of items confirmed by the owner 2404, etc. are aggregated and displayed.

FIG. 25 is an example of an activity master addition screen 2500.
When the operator clicks the activity master addition button 2405, the activity management module 211 displays an activity master addition screen 2500.
Although the activity management module 211 has registered a plurality of activity information in advance, the operator can add activities as desired.
The activity management module 211 accepts input of an activity name 2501, an activity category 2502, an activity type 2503, a purpose 2504, a message 2505, a title 2506, a content 2507, etc., and adds them to the activity master information 800.
The activity type 2503 includes, for example, approval, notice, contract, and the like, and is selected depending on the content of the confirmation request to be sent to the owner.

FIG. 16 is an example of an activity card preview screen 1600.
When the operator clicks preview button 2508, activity management module 211 displays activity card preview screen 1600.
The activity card 1601 has inquiry details 1602 and a confirmation button 1603.
In the inquiry content 1602, for each item in the inquiry content 1511 of the activity details input screen 1500, the amount to be confirmed by the owner, a numerical value, text, etc. are input.
The activity management module 211 uses, as the confirmation button 1603, a "confirm" button, a "contract" button for proceeding to an electronic contract, or the like, in addition to an "approve/reject" button, depending on the content of the activity.

26 to 32 are examples of screens displayed on the owner terminal 102.
FIG. 26 is an example of a chat screen 2600.
The owner asset management module 310 of the owner terminal 102 cooperates with the activity management module 211 of the management server 101 to provide a chat function between the owner and the operator.
A chat screen 2600 displays a message 2601 from an operator and an owner's response to the message 2602.

The activity card 2604 generated by the operator's operation is posted to the chat together with the operator's message 2603 and displayed on the chat screen 2600. When details 2610 is selected, owner asset management module 310 displays activity details screen 2700.
Within the chat, an attachment 2611 is sent along with the activity card 2604.

FIG. 27 is an example of an activity details screen 2700.
The activity details screen 2700 includes a topic 2701, an activity title 2702, a property name 2703, a status 2704, a message 2705, an inquiry content 2710, an attachment 2711, an approve button 2720, and a reject button 2730.
The contents of the activities and activity cards described above are input.
When the owner presses the approval button 2720, the owner asset management module 310 displays an activity approval screen 2800. When the owner presses the deny button 2730, the owner asset management module 310 displays an activity deny screen 2850.

FIG. 28 is an example of an activity approval screen 2800 and a denial screen 2850.
After confirming the inquiry details 2810 again, the owner taps an approval button 2820 to approve the inquiry as is. If you do not approve, tap the reject button 2830.
In the case of denial, the message input field 2801 is made a mandatory input field to request the owner's comment in order to notify the reason.

FIG. 29 is an example of a post-rejection chat screen 2900.
In the case of denial, the owner asset management module 310 posts the message 2901 input in the message input field 2801 to the chat, and posts the answer screen or answer information 2902 to the chat. In this way, by posting the reason for rejection inputted along with the rejection of an activity card as a chat message, communication between the operator and the owner can be carried out smoothly.
In addition to information such as a topic 2903 and an activity title 2904, the response screen displays a status 2905 of the owner's response.

FIG. 34 is an example of an activity card display/answer processing flow 3400.
The owner asset management module 310 displays a chat message related to the activity card sent from the activity management module 211 of the management server 101 (step 3410).
Owner asset management module 310 displays the activity card on the chat (step 3420).

The owner asset management module 310 receives a selection of approval, denial, confirmation, etc. for the activity from the owner (step 3440). If the answer is negative (step 3440: Yes), the message input field 2801 is made a required input item, and the owner's message input is accepted (step 3450).
As a result of these inputs, the owner asset management module 310 generates a response screen (response information) for the activity (step 3460), and posts the response screen to the chat between the operator and the owner (step 3470).

FIG. 30 is an example of an activity list screen 3000.
The owner asset management module 310 acquires information on the corresponding activity from the activity management module 211 of the management server 101 based on the narrowing down conditions 3001 for the activity.
The owner asset management module 310 displays the acquired activity information 3003, 3004, and 3005 in a list. Additionally, a total 3002 of current status is displayed.
In this way, by collectively displaying activity information indicating confirmation items for multiple assets managed by the management server 101 on the owner terminal 102, the owner can easily manage multiple assets. .

FIG. 31 is an example of an activity filter screen.
Upon receiving a selection of narrowing conditions 3001 from the owner, the owner asset management module 310 displays an activity filter screen or displays similar information in a pull-down format, thereby receiving the selection of an item from the owner.

FIG. 32 is an example of an asset management screen 3200.
The owner asset management module 310 of the owner terminal 102 collectively displays information regarding a plurality of assets 3203 owned by the owner on the asset management screen 3200.
The owner asset management module 310 aggregates and displays the total present value 3201 of a plurality of assets 3203, 3204, 3205, etc., and asset information 3202 such as cash flow.

Normally, when you have a large number of assets such as real estate, there are multiple asset management companies, and the management methods and confirmation matters such as approvals and confirmations that occur for each asset are different from each other. be notified in disparate ways depending on the asset management company's methods.
According to this embodiment, the management server 101 once receives confirmation items from the asset management company terminal 103 owned by each of a plurality of asset management companies via the platform provided by the management server 101 and integrates them into a fixed format called an activity. Accordingly, notifications will be made in the form of activity cards in the chat with the owner.
By accepting responses to each activity via chat and managing and updating the activity master information 800 and activity detailed information 900 of the management server 101, the management server 101 centrally manages the status of multiple assets owned by the owner. I can do it.

By simply introducing the owner asset management module 310 that operates in conjunction with the activity management module 211 of the management server 101, owners can enjoy centrally managed management rather than having to deal with multiple assets and multiple asset management companies differently. It is possible to manage multiple assets depending on the screen and method.
In addition, approvals and confirmations that occur frequently for multiple assets can be approved and confirmed while interacting with the operator in a real-time inquiry method called chat, making it extremely user-friendly for owners. Good service.

Note that the present invention is not limited to the above-described embodiments, and includes various modifications. For example, the embodiments described above are described in detail to explain the present invention in an easy-to-understand manner, and the present invention is not necessarily limited to having all the configurations described. Furthermore, it is possible to replace a part of the configuration of one embodiment with the configuration of another embodiment, and it is also possible to add the configuration of another embodiment to the configuration of one embodiment. Further, it is possible to add, delete, or replace a part of the configuration of each embodiment with other configurations.

Further, each of the above-mentioned configurations, functions, processing units, processing means, etc. may be partially or entirely realized in hardware by designing, for example, an integrated circuit. Furthermore, each of the above configurations, functions, etc. may be realized by software by a processor interpreting and executing a program for realizing each function. Information such as programs, tables, files, etc. that implement each function can be stored in a memory, a recording device such as a hard disk, an SSD (Solid State Drive), or a recording medium such as an IC card, SD card, or DVD.

Further, the control lines and information lines are shown to be necessary for explanation purposes, and not all control lines and information lines are necessarily shown in the product. In reality, almost all components may be considered to be interconnected.
Note that the above-described embodiments disclose at least the configuration described in the claims.

1... Asset management system, 102... Owner terminal, 103... Asset management company terminal, 211... Activity management module, 212... Data registration management module, 213... Asset registration management module, 310... Owner asset management module, 410... Management company assets management module

Claims (15)

An activity management method using chat executed by a management server, the method comprising:
Accepts selection or input of activities that require confirmation from the real estate property owner,
Accepting the selection of the real estate property ,
obtaining real estate property information regarding the activity of the selected real estate property;
Generate an activity card into which the acquired real estate property information is input,
The activity card is posted to a chat in which messages are exchanged between the owner and the management server , or between a terminal used by an asset management company that manages the real estate property and the management server. How to manage activities. The activity management method according to claim 1, comprising:
memorize a list of activities that require confirmation from the owner;
accept the selection of the activity from the activity list;
An activity management method characterized by. The activity management method according to claim 1 or 2 ,
The real estate property information includes information regarding the amount of money for the real estate property,
An activity management method characterized by inputting information regarding the amount into the activity card. The activity management method according to any one of claims 1 to 3 ,
There are approval and rejection buttons corresponding to the activity card,
An activity management method characterized by receiving a selection of approval or disapproval for the activity from the owner using the button displayed in the chat. The activity management method according to claim 4 ,
If the owner chooses to decline,
An activity management method characterized in that an entry of a reason for denial is accepted, and the reason for denial is posted as a message in the chat. The activity management method according to claim 4 or 5 ,
An activity management method characterized by storing the date and time when the activity was approved or rejected. The activity management method according to any one of claims 4 to 6 ,
Activity management characterized by acquiring information regarding predetermined activities for a plurality of real estate properties owned by the owner, and displaying a list of approval or disapproval status regarding the predetermined activities for the plurality of real estate properties. Method. A management server,
a storage means for storing real estate property information ;
input means that accepts selection or input of an activity that requires confirmation from the owner of a real estate property, and accepts selection of the real estate property;
Acquire real estate property information regarding the activity of the selected real estate property, generate an activity card into which the acquired real estate property information is input, and create an activity card between the owner and the management server or an asset that manages the real estate property. activity management means for posting the activity card in a chat where messages are exchanged between a terminal used by a management company and the management server ;
A management server characterized by having: The management server according to claim 8,
The storage means further stores a list of activities that require confirmation from the owner,
The input means receives the selection of the activity from the activity list.
A management server characterized by. The management server according to claim 8 or 9 ,
The real estate property information includes information regarding the amount of money for the real estate property,
A management server characterized by inputting information regarding the amount into the activity card. The management server according to any one of claims 8 to 10 ,
There are approval and rejection buttons corresponding to the activity card,
The management server is characterized in that the activity management means receives a selection of approval or disapproval for the activity from the owner using the button displayed in the chat. The management server according to claim 11 ,
If the owner chooses to decline,
A management server that accepts entry of a reason for denial, and posts the reason for denial as a message in the chat. The management server according to claim 11 or 12 ,
The management server is characterized in that the storage means stores a date and time when the activity was approved or rejected. The management server according to any one of claims 11 to 13 ,
A management server that acquires information regarding predetermined activities for a plurality of real estate properties owned by the owner, and displays a list of approval or disapproval statuses regarding the predetermined activities for the plurality of properties. A program for causing a management server to execute each step of the activity management method according to any one of claims 1 to 7 .

Images