What practitioners actually use to run an async reading practice.

Most readers running an async practice are using somewhere between four and seven different tools to do it. Each tool was built for a different audience, none were built for readers, and the seams between them are where the real work happens. The pieces work, mostly. But the workflow is held together by the practitioner.

Below is the honest stack. What each tool is doing, where the seams are, and what changes if any of them break.

In this post

1. The seven jobs to be done in an async practice
2. The typical stack
3. Where the seams are
4. The hidden tax of a stitched workflow
5. What it would look like if these things worked together
6. The short version

The seven jobs to be done in an async practice

Strip the tools away and what you are actually doing is this:

1. Letting clients book or order a reading
2. Collecting the information you need to do the reading
3. Tracking the queue, knowing what is owed and to whom
4. Doing the reading itself
5. Producing the deliverable, in whatever format you offer
6. Sending the reading to the client in a way that respects the work
7. Keeping enough record of what you sent that you can show up well next time

Each of these jobs has at least one tool, and most have two or three. Almost no tool covers more than one job well.

The typical stack

A scheduling app for booking. Most readers reach for one of the major scheduling tools because they are familiar and free at the entry tier. They handle calendar bookings well. They do not handle async work at all. An async reading is not an appointment, but the tool will treat it like one. You end up bending the tool to your shape.

A form tool for intake. Free form tools collect what the scheduling app cannot. Name, question, context, sometimes birth data. Each form is its own document. Responses arrive in a spreadsheet. Connecting a response to a booking is manual.

A spreadsheet or notebook for the queue. This is where the actual queue lives, even when readers think they are using something more sophisticated. Names, due dates, status. Updated by hand. Almost universal.

A note app for the reading itself. Whatever the reader writes in. A document, a notes app, a piece of paper. Photos of the spread are taken on a phone and emailed to the reader's own laptop, or transferred via cable.

A design tool for the deliverable. If the reader sends PDFs, this is where the PDF is built. Drag and drop card images, paste in the reading text, export. Each PDF is built one at a time, often from a template.

A file sharing service for delivery. Where the file lives. Where the link comes from. The single most common point of client confusion.

A messaging channel for sending the link. Whatever channel the client booked through. DMs, email, a marketplace inbox. Often three different channels for three different clients.

That is seven tools to send one reading. None of them know the others exist.

Where the seams are

The cost of a stitched stack is not in any one tool. It is in the gaps between them.

Booking to intake. A client books, then has to be sent the intake form separately. Some never fill it in. The reader has to follow up. The follow-up lives in a different inbox than the booking confirmation.

Intake to queue. Someone fills out the form. The response goes into a spreadsheet. The reader has to manually copy that response into the queue, or the queue tool has to be checked alongside the form responses. Information lives in two places.

Queue to reading. The reader sits down to work. They open the spreadsheet. Then they open the form responses to see the question. Then they open their notes app to write. Three windows for one reading.

Reading to deliverable. Whatever was written has to be moved into the design tool, formatted, photos embedded, exported.

Deliverable to delivery. The file is uploaded somewhere. A link is generated. The link is copied. The link is pasted into a message.

Delivery to record. If the reader keeps records, this is the last manual step. The link, the date, the client name, all logged somewhere. If they do not keep records, this step is skipped, and the practice loses the memory of the reading the moment the link is sent.

Each seam takes seconds. Multiplied across a year of readings, the seams are the practice.

The hidden tax of a stitched workflow

The tax shows up in three places.

Time. The minutes between tools add up to hours per week for a practitioner running any meaningful volume. Hours that are not reading, not marketing, not rest.

Errors. The wrong link sent. The wrong client name on the PDF. The intake form that never made it to the spreadsheet. The reading that got built in two parts because the workflow was interrupted halfway through.

Memory. This is the one most readers underestimate. A returning client comes back six months later. The reader cannot find the previous reading. They do not remember the cards that came up. The new reading starts from zero, and the relationship that should be the easiest part of the practice becomes the hardest.

Most readers compensate for the memory tax by deciding not to need it. "I prefer to start fresh." This is sometimes true and sometimes a workaround for not having a system that holds memory for them.

What it would look like if these things worked together

A practice tool built for async readings would do this:

• One place to receive bookings and intakes
• A queue that updates as bookings come in, with a status for each one
• A reading screen that holds the intake, the notes, the photos, and the writing in one view
• A delivery page that goes to the client, ready when the reading is
• A record of every reading, indexed by client, available next time

This is what Wren Sent is becoming. The delivery page exists today. The client list exists today. The booking and queue and composer are next. The point is not to replace every tool a reader uses. The point is that the seven jobs in an async practice should not require seven separate tools.

This is what Wren Sent does.

A delivery page made for the reading. Client list with reading history. The pieces of a practice, in one place. Start free, no card required.

Start for free

The short version

A stitched workflow works until it does not. Until a client falls through a seam, or a returning client has no memory in the system, or an hour of admin replaces an hour of reading. The tools are not the problem, exactly. The problem is that no one ever built tools that knew about each other.

The practice you actually want to run sits underneath the workflow you have been holding together by hand.