Reflection of SMS System Refactoring Project
Introduction
Project refactoring is a very time-consuming and labor-intensive thing. Project refactoring is more difficult than starting a new project. To make changes based on the previous system, you must first have a sufficient understanding of the previous system and a clear idea of the revision process.
In the past month, I took over my first refactoring project. Although the project was small, I still experienced ups and downs that I never experienced when I took over the new project. project.
1. Project background
Our company is a large-scale home appliance company. Two years ago, developers directly built their own SMS system system.
With the development of the business, the original SMS system cannot support the current business development in terms of features and processes. Therefore, the SMS system needs to be reconstructed.
2. Business research
1. Original business analysis
When the original SMS system was built, our company did not have a dedicated product manager, it was completely developed by developers, and no CRM system was built, and the user data of each system was not connected.
In this case, the SMS business process is as follows:
After interviews with actual business personnel, there are the following questions:
- The content of text messages and the audience cannot be reused (the original system does not support copying).
- The granularity of customer screening is too large and there is a lack of appropriate tags for filtering.
- It is difficult to support the precise SMS marketing required in large-scale events, and the same user may receive multiple similar campaign messages on the same day.
- There is no data after sending, so it is difficult to evaluate the effect of SMS.
3. Problem solving ideas
- Realize the reuse of text messages and the audience. (high priority)
- Realize the association between CRM system and SMS promotion system. (high priority)
- Develop rules for customers to receive SMS messages. (low priority)
- Building a database and formulate a data interface to reflect the effect of SMS receipts. (middle priority)
3. Refactoring goals
By modifying the overall business process to realize multiple reuse of content, and by calling CRM user data service to assist the accurate sending of SMS messages, collect relevant data and help business personnel analyze the sending effect.
4. Business process optimization
The SMS business mainly involves only operations and operation supervisors; its business is relatively simple. In the project reconstruction, in addition to the business process of the SMS platform itself, it is also necessary to consider the process of calling the SMS service in the CRM system.
The final business process is as follows:
5. Confirm data
The main data for the SMS system are:
- Customer data;
- Phone number data;
- Data returned by the SMS operator
Customer data: customer data comes from the refactored CRM system. The crowd filtering dimension depends on the previous customer purchase records and the tag management of subsequent operation staff, and directly classifies customers by grouping and crowd; then call CRM system service directly in SMS system.
Phone number data: considering that the SMS system will be opened to the sales company later, our sales company and stores retain some customer data (confidential to the headquarters); Therefore, in addition to the customer number directly obtained from the CRM system, some data will be imported from the system.
Data returned by the SMS operator: in the whole SMS sending business, the only data we can get from the operator is the number of successful SMS sending and the number of failed SMS sending. We can't get the sending status of each number.
On the whole, the data that can be returned from SMS operators is limited, so more data collection methods need to be added in the later feature design.
6. Feature framework design
Combined with business processes and interviews with participants, the whole system can be divided into four modules: SMS management, statistical analysis, setting and account management.
In addition to taking into account the future feature expansion, it is also necessary to consider the actual data situation.
- SMS management: In order to expand the feature of the system in the future (our company intends to provide the third-party platform product), the SMS is divided into three parts: SMS signature, SMS template, and SMS sending. All SMS sending is ultimately performed by sending tasks.
- Settings: it mainly considers the sending setting and list management. Other features need to be expanded after in-depth cooperation with SMS operators.
- Statistical analysis: In fact, it is to reflect the effect of SMS push. The general direction of the analysis is from large particles - overall receipt effect to small particles - phone number analysis, but at this stage, our company has not been able to obtain the receipt status of SMS for each number.
7. Information architecture design
In terms of information architecture, more consideration is given to functional expansion during subsequent project iterations and subsequent integration into large-scale DSP platforms. After combining the feature framework, the information architecture is as follows:
8. Data modeling
The core data entities in the original SMS system are SMS and customers, and the corresponding relationship is many-to-many, while the main data entities in the optimized SMS system are releasing tasks, SMS templates, SMS signatures, groups and customers.
9. Project detail design
1. Status Design
In the process of publishing, the switching involving multiple statuses needs to be defined in advance for each status and the switching conditions between statuses.
2. Key process design
- SMS template: the carrier of SMS content;
- Sending task: The execution unit of SMS sending.
- Due to the restrictions of operators, the content of SMS shall not contain sensitive words, and the input of sensitive words needs to be shielded during editing.
- There are often URL links in the text messages, and the URL links will occupy more text messages. In order to reduce the number of text messages occupied, it needs to be converted into short links.
When sending, you need to consider whether to increase the test sending, and whether the test sending needs approval. If the approval is skipped, the content of the SMS may be uncontrollable.
3. Page design
There are not many pages involved in the system, and only the sending task pages is most important.
4. Authority design
10. Summary
This project took more than 1 month in total, and it is relatively simple in general, but this is the first refactoring project I took over, and I still encountered some problems that I did not expect.
1. No documentation
As I mentioned earlier, the company did not have a dedicated product manager when the original system was developed, and the system was completely designed and developed by 3 developers. During the refactoring, among the original three developers, one of the back-end developers left without any development documentation, so the logic in the old system needs to be sorted out first.
In some business processes, you can use the sorting out process, but many hidden features are not easy to find, and even the original development may not remember.
For example, the original SMS content sensitive word reminder and the number of SMS messages sent are shown only when the SMS message is sent; The invitation code can also be added to the original system, and the invitation code can be written off on the app, etc.
2. User habits
Although the previous system features are not enough to support our business, it has been running for two years and the operation is very simple; while the refactored product has added many new features, but the operation is much more complicated than the original system.
In particular, our sales companies, agents, and store staff have different levels of computer operation, and there are still many follow-up problems that need to be solved after the new system is launched.
Users will have great expectations for the refactored system, and users will not want tool products to only play the role of tools. What they actually want is a set of solutions.
3. What to do and what not to do after refactoring
The original system refactoring is because the features cannot support the expansion of our SMS needs, so the new features are necessary; In the research stage, after referring to many text messaging systems and communicating with business personnel, there will be a pile of features and requirements in pools. At this time, we must distinguish what is needed by the system.
Moreover, the depth of cooperation between the company and SMS operators must be considered, and the features of competitive products cannot be copied.
For example, many SMS systems have phone number blacklist management, but our company can't get the data of each number sending, so although the blacklist feature is necessary, it can only be considered later.
If you like the article, please share it with others with page link, thanks for your supporting! ❤
Leave a comment