Injoys
Key Takeaways
Matching platforms that connect people—such as those for pet sitting, tutoring, interior design, cleaning, lessons, and caregiving—cannot operate based on features alone. While features like booking, payment, profiles, chat, and reviews can be quickly built using AI, it is not code but policies that safeguard the platform’s revenue and trust.
In particular, most of a matching platform’s revenue comes from transaction fees. If providers and users meet for the first time through the platform, then exchange external contact information and begin dealing directly, the platform ends up bearing only customer acquisition and operating costs while losing revenue. Therefore, before launching, you must first establish the marketplace’s rules and translate those rules into functional requirements to be communicated to the AI and development teams.
Why Are Matching Platforms Different from Regular Websites?
The Structure of a Two-Sided Market
A matching platform is not a service that needs to satisfy only one side. Both demanders and suppliers are customers.
| Category | Example | Problem the Platform Must Solve |
|---|---|---|
| Demand Side | Caregivers, parents, landlords, customers | Want to easily find trustworthy people and be protected if problems arise |
| Supply Side | Pet sitters, tutors, contractors, freelancers | Want to receive a steady stream of requests and be protected from cancellations or problematic customers |
| Platform | Marketplace operator | Must facilitate transactions, collect fees, and manage dispute resolution costs |
In this structure, there are many instances where rules take precedence over features. For example, the feature “display a list of sitters” is simple, but deciding who to show first is central to the business. Whether to feature sitters with high response rates and good reviews, give new sitters a chance, or include sponsored listings—these decisions shape the marketplace’s credibility and revenue model.
3 Ways Platforms That Focus Only on Features Fail
1. Without a display order, good service providers leave
If providers are displayed solely in the order they were registered, those who work hard are treated the same as inactive accounts. A sitter with a 4.9-star rating, 47 reviews, and a fast response rate might be pushed down the list, while an account with no reviews could appear at the top.
Under this structure, providers have little incentive to build up good reviews or respond quickly. Customers also become suspicious, wondering, “Why is this person shown first?” The display policy simultaneously influences search quality, provider motivation, and customer trust.
2. Revealing Contact Information Too Early Leads to Commission Losses
When chat is unrestricted and contact information is revealed before payment, conversations like “It’ll be cheaper if we contact each other directly instead of using the app” easily arise. In such cases, the platform bears the costs of discovery, recommendations, trust-building, and customer support but fails to generate actual revenue.
Direct transactions don’t just result in a simple loss of commission. When transactions occur outside the platform, it becomes difficult for the platform to verify or mediate issues such as refunds, safety incidents, no-shows, and service quality problems. Ultimately, both customers and service providers end up outside the platform’s protective framework.
3. Without a Cancellation Policy, One Party Suffers Unilateral Losses
If full refunds are granted even for same-day cancellations, service providers may be left without compensation after setting aside an entire day for the booking. Conversely, if a service provider cancels suddenly without any penalty, the customer’s important plans could be ruined.
A cancellation policy strikes a balance between customer-friendliness and provider protection. Without clear standards, operators must make emotional judgments on a case-by-case basis, leading to inconsistent outcomes for similar incidents and sparking controversy over unfair treatment.
5 Essential Policies to Set Before Launch
1. Listing Order: Who Appears at the Top?
Listing order is the platform’s reward system. You must first determine which actions will result in a top listing.
Recommended Criteria
- Recent response rate
- Average response time
- Review rating
- Number of reviews
- Date of most recent activity
- Booking completion rate
- Cancellation rate
- History of reports or disputes
- Whether the provider is new
Sample Policy
| Factor | Sample Policy | Intent |
|---|---|---|
| Response Rate | Bonus points for a high response rate to inquiries over the last 30 days | Encourage customers to receive answers quickly |
| Rating | Bonus points for a high rating based on a minimum number of reviews | Reflect verified quality at the top |
| Recent Activity | Bonus points for recent logins or schedule updates | Prevent inactive accounts from being displayed |
| Cancellation Rate | Penalty points for a high number of cancellations attributable to the provider | Deter irresponsible providers |
| New Providers | Display new providers without reviews in a separate section | Provide initial opportunities to new entrants |
Key Principles
Even if you do not disclose the full ranking criteria, it is advisable to explain the key factors on the screen. For example, stating, “The recommendation order is determined by a combination of response rate, reviews, recent activity, and booking completion rate,” helps providers understand what actions they should take.
2. Matching Method: Automatic Assignment vs. Application and Selection
The matching method determines the customer experience and accountability structure.
| Method | Description | Advantages | Disadvantages | Suitable Services |
|---|---|---|---|---|
| Automatic Assignment | The platform immediately connects customers with providers who meet the criteria | Fast and simple | Complaints are concentrated on the platform | Emergency calls, simple tasks, standardized services |
| Application and Selection | The customer posts a request; providers apply, and the customer makes the final selection | Facilitates trust-building and distributes selection responsibility | Takes more time | Pet sitting, childcare, tutoring, interior design consultations |
| Hybrid | The platform automatically displays recommended candidates, but the customer makes the final choice | Balances speed and trust | Complex policy design | Most early-stage matching platforms |
For services where trust is critical, the “Application and Selection” method is advantageous. When guardians or parents can directly compare profiles, reviews, work history, availability, and pricing to make their own choice, it provides greater peace of mind. On the other hand, while automatic assignment is faster, it can lead to increased complaints that “the platform made the wrong assignment” if the result is unsatisfactory.
3. Cancellation Policy: When and How Much Is Refunded
The cancellation policy must be displayed and agreed to before payment is made. If customers only learn about refund restrictions after payment, the likelihood of disputes increases.
Example Cancellation and Refund Criteria
| Cancellation Timing | Example Customer Refund | Example Provider Compensation | Operational Intent |
|---|---|---|---|
| Up to 3 days before the service | 100% refund | None | Allow customers flexible changes |
| Up to 1 day before the service | 50% refund | Partial compensation | Compensate the provider for schedule losses |
| Same-day cancellation | No refund or limited refund | Fixed percentage compensation | To deter no-shows and last-minute cancellations |
| Cancellation due to provider fault | Full refund to customer | Penalty points deducted from provider’s rating | To protect customers and prevent irresponsible cancellations |
The figures above are examples; actual rates should be determined based on the nature of the service, local regulations, payment processor policies, and customer expectations.
Provider Cancellation Penalties
Imposing unconditional financial penalties on providers can create legal and operational burdens. In the early stages, the following non-monetary penalties may be more practical:
- Reduction in recommendation score
- Exclusion from top search results for a set period
- Restrictions on new bookings for repeat cancellations
- Consideration of automatically providing apology coupons to customers
- Account warning or suspension following review by the operator
4. Commission Rates and Preventing Direct Transactions: Focus on Designing Protective Measures Rather Than Simply Blocking Them
Commission rates vary depending on the business model. For example, the choice between 10%, 15%, or 20% should be determined by considering customer acquisition costs, payment processing fees, customer support costs, insurance or guarantee costs, and the provider’s margin.
The real issue is not the commission rate itself, but direct transactions. Preventing direct transactions is not simply a matter of hiding phone numbers; it involves creating a structure that makes it clear that “transacting within the platform is safer and more advantageous.”
Required Features and Policies
| Item | Policy Example | Purpose |
|---|---|---|
| Contact Information Privacy | Hide phone numbers, email addresses, and messenger IDs until payment is confirmed | Reduce pre-payment drop-offs |
| Chat Detection | Detect patterns of phone numbers, bank account numbers, and external messenger IDs | Warn users of attempts at direct transactions |
| Warning Message | Notice stating, “External transactions are not eligible for refunds or dispute resolution protection” | Emphasizing the benefits of protection over punishment |
| Sanctions for Repeated Violations | Restricting visibility or reviewing accounts for repeated circumvention of contact information sharing | Maintaining marketplace order |
| Benefits of Platform Payments | Provides refund policies, dispute mediation, transaction history, and settlement protection | Explains the rationale for using the platform’s internal payment system |
Example Warning Message
“For your safety, sharing contact information and bank account numbers before payment is restricted. If you transact outside the platform, you will not be eligible for refunds, dispute arbitration, or transaction record protection.”
The key message of this statement is not “Don’t do it,” but rather “You must pay within the app to be protected.” The temptation to engage in direct transactions will decrease only when buyers and sellers understand the benefits of platform-based transactions.
5. Disputes and Settlement: When to Release Funds
The real power of dispute resolution stems from the settlement structure. If the full payment amount is released to the service provider immediately upon completion of the service, it becomes difficult for the platform to issue a full or partial refund when a problem arises.
Therefore, many matching platforms have a structure in place to hold funds or withhold payment for a certain period after payment is made. While this is often described as a concept similar to escrow, you must check the payment processor’s terms and conditions as well as local financial and e-commerce regulations to determine which methods are actually feasible.
Example Settlement Policy
| Stage | Process | Operational Purpose |
|---|---|---|
| Reservation Payment | Customer makes payment on the platform | Secure transaction records |
| Service in Progress | Customer leaves chat messages, schedule details, and requests on the platform | Secure evidence for disputes |
| Service Completed | Status changed to “Completed” | Settlement pending begins |
| 48 Hours After Completion | Dispute resolution period | Acceptance of incident reports and complaints |
| No Dispute | Settlement to provider | Normal transaction concluded |
| Dispute Filed | Settlement held pending review of evidence | Decision on refund, partial refund, or dismissal |
The 48-hour period is an example. Depending on the nature of the service, this may vary to 24 hours, 72 hours, 7 days, etc. Services where issues may be discovered later—such as pet care or interior design—may require a longer review period.
Dispute Data That Must Be Available on the Administrator Dashboard
To handle disputes properly, administrators must be able to view the full context of a case on a single screen.
| Data | Reason for Inclusion |
|---|---|
| Reservation Information | Verify date, amount, and scope of service |
| Payment and Settlement Status | Verify refundable amount and whether payment is on hold |
| Chat History | Verify appointment details and whether prior notice was given |
| Photographic or File Evidence | Verify incidents, defects, or work results |
| Cancellation/Change History | Verify who requested the schedule change |
| Previous Dispute History | Verify whether the account has a history of recurring issues |
| Reasons for Moderator Decisions | Used as a benchmark for similar future cases |
It is crucial to document the reasons behind moderator decisions. Recording why a full refund was issued, why a partial refund was issued, or why the supplier was deemed at fault helps establish consistent operational standards.
Policy Requirements to Include in AI Development Prompts
If you simply instruct the AI to “create booking, payment, and chat features,” there is a high likelihood that the marketplace’s core rules will be omitted. You must specify the policies as shown below.
Prompt Example
Create a pet sitter matching platform. Do not simply implement basic features; design the system to reflect the operational policies below.
1. The sitter list should be sorted by default based on a combination of response rate, review rating, number of reviews, date of last activity, and booking completion rate.
2. New sitters should be featured in a separate “New Sitters” section to prevent them from being completely buried due to a lack of reviews.
3. Matching works as follows: a pet owner posts a request, sitters apply, and the pet owner selects a sitter after reviewing their profile and reviews.
4. Cancellation and refund policies must be displayed on the screen before payment, and the user’s consent must be obtained.
5. Before payment, restrict the sharing of phone numbers, email addresses, bank account numbers, and external messenger IDs.
6. If patterns resembling contact information or bank account numbers are detected in chat, display a warning message about direct transactions.
7. Hold settlement for 48 hours after service completion; if a dispute is filed during this period, suspend settlement.
8. The operator must be able to view reservation information, payment status, chat history, supporting documents, and the reason for the decision all on a single screen.
Before implementation, please ask me first if there are any policies I haven’t specified that require a decision.
The last sentence is important. By designing the AI to ask about missing policies, the final product will be closer to a fully operational platform rather than just a collection of screens.
Thinking in Terms of a Data Model
Policies must ultimately be represented as data. The items below represent a structure that can be implemented as basic tables and status values even in web frameworks like Ruby on Rails.
| Domain | Example Required Data |
|---|---|
| User | Role, identity verification status, contact information disclosure status |
| Provider Profile | Experience, service area, price, availability, introduction, verification status |
| Visibility Score | Response rate, rating, number of reviews, last activity date, cancellation rate, penalty history |
| Request | Customer request details, preferred schedule, budget, location, status |
| Proposal | Service provider’s proposal message, quoted price, available times |
| Reservation | Selected service provider, schedule, amount, cancellation deadline, completion status |
| Payment | Payment status, refund status, platform fees, amount scheduled for settlement |
| Chat | Messages, attachments, contact information detection, warning history |
| Dispute | Reason, Supporting Evidence, Submission Time, Whether Settlement Is Pending, Decision Result |
| Settlement | Pending Settlement, On Hold, Payment Complete, Failed, Retry Status |
With this design, operational policies aren’t scattered throughout the code but are managed through statuses and records.
Pre-Launch Checklist
- Have you established default sorting criteria?
- Is there a way to provide exposure opportunities for new suppliers?
- Have you decided on the matching method: automatic matching, assisted selection, or a hybrid model?
- Have you distinguished between customer cancellations and supplier cancellations?
- Are refund rates and timing disclosed before payment?
- Is sharing contact information and bank account numbers restricted before payment?
- Do the warnings about direct transactions prioritize explaining the benefits of protection over penalties?
- Are the platform’s commission rates and settlement calculation formulas clear?
- Is there a settlement hold period after service completion?
- Can settlements be automatically paused when a dispute is filed?
- Can operators view supporting documents and chat logs on a single screen?
- Are the reasons for operator decisions recorded?
- Have you instructed the AI or development team to “ask first if a policy hasn’t been established”?
Conclusion
The most dangerous misconception in the initial development of a matching platform is the belief that “if the features are there, the marketplace will run on its own.” In reality, what drives a marketplace are rules such as exposure, matching, cancellations, fees, settlements, and dispute resolution.
AI can generate code quickly, but it is up to the founder to determine which behaviors to reward and which risks to prevent. To prevent fee leakage and maintain service quality, you must document these five policies before launch and integrate them into user interfaces, status indicators, admin features, and customer guidance messages.
