A whole-process management system for a franchise chain in the retail field
Patent Information
- Application Number
- CN202611068354.9
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-07-17
- Publication Date
- 2026-10-27
AI Technical Summary
然而,将这类通用软件直接套用于零售加盟招商场景时,存在若干不足
该一种用于零售领域的加盟连锁全过程管理系统,通过线索接入模块对来自外部系统推送、人工录入与文件批量导入三类来源的加盟意向线索进行归一化并赋予全局唯一商机标识,配合文件导入逐行校验与失败明细反馈,提高批量接入的容错性与可运维性,将阶段存储编码与展示文案解耦,使界面文案调整独立于底层数据,保障统计与跨系统映射所依赖的存储编码的长期稳定,订阅合同签署完成后,经幂等校验后自动流转赢单并通过异,采用开发口径与加盟口径两套统计方式,使同一业务数据兼顾双线考核需求,且两口径数据源隔离互不影响;团队协同模块按角色分类展示人员信息并在远程获取失败时实施降级超时返回,确保列表稳定渲染不因依赖异常而阻塞,结构化记录铺位编码、打卡位置、周边环境及加盟商反馈,使选址过程具备完整可追溯性,依据用户代理与屏幕宽度自动判别并缓存判定结果,使移动外勤场景获得适配界面,且端间共用接口与状态层降低维护成本,服务端动态下发字段可选值配合预加载与懒加载,高级筛选支持取空值选项及自定义模板保存,丰富数据检索维度,部署为解耦微服务架构,选址中台服务持有核心数据并对外提供原子能力,前台服务仅负责编排聚合且不直接持有数据库,结合服务注册发现、熔断降级与异步消息解耦机制,保障高并发场景下的服务稳定性。
Smart Images

Figure CN122988385A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of enterprise management technology, and in particular to a franchise chain full-process management system for the retail sector. Background Technology
[0002] Existing customer relationship management (CRM) software typically focuses on driving sales opportunities, recording customer information and maintaining a sales funnel. However, directly applying this type of general-purpose software to retail franchise recruitment scenarios has several shortcomings.
[0003] (i) The sources of leads are heterogeneous and the field definitions are inconsistent. Franchise recruitment leads can be entered and synchronized through the enterprise's self-built or externally sourced customer relationship system via interface, or manually entered by recruitment personnel after on-site or telephone communication, or imported in batches from channel activities in tables. The field definitions and value specifications of leads from different sources are inconsistent. If normalization is not performed, multiple fragmented customer views will be formed within the same recruitment team, leading to duplicate follow-ups and duplicate orders.
[0004] (ii) The stage storage value and the display text are too tightly coupled. General CRM usually persists the stage name directly as the storage value. Once the business party requests to adjust the interface display text of a certain stage, the underlying storage of all historical data must be modified. This not only poses a data migration risk, but also destroys the statistical reports and external interface logic that rely on the storage value.
[0005] (iii) Lagging cross-system status synchronization: Contract signing in franchise recruitment is usually completed in an independent electronic signing or legal approval system. If this key event cannot be fed back to the recruitment management side in time, the recruitment personnel need to manually advance the corresponding business opportunity from the signing stage to the winning order, which is both time-delayed and prone to omission. When the company uses this management system and the external customer relationship system at the same time, the status of the two stages is prone to inconsistency, requiring additional manual verification. (iv) The assessment and statistical methods are too simplistic. There are two parallel assessment perspectives in the franchise recruitment business: the development perspective, which is based on developers, and the investment perspective, which is based on investment managers. The two perspectives are naturally different in terms of data sources and ownership rules. The number of signed contracts should not be forced to be consistent. However, general software often only provides a single perspective, which makes it difficult to meet the management needs of both the development and investment lines at the same time.
[0006] To address the aforementioned technical shortcomings, a solution is proposed. Summary of the Invention
[0007] This invention adopts the following technical solution: a franchise chain end-to-end management system for the retail sector, comprising: The lead acquisition module is used to receive franchise intention leads pushed by external systems, entered through the interface, and imported from files. After normalization according to preset field mapping rules, the leads are written into the business opportunity data table, and each lead is assigned a globally unique business opportunity identifier. The opportunity filing and stage transition module is used to build an ordered stage chain for each opportunity in the opportunity data table. Each stage is stored in the data layer with a fixed code, and in the display layer, it is converted into a differentiated display name through the mapping of the coded text to support the differentiated text requirements of multiple regions and multiple brand lines. The service team collaboration module is used to bind multiple roles, including franchise consultant, site selection and development manager, engineering specialist, and operations supervisor, to each business opportunity. The module also collects and displays the names and contact information of the personnel corresponding to each role in the business opportunity list and business opportunity details page, according to role type. The site selection and viewing module is used to record the executed store viewing tasks, including store code, geographical location information of the viewing check-in, identity of the developer who executed the task, surrounding environment information, and franchisee feedback. The contract signing, performance, and status transition module is used to subscribe to contract signing completion messages, associate corresponding business opportunities with the messages, and automatically transition the stage to the winning order after idempotency verification, and trigger the establishment process. The franchise management dashboard module is used to statistically analyze business opportunities and contract signing data by time, region, source, etc., and output conversion rate, viewing-to-sales ratio, contract completion rate, and estimated management fee revenue decision indicators.
[0008] Furthermore, the contract signing, performance, and status transition module also includes the following specific content: After the business opportunity is transferred to the winning stage, the contract signing and status transition module further writes back the stage code corresponding to the winning stage to the same customer in the external customer relationship system based on the pre-established correspondence between the stage value of this system and the stage code of the external customer relationship system, so as to achieve bidirectional consistency of business opportunity stages between this system and the external customer relationship system.
[0009] Furthermore, the contract signing, performance, and status transition module also includes the following specific content: After subscribing to the contract signing completion message, the contract number or business opportunity identifier carried in the message is used as the basis for deduplication and idempotency verification is performed. For duplicate messages with the same business identifier, only one stage flow operation is performed. The phase transition is executed through a unified phase change service in the phase chain management module, which automatically triggers the business verification rules and operation log records attached to the phase change service during the transition.
[0010] Furthermore, when compiling contract data, the business dashboard module outputs the following two sets of data in parallel: Development criteria: The count is based on the contract confirmation time in the stall release record falling within the statistical period, and the contract creator of the record is assigned to the corresponding developer. Franchise criteria: Winning deals are counted based on the current stage of the business opportunity and the contract signing date falling within the statistical period. The number of contracts obtained from the two criteria are displayed separately and the values are not required to be equal.
[0011] Furthermore, the team collaboration module distinguishes between site selection development managers and development specialists by configuring role type codes for each role, and displays personnel names in groups according to role type codes when collecting personnel names; When there are multiple people under the same role type for the same business opportunity, the names of the multiple people will be concatenated with a separator and then displayed. When a business opportunity is missing a certain role, no placeholder or null character is rendered in the corresponding position for that role; When the team collaboration module fails to remotely retrieve role and personnel information, the business opportunity list is returned in a downgraded manner without blocking page rendering, and the corresponding role name position is left empty.
[0012] Furthermore, it also includes a terminal adaptive routing module, which is used to determine the terminal type based on two dimensions: user agent identifier and screen width when a user accesses the business opportunity management page. When either dimension meets the mobile terminal condition, the access is redirected to an independent mobile terminal page route; otherwise, the desktop terminal page route is maintained. Mobile and desktop pages share the same interface and state management layers, differing only in the view rendering layer.
[0013] Furthermore, when writing leads imported in batches from files or manually entered, the lead access module assigns a preset default partnership mode value to leads for which no partnership mode is specified. During normalization, the field name mapping and data type conversion of the clue fields from the three types of sources are performed according to the preset field mapping table, and the integrity of each clue is checked according to the mandatory field validation rules of the target field. For abnormal clues that fail the validation, they are not written to the franchise opportunity data table, but to a separate abnormal clue temporary storage table, and the reason for the abnormality and the source identifier are recorded, which supports the operation personnel to correct and resubmit. The business opportunity identifier in the franchise opportunity data table is a globally unique long integer identifier. When the system's list query interface receives a precise search request based on the business opportunity identifier, the front end transmits the identifier as a string. The server restores the string to a long integer during deserialization and performs a precise matching query on the business opportunity identifier column in the data table based on the equality condition.
[0014] Furthermore, the stage chain management module also includes the following specific features: The stage chain management module maintains a stage chain containing historical stages marked as obsolete. Obsolete stages are uniformly filtered during stage display, stage filtering, and stage advancement operations and are not presented to the terminal. Each stage of the stage chain is configured with stage entry conditions and stage exit conditions; when the current stage of a business opportunity meets the entry conditions for the next stage, the system activates the advancement operation button on the stage advancement interface and displays a list of target stages that can be advanced. When the conditions are not met, the push button is grayed out and a list of unmet conditions is displayed in a floating manner to guide the operator to complete the prerequisite elements.
[0015] Furthermore, the optional values for the fields involved in business opportunity entry and filtering in the system are dynamically issued by the server interface, and the terminal does not have a set of hard-coded optional values. In addition, in the advanced filtering function of the system, a null value option is uniformly provided for the filter fields that take enumerated values. When the user selects this option, the server performs a query on the field as a null condition.
[0016] In summary, due to the adoption of the above technical solution, the beneficial effects of the present invention are: This is a franchise chain end-to-end management system for the retail industry. Through a lead acquisition module, it normalizes franchise intention leads from three sources: external system pushes, manual entry, and batch file import, assigning each lead a globally unique business opportunity identifier. Combined with line-by-line verification and failure details feedback during file import, it improves the fault tolerance and maintainability of batch access. It decouples stage storage coding from display text, making interface text adjustments independent of the underlying data, ensuring the long-term stability of the storage coding upon which statistics and cross-system mapping depend. After the subscription contract is signed, it automatically flows to the winning order after idempotency verification and cross-system verification. It employs two sets of statistical methods, one for development and one for franchisees, allowing the same business data to meet the needs of dual-track assessment, while ensuring that the two data sources are isolated and do not interfere with each other. The team collaboration module displays personnel information categorized by role and remotely retrieves loss information. In case of failure, a degradation timeout return is implemented to ensure stable list rendering without being blocked by dependency exceptions. The structured recording of stall codes, check-in locations, surrounding environment, and franchisee feedback ensures complete traceability of the site selection process. The system automatically judges and caches the judgment results based on user agent and screen width, providing an adapted interface for mobile field service scenarios. The shared interface and state layer between terminals reduce maintenance costs. The server dynamically distributes optional field values in conjunction with preloading and lazy loading. Advanced filtering supports null value options and custom template saving, enriching the dimensions of data retrieval. The deployment is a decoupled microservice architecture. The site selection middleware service holds core data and provides atomic capabilities to the outside world, while the front-end service is only responsible for orchestration and aggregation and does not directly hold the database. Combined with service registration and discovery, circuit breaking and degradation, and asynchronous message decoupling mechanisms, the system ensures service stability in high-concurrency scenarios. Attached Figure Description
[0017] Figure 1A schematic diagram of the overall system structure of the present invention is shown; Figure 2 This diagram illustrates the overall structure of the coupling relationship throughout the entire process of the present invention. Figure 3 The diagram illustrates the three types of source clue flow structure of the present invention; Figure 4 This diagram illustrates the message-driven process structure for signing completion according to the present invention. Figure 5 This diagram illustrates the contract signing data structure for the development and investment channels of this invention. Figure 6 A schematic diagram of the inter-service call relationship flow structure of the present invention is shown. Detailed Implementation
[0018] To further illustrate the technical means and effects of the present invention in achieving its intended purpose, the following detailed description of the specific implementation methods, structures, features, and effects of the present invention, in conjunction with the accompanying drawings and preferred embodiments, is provided below.
[0019] Example 1: like Figure 1-6 As shown, the system provided in this embodiment is deployed in three layers: the front-end application layer, the front-end aggregation layer, and the middle-platform atomic capability layer. The front-end application layer is the investment promotion management backend page running in a browser, which has both desktop and mobile forms. The front-end aggregation layer is a terminal-oriented service that is responsible for aggregating and arranging multiple middle-platform capabilities into the interfaces required by the page. In the middle-platform atomic capability layer, the site selection middle-platform service carries the core data and atomic operations of business opportunities and the entire investment promotion process, and holds the corresponding database. This database contains a business opportunity data table, a franchise master file table, a service team table, a site release table, and a developer table.
[0020] In one specific embodiment, the business opportunity data table is denoted as locasys_customer, which is used to store each business opportunity, i.e., a potential franchisee; the franchise master table is denoted as locasys_customer_main; and the service team table is denoted as locasys_customer_service_team, which is used to store the binding relationship between business opportunities and roles such as investment managers, development managers, and development specialists. The point release table is denoted as locasys_point_release and is used to store information related to point release and contract signing. The developer is designated as locasys_developer. All the above data tables are built in the same business database. It should be noted that this invention does not limit the above table names and database names. Any storage structure that can carry the corresponding data meaning falls within the protection scope of this invention.
[0021] Each business module is decoupled from the others on a service-by-service basis. The front-end service does not directly access the database of the selected middleware service, but obtains its atomic capabilities through remote calls. The call results must be verified for success before they can be used. This decoupling method allows each module to evolve and be deployed independently.
[0022] II. Clue Access Module The lead access module receives leads from three types of sources. The first type is inbound synchronous leads, which come from external customer relationship systems. In one embodiment, the external customer relationship system is the Fenxiang Sales Platform, whose customer data is synchronized into the platform through an interface. The second type is manually entered leads, which are filled in manually by investment promotion personnel in the interface for creating new leads and then submitted. The third type is bulk lead import, where operations staff compile customer information collected from channel activities into a spreadsheet file and then upload it in batches. The three types of leads have different field definitions. The lead access module aligns the fields from different sources to a unified field in the business opportunity data table according to the preset field mapping rules. For example, the fields representing the intended city, contact information, partnership mode, etc. from each source are mapped to a unified field. After normalization, each lead is written into the business opportunity data table and assigned a globally unique business opportunity identifier. In one embodiment, the business opportunity identifier is a globally unique identifier of long integer, generated by a distributed identifier generation method.
[0023] Furthermore, for leads that are imported in batches or entered manually without a clearly specified partnership mode, the lead access module assigns a preset default partnership mode value to them. In one embodiment, the default value is standard franchise, so as to ensure that the newly entered data has a definite partnership mode value in the subsequent process and avoid downstream branch anomalies caused by null values.
[0024] III. Business Opportunity Filing and Phased Transfer Module See Figure 2 This module maintains a stage chain for each business opportunity. In one embodiment, the ordered stages of the stage chain are: lead cleaning, customer interview, attending investment promotion meeting, participating in interview, paying deposit, site selection and viewing, signing lease contract, signing cooperation agreement, followed by winning order, and there are losing orders parallel to it as unsold results, and the last one is the end. Each business opportunity is uniquely in a certain stage of the stage chain at any given time, which is denoted as the current stage. A key design feature of this module is the decoupling of stage-specific stored values and display text. The data layer consistently persists the current stage using the stage-specific stored value, such as the Chinese string "Sign up for cooperation". The display layer maintains a stage-specific text mapping relationship. When outputting to the terminal, the stored value is converted into the display text through mapping. For example, when the business requires that "Sign up for cooperation" be uniformly renamed to "Contract Signing" on the interface, only the mapping from "Sign up for cooperation" to "Contract Signing" needs to be established in the stage-specific text mapping relationship. All display locations, including stage step bars, filter dropdowns, details, and stage values in the list, are rendered using a unified method of retrieving display text and are renamed accordingly. The underlying stored value remains unchanged as "Sign up for cooperation". Since statistics, filtering conditions, and cross-system integration are all based on stored values, renaming the interface will not affect the above logic, and no migration of historical data is required.
[0025] Furthermore, there may be historical stages marked as obsolete in the stage chain, such as franchisee activation, confirmation of needs, acceptance of invitation, and signing of letter of intent that were once used but are now abandoned. This module establishes a unified set of obsolete stages for such obsolete stages, and uses this set to filter in the three aspects of stage display, stage filtering, and stage advancement, so that obsolete stages are no longer displayed, thereby ensuring that the stage classification of the current interface is clean and consistent without deleting historical data. The phased progress can be manually operated by the sales personnel in the phase funnel on the details page, or it can be automatically driven by the contract processing and automatic status flow module described later. Regardless of the triggering method, the phase change is executed through the unified phase change service of this module, so as to trigger business verification and operation record keeping at the same time as the change.
[0026] IV. Service Team Collaboration Module The service team collaboration module binds multiple roles to each business opportunity. In one embodiment, the service team table configures a role type code for each binding record, where the role type code for development specialist is 1, the role type code for development manager is 3, and the role type code for investment manager is the corresponding role type code. In the business opportunity list and business opportunity details, this module groups and collects personnel according to role type code. When multiple personnel are bound to the same business opportunity under the same role type, the names of the multiple personnel are concatenated with a separator and displayed together. When a business opportunity is missing a certain role, such as when a development manager has not been configured, the corresponding position of the role is displayed as empty, instead of outputting a null placeholder character, so as not to mislead users. To ensure the robustness of list queries, when the remote retrieval of role and personnel fails during the process of batch completing the role and personnel names for a whole page of business opportunities in this module, the list query adopts a fallback strategy. The list is still returned normally, but the corresponding role and personnel names are set to empty, so as not to block the display of the entire list due to the failure to retrieve role and personnel.
[0027] V. Site Selection and Viewing Module The site selection process for retail franchises is supported by the site selection and viewing module. When the sales staff goes out to view shops for a specific business opportunity, they create and execute a viewing task in the system. Each viewing record includes the location identifier, the location information when checking in, such as the check-in location, location name, location identifier, latitude and longitude coordinates and check-in time, and further records the name of the developer who executed the viewing task and the feedback content of the viewing. The above records are fully presented on the "Shop Viewing with Customers" tab in the business opportunity details, allowing follow-up personnel to see which locations were visited, when they were checked in, who performed the visit, and what the customer feedback was, thus supporting the continuity of site selection decisions.
[0028] As a further implementation, the site selection and viewing module can also be connected to the similar store matching capability, which can find several of the most similar existing stores from the store profile data for the target location, providing a comparable reference for franchise site selection. The specific matching method of this capability does not constitute a limitation of the present invention.
[0029] VI. Contract Processing and Status Transition Module This module addresses the issue of delayed status progression after contract signing. Contract signing is completed in a separate contract system. When a franchise contract is signed, the contract system sends a message to the message middleware. This module subscribes to this message and receives the contract signing completion event as a consumer. The message carries a business identifier that can be associated with business opportunities in this system, such as the customer identifier corresponding to the contract. After receiving a message, this module first performs idempotency verification based on the service identifier carried in the message for deduplication. In one embodiment, the processed service identifier is recorded. For messages with the same service identifier that arrive repeatedly, subsequent processing is performed only once, thereby avoiding duplicate processing caused by duplicate message delivery. After passing idempotency verification, this module associates the business identifier with the corresponding business opportunity in the business opportunity data table and transfers the current stage of the business opportunity to the winning stage. This transfer is executed through the unified stage change service of the business opportunity filing and stage transfer module to ensure that the transfer process is also subject to business verification constraints and is recorded in the operation log, rather than bypassing the existing business logic to directly rewrite the stored value; Furthermore, in a preferred embodiment, after the local process is completed, this module writes back the stage code corresponding to the winning stage to the same customer in the external customer relationship system based on the pre-established correspondence between the stage values of this system and the stage codes of the external customer relationship system. For example, when the winning stage in the external customer relationship system corresponds to a code, this module writes the code back, so that the stage on the external system side is synchronously updated to the winning stage, realizing bidirectional consistency between the stages on both sides. Thus, no matter whether the user views from this system or the external system, the stage seen is consistent.
[0030] It should be noted that this module's automatic insertion of winning orders replaces the previous approach of setting the process to "end" after signing. Compared to manual processing, this module uses an event-driven approach to complete the process in real time, which is more efficient and less prone to omissions.
[0031] VII. Franchise Operation Dashboard Module The franchise operations dashboard module summarizes business opportunities and related contract data, and outputs key operating indicators to managers, including but not limited to key performance indicator cards, stage funnel distribution, team ranking, distribution of intended cities, and monthly contract trends. In terms of contract data statistics, this module uses two sets of criteria in parallel. The development criterion uses the contract time in the site release record falling within the statistical time interval as the filtering condition, and assigns the contract to the corresponding developer according to the contract creator in the record, thereby obtaining the number of contracts for development line assessment. The investment criterion uses the current stage of the business opportunity as the winning order and its contract date falling within the statistical time interval as the filtering condition, thereby obtaining the number of contracts for investment line assessment. Because the two sets of standards differ in data sources, location release records, business opportunity stages, and attribution rules, the number of contracts signed by the creators and the managers responsible for the business opportunities may not be equal within the same time period. This module outputs the results of the two sets of standards separately without forcing them to be equal, thus serving both development line management and investment line management, avoiding mismatches and misinterpretations caused by a single standard.
[0032] 8. Terminal Adaptive Routing Module As a supplementary embodiment of the present invention, the system also includes a terminal adaptive routing module. When a user accesses a business opportunity management related page, the module makes a judgment based on two dimensions: user agent identifier and screen width. If the user agent identifier contains a mobile terminal identifier, or the screen width is less than a preset threshold, it is determined to be a mobile terminal access and the access is redirected to an independent mobile terminal page route; otherwise, the desktop terminal page route is maintained.
[0033] The mobile and desktop pages share the same interface and state management layers, differing only in the view layer. On mobile devices, the opportunity list is presented in a card format and supports pull-to-refresh and pull-to-load-more. Filtering conditions are collapsed by default and triggered via a drawer pop-up. The opportunity details have been changed from a fixed-width pop-up to a full-screen independent page. This allows sales personnel to smoothly browse, filter, view, and edit core fields of opportunities on mobile devices such as smartphones or vertical-screen tablets.
[0034] IX. Details of Several Supporting Implementation Measures To improve retrieval efficiency, the system's list query interface supports precise retrieval by business opportunity identifier. Since the business opportunity identifier is a globally unique long integer with a large number of digits, transmitting it as a numeric type on the front end might result in precision loss. Therefore, the front end transmits the identifier as a string, and the server restores it to a long integer during deserialization, performing precise matching on the business opportunity identifier column of the business opportunity data table based on equality conditions. If the column lacks an index, an index can be created to ensure query performance. This precise retrieval by identifier and fuzzy retrieval by keyword are mutually exclusive and are controlled by the front end to not be executed simultaneously. Furthermore, the optional values for fields involved in business opportunity entry and filtering in the system are issued by the server-side interface, and the terminal does not have a hard-coded set of optional values, thus ensuring centralized maintenance and cross-platform consistency of the optional value criteria. In advanced filtering, a unified option to retrieve null values is provided for filter fields that take enumerated values; when a user selects this option for a field, the server queries the field based on whether it is null, allowing the user to filter out business opportunities where a certain field is missing.
[0035] 10. Typical Workflow Example The system's overall operation will be explained using a typical process from a potential franchisee's entry to a completed transaction as an example.
[0036] A customer's information is synchronously entered into this system via an external customer relationship system. The lead acquisition module normalizes it and writes it into the opportunity data table, assigning a globally unique opportunity identifier. The initial stage is lead cleaning. The recruitment team assigns a service team to this opportunity, binding an investment manager, a development manager, and a development specialist. Recruitment personnel follow up through phone calls and face-to-face meetings, advancing the stages sequentially to customer face-to-face meetings, attendance at recruitment meetings, and interviews. After the customer pays an intention deposit, the stage enters the intention deposit payment stage. Subsequently, the development personnel take the customer to view the store, recording the store viewing task in the system, including the location, check-in location, and feedback from the executor. The stage enters the site selection stage. After the customer selects a location and signs a lease agreement, the stage enters the lease agreement signing stage. Finally, the franchise agreement is signed in the contract system, and the contract system sends a signing completion message. The contract processing and status auto-flow module subscribes to this message, and after idempotency verification, the opportunity is automatically transferred to the winning order stage, and the stage code corresponding to the winning order is written back to the external customer relationship system. Throughout the process, the business dashboard module includes the signing in statistics according to the development and investment perspectives, allowing managers to monitor the recruitment progress in real time.
[0037] In the above process, the page-facing interface is aggregated and orchestrated by the front-end service, while core data such as business opportunity data, service team, location release and customer viewing records are managed and held in the database by the site selection middle platform service. The front-end service obtains the atomic capabilities of the site selection middle platform service through remote calls, and the two databases are independent of each other.
[0038] The size of the interval and threshold is set to facilitate comparison. The size of the threshold depends on the amount of sample data and the number of bases set by those skilled in the art for each set of sample data; as long as it does not affect the ratio between the parameter and the quantized value.
[0039] The above formulas are all dimensionless calculations. The formulas are derived from software simulations based on a large amount of collected data to obtain the most recent real-world results. The preset parameters in the formulas are set by those skilled in the art according to the actual situation. In the two embodiments provided in this application, it should be understood that the disclosed apparatus and system can be implemented in other ways; for example, the apparatus embodiments described above are merely illustrative, and the division of modules is merely a logical functional division. In actual implementation, there may be other division methods, such as multiple modules or components can be combined or integrated into another system, or some features can be ignored or not executed; furthermore, the coupling or direct coupling or communication connection between the shown or discussed mutuals can be through some interfaces, and the indirect coupling or communication connection between the apparatus or modules can be electrical, mechanical or other forms. The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention in any way. Although the present invention has been disclosed above with reference to preferred embodiments, it is not intended to limit the present invention. Any person skilled in the art can make some modifications or alterations to the above-disclosed technical content to create equivalent embodiments without departing from the scope of the present invention. Any simple modifications, equivalent changes and alterations made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention shall still fall within the scope of the present invention.
Claims
1. A franchise chain end-to-end management system for the retail sector, characterized in that, include: The lead acquisition module is used to receive franchise intention leads pushed by external systems, entered through the interface, and imported from files. After normalization according to preset field mapping rules, the leads are written into the business opportunity data table, and each lead is assigned a globally unique business opportunity identifier. The opportunity filing and stage transition module is used to build an ordered stage chain for each opportunity in the opportunity data table. Each stage is stored in the data layer with a fixed code, and in the display layer, it is converted into a differentiated display name through the mapping of the coded text to support the differentiated text requirements of multiple regions and multiple brand lines. The service team collaboration module is used to bind multiple roles, including franchise consultant, site selection and development manager, engineering specialist, and operations supervisor, to each business opportunity. The module also collects and displays the names and contact information of the personnel corresponding to each role in the business opportunity list and business opportunity details page, according to role type. The site selection and viewing module is used to record the executed store viewing tasks, including store code, geographical location information of the viewing check-in, identity of the developer who executed the task, surrounding environment information, and franchisee feedback. The contract signing, performance, and status transition module is used to subscribe to contract signing completion messages, associate corresponding business opportunities with the messages, and automatically transition the stage to the winning order after idempotency verification, and trigger the establishment process. The franchise management dashboard module is used to statistically analyze business opportunities and contract signing data by time, region, source, etc., and output conversion rate, viewing-to-sales ratio, contract completion rate, and estimated management fee revenue decision indicators.
2. The franchise chain end-to-end management system for the retail sector according to claim 1, characterized in that, The contract signing, performance, and status transition module also includes the following specific components: After the business opportunity is transferred to the winning stage, the contract signing and status transition module further writes back the stage code corresponding to the winning stage to the same customer in the external customer relationship system based on the pre-established correspondence between the stage value of this system and the stage code of the external customer relationship system, so as to achieve bidirectional consistency of business opportunity stages between this system and the external customer relationship system.
3. The franchise chain full-process management system for the retail sector according to claim 1, characterized in that, The contract signing, performance, and status transition module also includes the following specific components: After subscribing to the contract signing completion message, the contract number or business opportunity identifier carried in the message is used as the basis for deduplication to perform the idempotency check. For duplicate messages with the same business identifier, only one stage flow operation is performed. The phase transition is executed through a unified phase change service in the phase chain management module, which automatically triggers the business verification rules and operation log records attached to the phase change service during the transition.
4. A franchise chain end-to-end management system for the retail sector according to claim 1, characterized in that, When compiling contract data, the business dashboard module outputs the following two sets of data in parallel: Development criteria: The count is based on the contract confirmation time in the stall release record falling within the statistical period and the contract creator of the record being assigned to the corresponding developer; Franchise criteria: Winning deals are counted based on the current stage of the business opportunity and the contract signing date falling within the statistical period. The number of contracts obtained from the two criteria are displayed separately and the values are not required to be equal.
5. A franchise chain end-to-end management system for the retail sector according to claim 1, characterized in that, The team collaboration module distinguishes between site selection development managers and development specialists by configuring role type codes for each role, and displays personnel names in groups according to the role type codes when collecting personnel names. When there are multiple people under the same role type for the same business opportunity, the names of the multiple people will be concatenated with a separator and then displayed. When a business opportunity is missing a certain role, no placeholder or null character is rendered in the corresponding position for that role; When the team collaboration module fails to remotely retrieve role and personnel information, the business opportunity list is returned in a downgraded manner without blocking page rendering, and the corresponding role name position is left empty.
6. A franchise chain end-to-end management system for the retail sector according to claim 1, characterized in that, It also includes a terminal adaptive routing module, which determines the terminal type based on two dimensions: user agent identifier and screen width when a user accesses the business opportunity management page. If either dimension meets the mobile terminal condition, the access is redirected to an independent mobile terminal page route; otherwise, the desktop terminal page route is maintained. Mobile and desktop pages share the same interface and state management layers, differing only in the view rendering layer.
7. A franchise chain end-to-end management system for the retail sector, characterized in that, When writing leads imported in batches from files or manually entered, the lead access module assigns a preset default partnership mode value to leads for which no partnership mode is specified. During normalization, the field name mapping and data type conversion of the clue fields from the three types of sources are performed according to the preset field mapping table, and the integrity of each clue is checked according to the mandatory field validation rules of the target field. For abnormal clues that fail the validation, they are not written to the franchise opportunity data table, but to a separate abnormal clue temporary storage table, and the reason for the abnormality and the source identifier are recorded, which supports the operation personnel to correct and resubmit. The business opportunity identifier in the franchise opportunity data table is a globally unique long integer identifier. When the system's list query interface receives a precise search request based on a business opportunity identifier, the front end transmits the identifier as a string. The server then deserializes the string into a long integer and performs a precise matching query on the business opportunity identifier column in the data table based on the equality condition.
8. A franchise chain end-to-end management system for the retail sector, characterized in that, The stage chain management module also includes the following specific components: The stage chain management module maintains a stage chain containing historical stages marked as obsolete. These obsolete stages are uniformly filtered during stage display, stage filtering, and stage advancement operations and are not presented to the terminal. Each stage of the stage chain is configured with stage entry conditions and stage exit conditions; When the current stage of a business opportunity meets the entry conditions for the next stage, the system activates the advancement operation button on the stage advancement interface and displays a list of target stages that can be advanced. When the conditions are not met, the push button is grayed out and a list of unmet conditions is displayed in a floating manner to guide the operator to complete the prerequisite elements.
9. A franchise chain end-to-end management system for the retail sector, characterized in that, In the system, the optional values for the fields involved in business opportunity entry and filtering are dynamically issued by the server interface, and the terminal does not have a set of hard-coded optional values. Furthermore, in the advanced filtering function of the system, a null value option is uniformly provided for the filtering fields that take enumerated values. When the user selects this option, the server performs a query on the field as a null condition.
