The One-Person COO System: How Traditional Businesses Can Apply LLMs to Improve Efficiency

This guide is for developers and small teams already operating offline or labor-intensive businesses. You should have a reasonable amount of business information, such as property listings, frequently asked questions, or product manuals, and understand the basic advertising and personal data requirements in your region. The approach below is most useful when both conditions are met.

1. Where Large Language Models Fit in Traditional Businesses

Traditional business processes are often repetitive and relatively structured. Real estate agents, for example, may write property descriptions, answer similar buyer questions, and send similar follow-up messages to different customers every day.

These tasks share several characteristics: their content structure is stable, and the underlying knowledge does not change frequently. This makes them good candidates for organization into a knowledge base and batch processing with a large language model.

However, an LLM does not create sales automatically. It only turns existing business knowledge into text and responses more efficiently. If the property data is inaccurate or customer records are disorganized, the model’s output will also be unreliable. For this reason, the first step is usually data organization—not model selection.

2. The Three Modules of a One-Person COO System

You can think of this system as giving a small street-side lemonade stand an automatic juicer, a digital cash register, and an assistant that answers the phone. The business owner remains responsible for judgment and decisions, while the system takes over repetitive work.

The three modules are described below.

2.1 Content Production

The core principle is to manage prompts like code.

Each template should include:

• A role definition
• Task instructions
• A list of prohibited terms
• An output format
• A version number

Every change should record why it was made and how the result changed before and after the update. This makes it easier to roll back when necessary.

For few-shot prompting, use five to ten high-quality examples that have been reviewed by a person. The examples should cover different property types, such as school-district homes, commercial properties, and long-term rental apartments. If all examples use the same sentence structure, the model will tend to produce only one style.

Output review should have two layers:

1. Rule-based filtering: Check prohibited terms and verify that key fields—such as price, area, and school district—match the original data.
2. Human sampling: People should review a sample of the output. Any content involving prices or promises must be approved manually before publication.

A/B testing can be used to compare performance. Prepare two versions of the copy for the same property and compare metrics such as click-through rate or inquiry rate. When the sample size is small, differences may be caused by random variation, so avoid drawing conclusions too quickly.

When calling the API, set a timeout and use exponential backoff for retries. Also set a maximum retry count. If the response does not conform to the expected JSON format, generate it again once. If it still fails, route the task to a human for handling.

To control costs, set a daily usage budget and alert threshold. Use a smaller model for short copy, and cache repeated requests whenever possible.

2.2 Intelligent Customer Support and Q&A

This module uses a retrieval-augmented generation (RAG) architecture. The basic workflow is to retrieve relevant information first and then generate a response.

Several key configuration choices require attention.

Vector database selection

Choose a vector database based on data volume, latency requirements, and operational cost. If the knowledge base contains only a few thousand entries, a lightweight local vector database may be sufficient. You can also use vector extensions provided by an existing database.

For larger datasets or higher concurrency, a managed vector retrieval service may be appropriate, such as the vector retrieval engine provided by Baidu AI Cloud or a comparable service. Regardless of the product, confirm that it supports metadata filtering, because access control depends on this capability.

Embedding models

Choose an embedding model with strong support for Chinese if your source materials and customer questions are in Chinese. Do not rely only on public benchmarks. Test several models with a small set of real user questions and compare their retrieval performance.

Chunking strategy

Use question-and-answer pairs or complete paragraphs as the basic unit. Each chunk can be approximately 300 to 500 Chinese characters, with a small overlap between adjacent chunks to prevent sentences from being cut off.

Each text chunk should include metadata such as:

• Title
• Last updated time
• Applicable region

This metadata supports filtering later in the retrieval process.

Retrieval evaluation

Prepare approximately 100 real customer questions and label the expected answers. Measure the hit rate at Top-K.

If the hit rate is low, first adjust the chunking strategy and metadata. Only then consider replacing the embedding model.

Access control

Access control must be enforced during retrieval. Customers should be able to retrieve only public information. Internal commission rules, unpublished prices, and customer privacy data should be accessible only to authorized internal roles.

This must be implemented through metadata filtering during retrieval. It is not sufficient to place an instruction such as “do not disclose this information” in the prompt, because the model is not fully reliable for access control.

Privacy protection

Anonymize data before writing it to the knowledge base. Remove phone numbers, government ID numbers, and detailed addresses. Logs must be anonymized as well.

When the knowledge base does not contain supporting information, the system should transfer the question to a human instead of allowing the model to guess.

2.3 Customer Outreach

This module carries the highest risk because it interacts directly with external users.

First, send email only to people who have explicitly consented to receive messages or who have an existing lawful business relationship with you. Do not purchase arbitrary mailing lists.

Second, every email must include a one-click unsubscribe option. Once an unsubscribe request is received, remove the recipient from the mailing list immediately.

Third, configure authentication records such as SPF and DKIM for the sending domain. Control the sending rate and continuously monitor bounce and complaint rates. If the bounce rate remains high, pause sending and investigate the quality of the list.

Fourth, set contact-frequency limits. For example, contact the same customer no more than once per week and maintain a cooling-off period between messages to avoid harassment.

Fifth, personalized content may be generated only from behavioral data that was collected with appropriate authorization. The model must not invent a customer’s experiences, interests, or needs.

The overall process must comply with the personal data protection and advertising requirements of the applicable region.

3. Content Safety and Advertising Compliance

The greatest risk in using AI to generate advertising at scale is false or exaggerated content. The system should include one control point during generation and another before publication.

During generation, a compliance review model can perform a second pass over the copy. At a minimum, the filtering rules should cover three categories:

• Absolute claims, such as “the best” or “number one”
• Unverified promises of results or benefits
• Fabricated transaction data or customer testimonials

Advertising laws in many jurisdictions restrict absolute claims and misleading statements. In China, for example, the Advertising Law places clear restrictions on absolute wording. Such copy should not be published directly.

Before publication, retain a manual approval step. Model-based review has limitations, and missed violations cannot be eliminated completely. Human review remains the final safeguard.

4. Pre-Launch Checklist

Before launch, verify each of the following items:

• Data compliance: The source of every document is traceable, and the necessary usage rights have been obtained.
• Human review: Content involving prices, promises, or legal issues must be approved by a person.
• Performance evaluation: Record baseline metrics before launch, such as inquiry volume, conversion rate, and time spent on manual processing. Review and compare the metrics every week after launch.
• Cost monitoring: Set budget limits and alerts to prevent uncontrolled API usage.
• Rollback plan: Keep the previous prompt version and snapshots of the knowledge base so you can quickly switch back if problems occur.

5. Conclusion

Large language models can reduce the cost of repetitive work in traditional businesses. They are particularly useful for content production, frequently asked questions, and standardized customer follow-up.

Their value comes from making existing business knowledge easier and more efficient to use.

The upper limit of performance depends on three factors: whether the underlying business is sound, whether the data is clean, and whether the team can continuously operate and improve the system. Technology can shorten the time from an idea to execution, but it cannot replace judgment about customers or compliance.

Building a system that is stable and compliant is more important than maximizing short-term output.