How quickly will someone reply?
Usually within about 24 hours for a first-pass read. Urgency matters, but it does not erase the need for a clean review boundary.
After intake · what the first review actually looks like
What happens after intake.
A guided intake is not a dead drop. It is the first bounded packet in a real review flow. The goal is to get from vague inbox motion to a cleaner decision about fit, risk, missing context, and the next legitimate lane.
Usually within about 24 hours, the intake is read, normalized, and either clarified, narrowed, or advanced. This page explains that public-facing shape without pretending the process is fancier than it is.
Typical flow
The first three moves.
Not every intake becomes client work. But the good ones usually become clearer in this order.
Timeline
01 · Receipt
Submission is captured
Your intake is normalized into a cleaner packet so the first review is reading one thing, not reconstructing a thread from fragments.
02 · Review
Fit, risk, and missing context get read
The first job is not blind action. It is figuring out what kind of work this is, what matters now, and what still needs tightening.
03 · Next lane
The work narrows or advances
That may mean a bounded clarification request, a clearer technical lane, or an honest note that the fit is wrong in this shape.
Questions people usually have
The practical version.
Enough detail to reduce anxiety. Not enough ceremony to feel like a corporate FAQ graveyard.
What if the intake is incomplete?
You may get a narrow follow-up request for a few missing non-sensitive details. The aim is to make the next move clearer, not to drag you through a questionnaire ritual.
What if the issue is urgent?
Say that clearly in the intake. Urgency helps with routing, but it does not automatically justify bypassing review, boundary checks, or secure handling.
Will you ask for credentials right away?
No. First contact stays low-privilege on purpose. If deeper handling becomes necessary later, it should be explicit, narrower, and tied to a real need.
What is the client token for?
After the first intake, follow-up communication may use a client token so new context can be safely tied back to the right client lane instead of guessed from loose metadata.
What if the fit is wrong?
Then the right answer is not to fake momentum. A bad-fit lane should stay narrow, redirect, or stop rather than pretending everything is workable.
If you wanted the public process in plain language
This is it.
Clean first packet. Real review. Narrower next move. That is the public rhythm we are trying to protect.
Related pages
The support pages are one surface.
Core values, security posture, and the not-vibe-coding contrast are meant to reinforce the same first impression, not scatter it.