Responding to a project-based booking request

Step by step

1. 1

   A request lands in your Pending tab

   When a client submits a project-based request to you, you get a push notification. Tapping it lands you on the booking detail page directly. If you missed the push or want to look later, the request lives under Bookings → Requests → Pending as a compact card — one slim row per request in the list.

   The compact card is intentionally small (one row, very dense). Left to right it contains:

   • the client's avatar and @username
   • the date and time of the next session (or the only session, if you haven't proposed a date yet — in that case the time slot reads --:--), plus the city for tattoo artists if a session-level location is set, and a small +N counter if the booking has more sessions you're not seeing on this row

   on the right, a strip of six small icons in coloured pill backgrounds — one per field of the next session. The icon shape stays the same in every row; only the background colour changes to reflect the field's status. The six fields are:

   • Date — calendar-outline
   • Time — time-outline
   • Duration — hourglass-outline
   • Location — location-outline (tattoo artists only — body modification practitioners don't see this icon)
   • Price — pricetag-outline
   • Deposit — cash-outline

   (Time-based bookings show only two icons on this strip — date and deposit — because the time-based model doesn't negotiate the others.)

   The whole card is one tap-target — tapping anywhere on the row opens the full booking detail page, which is the proper workspace where you actually negotiate (covered from Step 2 on).

   The background colour of each icon is how you read the card. This is the single most important thing to learn about the booking list — it's how you tell at a glance which requests need you right now and which are waiting on the client. The colour code is the same everywhere in the booking system (compact card here, detail page in Step 3, the badges on the calendar):

   • 🟠 Orange — your turn to act. You haven't proposed a value for this field yet, or the client rejected the value you proposed and you need to propose a new one.
   • 🟡 Yellow — the client's turn. You proposed a value; you're waiting on them to accept or reject it.
   • 🟢 Green — confirmed. You both agreed on this field, it's locked in.
   • 🔴 Red — rejected. Either the client explicitly rejected your proposal, or the proposed date passed without the client confirming it (the system auto-rejects expired dates — see Step 5). You need to propose a new value.

   If any field icon on a card is orange, a small orange stripe also lights up on the left edge of the row — a fast visual to scan the whole list and spot every request that needs you, without checking each icon individually.

   If a booking is currently in a refund flow (the client cancelled a session, or you dropped one and the refund is in progress), the six field icons are replaced by a small "Cancelling" or "Dropping" badge — same colour rules apply (orange = your move next, yellow = waiting on the other party).

   Two banners may sit above the whole list, and both are worth knowing:

   • Calendar Closed. If your Availability & Schedule info card has your calendar set to closed, a banner appears across every Requests sub-tab telling you new requests and broadcasts are paused. Existing requests still live in your queue and you can still negotiate them — closed just means no new ones are coming in. The banner shows the reopening date if you set one, and the Update Availability Settings link in it deep-links straight to the right screen.
   • Activate the Booking module to receive new requests. If you're a practitioner without the Booking module active (typically post-trial), the banner blocks new incoming requests but leaves your historical ones visible. Tapping it routes you to the upgrade flow.

   If you don't have any pending requests, the tab shows a friendly All Clear! empty state.

2. 2

   Open the brief

   Tap a card to open the booking detail page. The page has two tabs at the top — Management and Request Details — and a Message button in the header (tap it to open or start the conversation with the client). Hit Request Details first; that's where the brief lives. You'll see a stack of cards, one per piece of information the client provided:

   • Project Description — the free-text brief the client wrote. This is the actual ask, in their words: "I want a small flower on my hips," "Looking to redo this old piece," "Need a touch-up plus an extension." Read it carefully — it's the only piece of the form where the client's voice comes through unfiltered.
   • Reference Images — a separate gallery of images the client uploaded from their own gallery or picked off your portfolio. Tap one to open the full-screen viewer.
   • Tattoo Details (tattoo artists only) — Size (cm), Placement (body part), Style Preference (e.g. neo-traditional, realism, fineline). The client filled these on dedicated form pages, so they're parsed and structured here — not duplicated from the description.
   • Location — the place the client picked when they submitted the request: your resident studio (your home shop), one of your guest spots (with the studio name and dates), or your independent location. Whatever they picked is inherited by every session by default, so unless you propose a per-session location change later (covered in the per-field article), this is where all the work will happen.
   • Scheduling preferences — when the client said they're available. Either Calendar dates (specific days or date ranges), a Weekly pattern ("I'm available Mondays and Tuesdays"), or both — with optional time windows on either. You'll also see whether the client flagged themselves as traveling from another city, flexible with dates, or hard-windowed for a holiday/business trip. They also tell you their maximum consecutive sessions — how many sessions in a row they're willing to do (e.g. "up to 3 consecutive days"). Important: this number is informational only; it doesn't pre-create sessions for you. Read it as: "if you decide this project needs to be split into N sessions, here's how many you can stack on consecutive days."

   Read all of these before you start responding — vague availability in your proposal is the easiest way to turn a single-round negotiation into a long back-and-forth.

3. 3

   The response loop — how proposing actually works

   Switch to the Management tab. This is where you spend most of the booking's life.

   The booking always starts with one session. The form asks them about their maximum consecutive sessions preference, so read the brief, decide how the work should actually be split, and add any extra sessions yourself from this same screen.

   You'll see a row of session tabs across the top (Session 1, Session 2, etc., plus a + to add one). The selected session card sits below the tabs with six rows: Date, Time, Duration, Price, Deposit, Location. Each row has an icon, the current value (or "Not set"), and a status pill in the same colour code you saw on the compact card — orange = your turn, yellow = the client's, green = confirmed, red = rejected.

   To propose a value, tap any field row. A modal opens, you set what you want, you close it. Your changes don't go out yet — they sit as pending changes on the booking. You can stack changes across multiple fields, switch session tabs and stack more, then tap Submit Proposal once when you're ready. Every queued change goes out together and the client gets a single notification ("New proposals from @you on your booking"). The batching is intentional — it stops both sides from getting drowned in per-field pings.

   A few things to know about the loop:

   • Order on a fresh session: you can propose fields in any order, but the Deposit row is disabled until you've at least set a price. That's a UI rule — the deposit modal needs to know what the price is to make sense of percentages and amounts.
   • You can re-propose any field, including confirmed ones. If the client already confirmed the date but you realise you need to shift it, you can still tap the date and propose a new one. The field goes back to pending and the booking flips out of "fully confirmed" until things resettle.
   • The client cannot reject a field after they've confirmed. Once they accept a field and submit, that field is locked from their side — they have no button to change their mind. If they want to walk back a confirmation, they have to send you a message and ask you to re-propose it. This is by design: it stops last-minute "actually I changed my mind on that date" surprises after you've already organised your week around it.
   • Date, Time, and Duration bundle together after a rejection. If any of Date, Time, or Duration is currently in the rejected state (because the client rejected it, or it was auto-rejected — see Step 5), then re-proposing any one of those three forces the other two to be re-submitted along with it.
   • A session shows on your calendar's day timeline once date, time, and duration are all set — even while still pending. It drops off the timeline if you drop the session or any of those three gets rejected.
   • Deposit has its own rules. Setting a deposit fires its own notification immediately (not batched into Submit Proposal). On the client's side, the Send Deposit button stays disabled until all five other fields (date, time, duration, price, location) are confirmed.

   As soon as all six fields on a session are agreed (with the deposit either received or marked "not required"), that session is confirmed — a real, locked-in appointment.

   This article keeps to the rhythm of the loop. The mechanics of each per-field modal — what the date calendar shows you, how the time view detects conflicts, the three price modes, how deposit amounts are entered, when and why to propose a per-session location — live in the per-field article: Making proposals on a project-based session.

4. 4

   The dual-card view: same booking in both tabs

   Confirmation happens at the session level, not the booking level. The moment one session has all six fields agreed, that session is locked in as a real appointment and the booking shows up under Bookings → Requests → Confirmed. If other sessions on the same booking are still being negotiated, the booking also keeps a card under Pending — same booking, two cards, both opening the same detail page when tapped. The split is intentional: Pending lists only what still needs work, Confirmed lists only locked-in appointments.

   Over a booking's life it moves between only-Pending, only-Confirmed, and both-at-once as sessions get added, fields get re-opened, or things finish settling. The session tabs at the top of the detail page mirror this — each tab has a status dot (green = confirmed, orange/yellow = in-negotiation, grey = dropped) so you can see at a glance which sessions are in which state without leaving the page. The full dot and badge taxonomy lives in Session statuses, explained.

5. 5

   When you want to walk away

   Project-based bookings don't have a single "Reject this request" button. The way to step away is by dropping.

   • Drop a single session — any session can be dropped, pending or confirmed (as long as it isn't already dropped, completed, or mid-drop). There's a small red Drop button at the top of each session card in the Management tab; tap it, a bottom-sheet asks for a reason (no-show, client cancelled last minute, you cancelled, no longer interested, emergency, health, or other) and an optional note, and the session is dropped.
   • Drop the whole booking — there isn't a dedicated button for this on project-based; drops always happen one session at a time. When you drop the last remaining active session, the system completes the cascade and the whole booking moves to Review → Dropped.
   • If a deposit was already paid on the session, the drop won't finalise until you've refunded. The session enters Awaiting Refund, you send the refund per the refund-eligibility rules snapshotted on the booking, and only then is the drop complete.

   A message is always an option. The Message button in the detail page header opens (or creates) the conversation with the client, regardless of booking state.

Frequently asked questions

Where does a fresh request land — Pending, Confirmed, or somewhere else?

Pending, always. Project-based requests don't auto-confirm at submit; they need at least one session to have all six fields agreed before the booking shows up under Confirmed at all. (Time-based bookings behave differently — those can auto-confirm at submit when there's no deposit. The shape difference between the two models is covered in the time-based-vs-project-based concept article.)

Do I have to "accept" the request as a whole before I start negotiating?

No. There's no "accept the request" button on the project-based side; your acceptance happens implicitly when you start proposing values on the session's fields. You can also drop right away if the brief tells you it isn't for you — see Step 5.

I see only one session tab — but the client's scheduling preferences mention they can do up to 3 consecutive sessions. Did the system miss something?

No, that's expected. The client never tells the system how many sessions a project needs — that's your call, based on the brief. The only session-related preference they fill is the maximum consecutive sessions they could endure if the project ends up multi-session. Project-based bookings therefore always start with one session; you add any extras yourself from the same screen after deciding how the work should be split.

I queued a few changes across two sessions but tapped back instead of Submit Proposal. Did they go out?

No — and worse, they're gone. The system warns you with an "Unsaved Changes" dialog before letting you leave. If you choose Stay & Submit, they're still there. If you choose Leave & Discard (or hit the Android back button and confirm), the queued changes are wiped. Coming back to the booking won't restore them; you'll have to set them again.

Why does the same booking show up in both my Pending and Confirmed tabs?

Confirmation is per-session, not per-booking — a booking with some confirmed sessions and some still-negotiating sessions gets a card in both tabs. See Step 4.

Can I drop a session that's already confirmed?

Yes — see Step 5 (bullet 1 for the mechanics; bullet 3 for the refund flow if a deposit was paid).

Why is there no "Drop Booking" button for a multi-session project?

Project-based always drops one session at a time — see Step 5 bullet 2. (The single Drop Booking button only appears on time-based bookings.)

Can the client change their mind on a field they already confirmed?

Not from the UI — once they tap Accept and submit, that field is locked from their side. If they want to walk it back, they have to message you and ask you to re-propose it (which you can; see Step 3).

I just opened a request and my calendar is closed. Can I still respond?

Yes. The closed-calendar banner only blocks new incoming requests (and pauses broadcast fan-out); it doesn't freeze in-flight bookings. Existing requests stay actionable — you can propose, accept, drop, message, the lot. To stop the banner from showing, re-open your calendar from your Availability & Schedule info card.

I proposed a date, the client never confirmed, and the date is now in the past. What happens?

Date, Time, and Duration get auto-rejected on the session (red on the compact card; system message "This date/time expired and was automatically rejected") and the session disappears from the day timeline. The session itself stays — waiting for you to propose new values. See Step 5 bullet 4.