Before Building a Matching Service: Start with Registration, Search, or Introduction?

A shopping-district office receives a LINE message: “Do you know a photographer for our event next month?” The coordinator searches a paper member directory and old email threads, then calls candidates one at a time. While waiting for the first reply, the requester only hears that the office is still checking.

At a local business support desk, a paper request says “weekends preferred,” so the coordinator introduces an available specialist. Only after the introduction does the requester explain a crucial experience requirement, and the search starts again by email.

As these introductions increase, it is natural to wonder whether you need a matching service with registration, search, and automatic recommendations.

Record why an introduction worked before designing screens

“Registration and search both seem necessary. But while our introductions are still manual, where should we start?”

A matching service has three participants: the person making a request, the person offering help, and the operator coordinating the introduction.

Designing all three interfaces at once quickly expands the feature list.

Yet screens alone do not explain why a match worked.

You need to learn what the requester valued, why the provider accepted, and why the operator selected that candidate.

The first question is not whether candidates can be ranked automatically.

It is whether you can receive one request, select a candidate, obtain consent from both sides, and check the outcome.

If this exchange does not work repeatedly, more profiles and filters will not reveal match quality.

The short answer

If you have only a few real introductions and do not record why they succeed or stop, you do not need to start with a registration site.

Use an existing form to receive a request, let an operator select one candidate, and confirm separately with both parties.

If requesters naturally compare area, service, and availability themselves, test a small searchable directory with limited public fields.

If providers need to review requests and volunteer for work they can handle, test request posting and applications.

Consider automatic ordering only after you have the following evidence:

Requesters can explain why they accepted or rejected a candidate.
Providers can explain why they accepted or declined a request.
Operators can explain which conditions included and excluded candidates.
You can see whether an introduction reached contact, a meeting, an order, or delivery.
When similar requests have different outcomes, you can review what changed.

You do not need registration, search, messaging, payment, and reviews in the first release.

Build the smallest flow that can take one recent request from intake through outcome review.

30-second check: how should you test the first match?

Answer four questions to choose a provisional starting point: form intake with manual introduction, a searchable directory, request posting and applications, or matching-rule design.

The result is not a final decision.

Use it to order a real introduction trial and the questions you ask a service provider or development partner.

Write one introduction as a timeline before naming the service

Choose one recent introduction that succeeded or stopped partway through.

Write it in this order:

Who sent the request, and whether it arrived by phone, LINE, email, or paper.
What outcome the requester wanted.
What the operator had to ask again.
Which directory or past record the operator searched.
Why the operator contacted that candidate.
What the candidate checked before accepting.
When and what information was shared with each party.
Who checked how far the introduction progressed.

Do not use feature names yet.

Write human actions such as “the requester enters conditions,” “the operator selects a candidate,” and “the provider replies whether they can help.”

The point where the exchange stopped is a candidate for the first screen to test.

Compare manual introductions, directories, request posts, and automatic ordering

This table is not a ranking.

It separates who chooses the candidate, how much information is public, and what the operator must do.

Because prices change, it focuses on the conditions needed for an initial trial.

Representative starting point	When it fits	Primary benefit	Downside or question	Usage or connection condition	First trial
Manual introduction by LINE, email, or phone	Request volume is still low, and an operator selects candidates after hearing both sides	Test what makes an introduction work without requiring new registration	Requests, candidates, replies, and outcomes can remain in separate places. A new operator may not know why someone was selected	Use current communication channels, but keep the request number, candidate, consent, and outcome in one record	Take one request through intake, selection, consent, contact sharing, and outcome review
Existing form plus operator-led introduction	The questions are mostly known, but candidate selection still needs conversation and operator experience	Receive requests in consistent fields and learn which questions matter before building registration	A long form can stop people. Candidate checks, consent, and outcomes still need a separate operating flow	Google Forms, for example, can show responses in the form or a linked spreadsheet. Confirm who can view the data	Receive one request, let an operator choose one candidate, and append the reason and outcome
Searchable candidate directory	Requesters can compare area, service, and availability and choose whom to contact	Help requesters understand differences and reduce simple candidate inquiries to the operator	Old public information creates confusion. Too many filters can return almost nothing while the directory is small	Decide public profile fields, update ownership, listing suspension, and what is shared only after inquiry	Use a small set of candidates and only the conditions real requesters use to choose one contact
Request posting plus provider applications	Providers can review a request and decide for themselves whether to respond	Start with providers who are willing and reduce sequential outreach by the operator	You need a process for no applications and multiple applications. The post must not identify the requester unintentionally	Define public request fields, deadline, eligibility, contact-sharing conditions, and who closes the post	Share one nearly anonymous request and test application, requester selection, and consent from both parties
A focused custom candidate-ordering flow	Reasons for success and failure are recorded, and candidate volume now makes comparison difficult	Narrow candidates by common conditions so operators can focus on exceptions	You must handle ordering explanations, old data, bias, no result, and incorrect suggestions. Keep human review where needed	Operate profile updates, conditions, explanations, identity checks, contact, suspension, and support	Replay one past request, show top candidates and reasons, and ask whether an operator agrees

What the official information tells you to check

Japan's Digital Agency guidebook on user-centered public services recommends improving services from actual user voices and behavior (reference).

For matching, review the actions of providers and operators as well as requesters.

The GOV.UK user research guide similarly recommends learning what people use today, what frustrates them, and what they need to achieve (reference).

Do not build search only because someone asks for it. Return to a concrete problem such as “I cannot compare candidates, so I call the office every time.”

The Small and Medium Enterprise Agency's Growth Acceleration Matching Service lets businesses register needs and receive contact from interested supporters (reference).

It is a current example showing that a matching service does not have to choose the other party automatically. The page also states that contact from a supporter is not guaranteed.

Who selects the candidate and who makes first contact change both the screens and the operating work.

Separate the requester task from the provider task

Requesters and providers do not necessarily need the same information.

What requesters need to know

Whether their request is eligible before they register.
What they must describe for candidates to be found.
How candidates differ and why one was introduced.
When they can expect a response.
Whether they must explain a rejection directly to the candidate.

What providers need to know

Whether the request, timing, and location are within their scope.
What requester information they can see before applying or accepting.
Who will contact them after they accept.
How much they need to explain when they cannot help.
Who updates their profile and current availability.

Do not place all of these questions in one registration form.

Separate public information, operator-only information, and information shared after both parties agree.

Separate must-have conditions, preferences, and conversation points

More conditions do not automatically produce a better candidate.

Start with three groups:

A must-have condition prevents the introduction if it is not met.
A preference helps compare several eligible candidates.
A conversation point cannot be confirmed without speaking to the parties.

For one service, area and required licensing may be must-haves, preferred dates may be preferences, and working style may need a conversation.

The classification changes with the industry and request.

For each real introduction, record which conditions were checked in data and which were confirmed through conversation.

Do not force an important free-text sentence into a fixed option when the nuance matters.

Confirm separately with both parties before the introduction

Even after an operator finds a candidate, sharing contact information immediately may be inappropriate.

Test this order:

Confirm with the requester what will be introduced and what will be told to the candidate.
Give the provider a nearly anonymous request summary and ask whether they can respond.
Tell both parties how and by when first contact should happen.
Share only the necessary contact information after both parties agree.
Let the operator confirm that contact started.
If the introduction stops, record the reason and next action.

Skipping this sequence can create surprise contact or unintended information sharing.

In a prototype, show different information before and after consent.

Record where the exchange stopped, not only completed matches

If your record ends at “introduced,” you cannot see what to improve.

As practical decision support, separate these states:

The request arrived, but missing information prevented candidate search.
A candidate was found, but the provider could not respond.
Both parties agreed, but first contact did not begin.
They met, but no order or delivery followed.
Delivery occurred, and both parties confirmed the outcome.
Contact stopped, and the operator could not confirm the outcome.

Do not force every rejection into a predefined option.

Allow a short note so the next introduction criteria can be reviewed.

Decide trust and incident handling before adding search

When matching involves people's skills, time, places, or shared goods, safety and trust after the introduction are also part of operations.

The sharing-economy model guidelines published by Japan's Digital Agency cover contact methods, risk-based identity checks, terms, ranking explanations, pre-service inquiries, removal of false listings, and support channels (reference).

The guideline does not apply identically to every matching service.

It is still useful for preventing these questions from being postponed:

What do you confirm about requesters and providers before allowing use?
Who verifies licenses or qualifications where they are required?
Who removes an old, false, or policy-breaking listing?
Can the parties clarify the request before the work starts?
Who receives reports and incidents, and through which contact route?
If the service closes, how are active introductions handled?

The applicable rules depend on what is being matched.

Once the service category is known, confirm requirements with the relevant authority or a qualified legal adviser.

Five signs to discuss a focused custom flow

After testing an existing form and manual introduction, consider a focused custom flow when several of these conditions overlap:

Requesters, providers, and operators need finely separated rights to enter, publish, and view information.
Provider availability and service areas change often, causing introductions based on old information.
One request involves several candidates, and the operator must track consent and contact order.
The operator needs to follow meetings, orders, delivery, and rejection and use them in future selection.
The category needs specific identity checks, qualification checks, reporting, or account suspension procedures.

Even then, the first build is not a large public marketplace.

Test only the flow that receives one request, selects one candidate, introduces them after both parties agree, and records the outcome.

Define the first scope as one request type and one introduction method

Every additional matching category adds questions and checks.

As a practical starting point, use this scope:

Decision	First scope	What to verify
Request	One type whose contents and outcome can be explained	Can a requester ask without confusion, and can the necessary information be collected?
Provider	A group whose current availability the operator can confirm	Can you ask about eligible conditions and rejection reasons consistently?
Introduction method	One of manual introduction, candidate search, or request posting	Who chooses candidates, and when is contact information shared?
Outcome	One exchange from intake through delivery review	Can you record both completion and where and why the exchange stopped?

If the trial lacks information, add one question to the next request.

Do not collect every field that might be useful someday.

Separate public profiles from private request details

A matching service may handle names, contact details, location, experience, qualifications, request details, timing, budget approach, and introduction outcomes.

Japan's Personal Information Protection Commission guidelines state that the purpose of use should be specific enough for the person to anticipate how information will be used (reference).

If information will be shared with another party, define the purpose so that sharing is clear.

If registration or behavior data influences candidate ordering, explain what is used and why.

Before adoption, divide information into three levels:

Public information visible before registration.
Operator-only information used for candidate selection.
Information shared with the other party after both sides agree.

Also decide correction, listing suspension, account closure, post-introduction removal, and access removal when an operator changes.

“Use for future matching improvement” is too vague for a person to understand.

State which information supports which selection or contact step.

Five preparations before consultation

1. Choose one recent introduction

It may have succeeded or stopped partway through.

Put the phone calls, LINE messages, emails, and paper notes in time order.

2. Separate the three participants' tasks

Write what the requester decides, what the provider decides, and what the operator checks.

Name the owner of each task before combining them into one screen.

3. Explain candidate selection in one sentence

Separate area, service, timing, experience, and points confirmed in conversation.

If the reason cannot be explained, keep it manual and make it a consultation question.

4. Separate information visibility

Divide public information, operator-only information, and information shared after consent.

Do this for both requester and provider information.

5. Choose the first end point

Decide whether you will follow the exchange through contact sharing, a meeting, an order, or delivery.

Also name who checks the outcome and how.

Matching service starting-point checklist

Select only the items you can answer now.

Unselected items become questions for a manual trial or the first consultation.

Copyable consultation note

You can use this even when registration fields and search filters are not decided.

For an unknown item, write “confirm through the manual introduction trial.”

Copy a matching service consultation note

Use this note before registration fields or search filters are decided. Write “confirm through a manual trial” for unknown items.

What we want to discuss about starting a matching service:

What we introduce:
Example: receive requests from local businesses and introduce photographers or designers

Requester:
Example: shopping-district stores and community event organizers

Provider:
Example: local photographers and designers

Operator:
Example: two staff members at the shopping-district office

Current request intake:
Example: receive LINE messages, emails, and calls, then write them on paper

One recent introduction:
Example: received an event photography request, searched the member directory, and called a candidate to check availability

Why the candidate was selected:
Example: area and date were required, event experience was preferred, and working style needed a call

Where and why the introduction stopped:
Example: the first candidate did not reply, and it took two days to offer another option

Information that may be public:
Example: service area, work type, experience summary, and current availability

Operator-only information:
Example: contact details, decline reasons, identity or qualification review status

Information shared after both parties agree:
Example: name, email, phone number, and full request details

Outcome to review:
Example: whether the exchange reached first contact, a meeting, an order, or delivery

Trust and incident handling:
Example: the office receives listing corrections, reports, and suspension requests

First introduction method to test:
Example: receive one form request, let an operator choose one candidate, and introduce them after consent

What we want to decide:
Example: whether to start with manual introduction, a searchable directory, or request posting and applications

Examples we can share:
Example: anonymized LINE request, paper directory, candidate confirmation message, and outcome record

Your next step

Choose only one recent introduction request.

Write one line each for the request, why the candidate was selected, what each party confirmed, and the outcome.

This sentence is enough for a first consultation:

We coordinate introductions by LINE and email. Before building a registration site, we want to decide whether to test form intake with manual introduction, a searchable directory, or request posting and applications.

Start with one introduction you can follow to the end, not with “build a matching service.”

Record why an introduction worked before designing screens

“Registration and search both seem necessary. But while our introductions are still manual, where should we start?”

A matching service has three participants: the person making a request, the person offering help, and the operator coordinating the introduction.

Designing all three interfaces at once quickly expands the feature list.

Yet screens alone do not explain why a match worked.

You need to learn what the requester valued, why the provider accepted, and why the operator selected that candidate.

The first question is not whether candidates can be ranked automatically.

It is whether you can receive one request, select a candidate, obtain consent from both sides, and check the outcome.

If this exchange does not work repeatedly, more profiles and filters will not reveal match quality.

The short answer

If you have only a few real introductions and do not record why they succeed or stop, you do not need to start with a registration site.

Use an existing form to receive a request, let an operator select one candidate, and confirm separately with both parties.

If requesters naturally compare area, service, and availability themselves, test a small searchable directory with limited public fields.

If providers need to review requests and volunteer for work they can handle, test request posting and applications.

Consider automatic ordering only after you have the following evidence:

Requesters can explain why they accepted or rejected a candidate.
Providers can explain why they accepted or declined a request.
Operators can explain which conditions included and excluded candidates.
You can see whether an introduction reached contact, a meeting, an order, or delivery.
When similar requests have different outcomes, you can review what changed.

You do not need registration, search, messaging, payment, and reviews in the first release.

Build the smallest flow that can take one recent request from intake through outcome review.

30-second check: how should you test the first match?

Answer four questions to choose a provisional starting point: form intake with manual introduction, a searchable directory, request posting and applications, or matching-rule design.

The result is not a final decision.

Use it to order a real introduction trial and the questions you ask a service provider or development partner.

Write one introduction as a timeline before naming the service

Choose one recent introduction that succeeded or stopped partway through.

Write it in this order:

Who sent the request, and whether it arrived by phone, LINE, email, or paper.
What outcome the requester wanted.
What the operator had to ask again.
Which directory or past record the operator searched.
Why the operator contacted that candidate.
What the candidate checked before accepting.
When and what information was shared with each party.
Who checked how far the introduction progressed.

Do not use feature names yet.

Write human actions such as “the requester enters conditions,” “the operator selects a candidate,” and “the provider replies whether they can help.”

The point where the exchange stopped is a candidate for the first screen to test.

Compare manual introductions, directories, request posts, and automatic ordering

This table is not a ranking.

It separates who chooses the candidate, how much information is public, and what the operator must do.

Because prices change, it focuses on the conditions needed for an initial trial.

Representative starting point	When it fits	Primary benefit	Downside or question	Usage or connection condition	First trial
Manual introduction by LINE, email, or phone	Request volume is still low, and an operator selects candidates after hearing both sides	Test what makes an introduction work without requiring new registration	Requests, candidates, replies, and outcomes can remain in separate places. A new operator may not know why someone was selected	Use current communication channels, but keep the request number, candidate, consent, and outcome in one record	Take one request through intake, selection, consent, contact sharing, and outcome review
Existing form plus operator-led introduction	The questions are mostly known, but candidate selection still needs conversation and operator experience	Receive requests in consistent fields and learn which questions matter before building registration	A long form can stop people. Candidate checks, consent, and outcomes still need a separate operating flow	Google Forms, for example, can show responses in the form or a linked spreadsheet. Confirm who can view the data	Receive one request, let an operator choose one candidate, and append the reason and outcome
Searchable candidate directory	Requesters can compare area, service, and availability and choose whom to contact	Help requesters understand differences and reduce simple candidate inquiries to the operator	Old public information creates confusion. Too many filters can return almost nothing while the directory is small	Decide public profile fields, update ownership, listing suspension, and what is shared only after inquiry	Use a small set of candidates and only the conditions real requesters use to choose one contact
Request posting plus provider applications	Providers can review a request and decide for themselves whether to respond	Start with providers who are willing and reduce sequential outreach by the operator	You need a process for no applications and multiple applications. The post must not identify the requester unintentionally	Define public request fields, deadline, eligibility, contact-sharing conditions, and who closes the post	Share one nearly anonymous request and test application, requester selection, and consent from both parties
A focused custom candidate-ordering flow	Reasons for success and failure are recorded, and candidate volume now makes comparison difficult	Narrow candidates by common conditions so operators can focus on exceptions	You must handle ordering explanations, old data, bias, no result, and incorrect suggestions. Keep human review where needed	Operate profile updates, conditions, explanations, identity checks, contact, suspension, and support	Replay one past request, show top candidates and reasons, and ask whether an operator agrees

What the official information tells you to check

Japan's Digital Agency guidebook on user-centered public services recommends improving services from actual user voices and behavior (reference).

For matching, review the actions of providers and operators as well as requesters.

The GOV.UK user research guide similarly recommends learning what people use today, what frustrates them, and what they need to achieve (reference).

Do not build search only because someone asks for it. Return to a concrete problem such as “I cannot compare candidates, so I call the office every time.”

The Small and Medium Enterprise Agency's Growth Acceleration Matching Service lets businesses register needs and receive contact from interested supporters (reference).

It is a current example showing that a matching service does not have to choose the other party automatically. The page also states that contact from a supporter is not guaranteed.

Who selects the candidate and who makes first contact change both the screens and the operating work.

Separate the requester task from the provider task

Requesters and providers do not necessarily need the same information.

What requesters need to know

Whether their request is eligible before they register.
What they must describe for candidates to be found.
How candidates differ and why one was introduced.
When they can expect a response.
Whether they must explain a rejection directly to the candidate.

What providers need to know

Whether the request, timing, and location are within their scope.
What requester information they can see before applying or accepting.
Who will contact them after they accept.
How much they need to explain when they cannot help.
Who updates their profile and current availability.

Do not place all of these questions in one registration form.

Separate public information, operator-only information, and information shared after both parties agree.

Separate must-have conditions, preferences, and conversation points

More conditions do not automatically produce a better candidate.

Start with three groups:

A must-have condition prevents the introduction if it is not met.
A preference helps compare several eligible candidates.
A conversation point cannot be confirmed without speaking to the parties.

For one service, area and required licensing may be must-haves, preferred dates may be preferences, and working style may need a conversation.

The classification changes with the industry and request.

For each real introduction, record which conditions were checked in data and which were confirmed through conversation.

Do not force an important free-text sentence into a fixed option when the nuance matters.

Confirm separately with both parties before the introduction

Even after an operator finds a candidate, sharing contact information immediately may be inappropriate.

Test this order:

Confirm with the requester what will be introduced and what will be told to the candidate.
Give the provider a nearly anonymous request summary and ask whether they can respond.
Tell both parties how and by when first contact should happen.
Share only the necessary contact information after both parties agree.
Let the operator confirm that contact started.
If the introduction stops, record the reason and next action.

Skipping this sequence can create surprise contact or unintended information sharing.

In a prototype, show different information before and after consent.

Record where the exchange stopped, not only completed matches

If your record ends at “introduced,” you cannot see what to improve.

As practical decision support, separate these states:

The request arrived, but missing information prevented candidate search.
A candidate was found, but the provider could not respond.
Both parties agreed, but first contact did not begin.
They met, but no order or delivery followed.
Delivery occurred, and both parties confirmed the outcome.
Contact stopped, and the operator could not confirm the outcome.

Do not force every rejection into a predefined option.

Allow a short note so the next introduction criteria can be reviewed.

Decide trust and incident handling before adding search

When matching involves people's skills, time, places, or shared goods, safety and trust after the introduction are also part of operations.

The guideline does not apply identically to every matching service.

It is still useful for preventing these questions from being postponed:

What do you confirm about requesters and providers before allowing use?
Who verifies licenses or qualifications where they are required?
Who removes an old, false, or policy-breaking listing?
Can the parties clarify the request before the work starts?
Who receives reports and incidents, and through which contact route?
If the service closes, how are active introductions handled?

The applicable rules depend on what is being matched.

Once the service category is known, confirm requirements with the relevant authority or a qualified legal adviser.

Five signs to discuss a focused custom flow

After testing an existing form and manual introduction, consider a focused custom flow when several of these conditions overlap:

Requesters, providers, and operators need finely separated rights to enter, publish, and view information.
Provider availability and service areas change often, causing introductions based on old information.
One request involves several candidates, and the operator must track consent and contact order.
The operator needs to follow meetings, orders, delivery, and rejection and use them in future selection.
The category needs specific identity checks, qualification checks, reporting, or account suspension procedures.

Even then, the first build is not a large public marketplace.

Test only the flow that receives one request, selects one candidate, introduces them after both parties agree, and records the outcome.

Define the first scope as one request type and one introduction method

Every additional matching category adds questions and checks.

As a practical starting point, use this scope:

Decision	First scope	What to verify
Request	One type whose contents and outcome can be explained	Can a requester ask without confusion, and can the necessary information be collected?
Provider	A group whose current availability the operator can confirm	Can you ask about eligible conditions and rejection reasons consistently?
Introduction method	One of manual introduction, candidate search, or request posting	Who chooses candidates, and when is contact information shared?
Outcome	One exchange from intake through delivery review	Can you record both completion and where and why the exchange stopped?

If the trial lacks information, add one question to the next request.

Do not collect every field that might be useful someday.

Separate public profiles from private request details

A matching service may handle names, contact details, location, experience, qualifications, request details, timing, budget approach, and introduction outcomes.

Japan's Personal Information Protection Commission guidelines state that the purpose of use should be specific enough for the person to anticipate how information will be used (reference).

If information will be shared with another party, define the purpose so that sharing is clear.

If registration or behavior data influences candidate ordering, explain what is used and why.

Before adoption, divide information into three levels:

Public information visible before registration.
Operator-only information used for candidate selection.
Information shared with the other party after both sides agree.

Also decide correction, listing suspension, account closure, post-introduction removal, and access removal when an operator changes.

“Use for future matching improvement” is too vague for a person to understand.

State which information supports which selection or contact step.

Five preparations before consultation

1. Choose one recent introduction

It may have succeeded or stopped partway through.

Put the phone calls, LINE messages, emails, and paper notes in time order.

2. Separate the three participants' tasks

Write what the requester decides, what the provider decides, and what the operator checks.

Name the owner of each task before combining them into one screen.

3. Explain candidate selection in one sentence

Separate area, service, timing, experience, and points confirmed in conversation.

If the reason cannot be explained, keep it manual and make it a consultation question.

4. Separate information visibility

Divide public information, operator-only information, and information shared after consent.

Do this for both requester and provider information.

5. Choose the first end point

Decide whether you will follow the exchange through contact sharing, a meeting, an order, or delivery.

Also name who checks the outcome and how.

Matching service starting-point checklist

Select only the items you can answer now.

Unselected items become questions for a manual trial or the first consultation.

Copyable consultation note

You can use this even when registration fields and search filters are not decided.

For an unknown item, write “confirm through the manual introduction trial.”

Copy a matching service consultation note

Use this note before registration fields or search filters are decided. Write “confirm through a manual trial” for unknown items.

What we want to discuss about starting a matching service:

What we introduce:
Example: receive requests from local businesses and introduce photographers or designers

Requester:
Example: shopping-district stores and community event organizers

Provider:
Example: local photographers and designers

Operator:
Example: two staff members at the shopping-district office

Current request intake:
Example: receive LINE messages, emails, and calls, then write them on paper

One recent introduction:
Example: received an event photography request, searched the member directory, and called a candidate to check availability

Why the candidate was selected:
Example: area and date were required, event experience was preferred, and working style needed a call

Where and why the introduction stopped:
Example: the first candidate did not reply, and it took two days to offer another option

Information that may be public:
Example: service area, work type, experience summary, and current availability

Operator-only information:
Example: contact details, decline reasons, identity or qualification review status

Information shared after both parties agree:
Example: name, email, phone number, and full request details

Outcome to review:
Example: whether the exchange reached first contact, a meeting, an order, or delivery

Trust and incident handling:
Example: the office receives listing corrections, reports, and suspension requests

First introduction method to test:
Example: receive one form request, let an operator choose one candidate, and introduce them after consent

What we want to decide:
Example: whether to start with manual introduction, a searchable directory, or request posting and applications

Examples we can share:
Example: anonymized LINE request, paper directory, candidate confirmation message, and outcome record

Your next step

Choose only one recent introduction request.

Write one line each for the request, why the candidate was selected, what each party confirmed, and the outcome.

This sentence is enough for a first consultation:

Start with one introduction you can follow to the end, not with “build a matching service.”

Record why an introduction worked before designing screens

The short answer

30-second check: how should you test the first match?

Write one introduction as a timeline before naming the service

Compare manual introductions, directories, request posts, and automatic ordering

What the official information tells you to check

Separate the requester task from the provider task

What requesters need to know

What providers need to know

Separate must-have conditions, preferences, and conversation points

Confirm separately with both parties before the introduction

Record where the exchange stopped, not only completed matches

Decide trust and incident handling before adding search

Five signs to discuss a focused custom flow

Define the first scope as one request type and one introduction method

Separate public profiles from private request details

Five preparations before consultation

1. Choose one recent introduction

2. Separate the three participants' tasks

3. Explain candidate selection in one sentence

4. Separate information visibility

5. Choose the first end point

Matching service starting-point checklist

Copyable consultation note

Your next step

Further reading

Test your improvement idea with a small prototype

Related articles

A New Web Service Idea: What Should You Test Before Development?

Website, Application Form, or Web App? Choose the Right Starting Point

Event and Community Web App Prototype Ideas: Start with Check-In and Attendee Lists

Do You Need a Member Portal? Where to Start with Bookings, History, and Notices

Record why an introduction worked before designing screens

The short answer

30-second check: how should you test the first match?

Write one introduction as a timeline before naming the service

Compare manual introductions, directories, request posts, and automatic ordering

What the official information tells you to check

Separate the requester task from the provider task

What requesters need to know

What providers need to know

Separate must-have conditions, preferences, and conversation points

Confirm separately with both parties before the introduction

Record where the exchange stopped, not only completed matches

Decide trust and incident handling before adding search

Five signs to discuss a focused custom flow

Define the first scope as one request type and one introduction method

Separate public profiles from private request details

Five preparations before consultation

1. Choose one recent introduction

2. Separate the three participants' tasks

3. Explain candidate selection in one sentence

4. Separate information visibility

5. Choose the first end point

Matching service starting-point checklist

Copyable consultation note

Your next step

Further reading

Test your improvement idea with a small prototype

Related articles

A New Web Service Idea: What Should You Test Before Development?

Website, Application Form, or Web App? Choose the Right Starting Point

Event and Community Web App Prototype Ideas: Start with Check-In and Attendee Lists

Do You Need a Member Portal? Where to Start with Bookings, History, and Notices