Collect the essentials
Ask for service category, languages, working hours, experience and a sample profile. Explain the review process, data use and who will contact the applicant. Avoid asking for unrelated personal history.
Resources / operator guide
Reader onboarding for psychic hotlines and marketplaces
A reader network is a service operation, not a directory of portraits. Decide how advisers join, become available, deliver a session, get paid and resolve complaints before adding a large roster.
A practical process design for operators. Background checks, employment status, recording and payment rules require jurisdiction-specific professional review.
01 / Service promise
Define the experience before recruitment.
The application should be designed around what customers are promised: medium, languages, price basis, hours, response time and support.
If customers can call instantly, a profile marked “available” must represent an answerable reader, not a stale status from yesterday. If a service is appointment-only, the profile should show bookable times in the customer's time zone. If readers choose rates, customers must see the total price basis before entering a session. Define minimum service standards, acceptable claims and the process for escalating distress or a safety concern.
Separate the reader's public biography from sensitive internal checks. Decide which team can see identity documents, tax details, payout information and incident notes. Document a retention and deletion schedule based on applicable obligations; avoid collecting details that the workflow never uses.
02 / The onboarding sequence
Make each approval step reversible and observable.
Verify the fit
Check stated credentials or identity to the extent relevant and permitted. Review copy and claims against platform rules. Use a consistent scorecard; keep the reviewer, decision and reason auditable.
Test the journey
Run a sample booking or call with a test customer. Confirm availability, connection, time-zone display, rate, cancellation, support and reader payout ledger. Train the reader on the actual tools.
Go live in stages
Start with limited availability and an assigned support contact. Review first-session exceptions before increasing visibility. Give the reader a way to pause status and report a technical problem.
A rejection or pause should have a documented reason, a person who can review it and a defined appeal or correction path. Treat account suspension and deletion as separate actions; preserve records only where necessary and permitted.
03 / System design
Reader status is a product contract.
Represent availability as explicit states, not a single boolean. An accepted adviser may be offline, scheduled, available, ringing, in a session, on a break or suspended. Define which transitions readers control, which are triggered by a booking or call event, and which require an operator. A network should not bill a customer because the reader tapped “available” if no connection occurred.
| State or event | Customer view | Operator check |
|---|---|---|
| Available | A real call or booking action | Fresh status and route to reader |
| Ringing, unanswered | Clear fallback or another adviser | No completed-reading charge; retry rule |
| Connected session | Price and elapsed-time clarity | Connection event, billable rule, support trace |
| Cancelled or disputed | Resolution channel and policy | Timeline, refund decision and payout adjustment |
Telephony services such as Twilio expose more than “success” and “failure”: queued, ringing, in-progress, busy, no-answer and completed states exist. Choose the events that drive billing and support, reconcile them with the provider and test dropped calls. Do not assume every provider emits identical events or timing.
04 / Quality without theatre
Use permissioned evidence and a fair review path.
Profile evidence might include the reader's chosen introduction, genuine specialties, supported formats, languages, available hours and verified service history when the platform can substantiate it. Publish testimonials only with permission and a way to report misuse. Do not fabricate “verified” badges or reorder profiles using a score customers cannot interpret.
Give support a consistent case form: booking or call ID, timeline, promise shown to the customer, technical events, reader account, customer's requested remedy and final action. Define when support can issue credit, refund, warning or escalation. Track repeat complaints in context: an adviser with one complaint in two sessions is not equivalent to one with one complaint in hundreds, and raw star averages alone hide the reason.
An exception to test
A customer is charged for a three-minute attempted call, but the reader says no audio was heard. The operator needs connection and billing timestamps, a stated charging rule, the contact record and authority to resolve the discrepancy. Reconstruct the event without requiring either party to tell the whole story again.
05 / Pilot scorecard
Prove a small roster before recruitment at scale.
Run a limited pilot with a few invited readers and agreed service hours. Count applications to approvals, successful first sessions, answer rate, customer wait, support contacts per completed session, cancellations, disputes, reader availability accuracy and net contribution after reader, telephony, payment and support costs. Review every failed path manually, not just conversion totals.
Write acceptance conditions before launch: a new reader can submit, be reviewed, complete the test journey and pause availability; a customer sees the rate, connects or receives a truthful fallback; an operator can explain every billable event. If the operator cannot reconcile a refund and payout, do not widen the roster yet.
Our hotline setup guide covers the wider business model, and the hotline planning calculator lets you stress-test assumptions. Both require your real cost inputs.
Operator questions
Frequently asked questions.
Should every applicant become searchable immediately?
No. Review the application and complete a test of the specific service journey first. A live profile implies the operator can route, support and settle the promised service.
How should a reader become unavailable?
Provide a clear manual pause and automatic transitions for booked or connected sessions. Define how stale sessions recover and when an operator can override an incorrect state.
Can we publish a quality score?
Only if the underlying evidence, sample size, meaning and complaint process are defensible. A simpler, accurately stated review or availability signal may be more useful than an opaque badge.
Who should handle a billing dispute?
An accountable support role needs the session timeline, provider events, price shown, applicable terms and authority to decide a remedy. Get professional review of the policies and local obligations.
Build around operations
Scope the reader journey before platform features.
Hotline systemsCall routing, billing and support design.Explore service ↗Marketplace designReader discovery, booking and settlement.Explore service ↗Discuss a projectShare your current roster and failure path.Prepare a brief ↗
Reference: Twilio call states and callbacks. Provider events and compliance requirements must be validated for the chosen stack and operating markets.