Intake and the front desk

A front desk turns an incoming message into a request that someone can own. It preserves the intended outcome, recognizes missing information, and identifies stakes before the request reaches a worker. Good intake helps a coordinator see what needs a decision and helps specialists avoid starting the wrong job.

CJS's internal Secretary instructions provide the case study for this part. Secretary receives incoming requests through HQ intake, routes review items, and escalates consequential requests. It never does the work itself. That last rule makes the front desk a distinct responsibility rather than another general-purpose worker.

You will practice the pattern with a local request log. The examples are invented teaching cases, not real CJS tasks. No API call, message, publication, or deployment is needed to complete the lesson.

What the CJS intake pattern actually says

CJS's internal Secretary document describes several entry paths into HQ intake. Owner or outside requests are logged by Secretary. HQ rules can create tasks. Staff-created dashboard tasks already have a manual routing choice. Pushed business events can be informational or need review, depending on whether their types are known.

This variety matters because a new event does not always mean “ask an agent to do something.” Some events carry information; others create follow-up work through existing rules. A front desk should preserve that distinction rather than invent a task for every notification.

For requests needing routing, the document describes three important outcomes:

These labels describe routing. They do not prove that the requested work has happened or that every downstream action is approved. In the documented automatic path, Infrastructure owns requests for server-room or deploy-pad, while other routes default to Optima. A station and an owner are separate pieces of information.

Treat the configured threshold as a detail of the documented CJS implementation, not a universal recommendation. A high confidence score describes the routing mechanism's assessment. It cannot establish that a person authorized a payment, release, or outbound message.

Capture the outcome before choosing a route

A useful request record begins with the result the requester wants. “Course page” is a subject. “Review the supplied course introduction for clarity and return a local revision” is an assignment.

For this exercise, use the following fields in a local note:

• Reference and title: a short way to identify the request.
• Requested outcome: what the requester wants back.
• Scope and materials: what may be examined or changed locally.
• Stakes: any consequential actions the request includes.
• Proposed route and next owner: who should handle the next step.
• Open question or decision: what still prevents assignment or execution.

This is an Academy practice template, not an exact copy of CJS intake fields. Its purpose is to support a good handoff without reproducing an operational system.

CJS's internal instructions say to avoid personal data in request titles and details and refer to a record instead. Apply that principle to your exercise. Use an invented reference such as “Demo: inquiry review,” and keep sensitive content out of the log. The CJS rules also require demo or test items to begin with “Demo:”. Here, all such items stay in your local exercise.

Check stakes before accepting an automatic route

CJS uses a never-JEV list to intercept requests involving consequential actions. Secretary must not execute escalated items. Escalated requests stay on an authorized escalation path until resolved.

For your local front desk, check the complete never-act-alone list:

• Money: payments, prices, refunds, and financial changes.
• DNS, infrastructure, and deploys: domains, servers, firewalls, configuration, and releases.
• Sending: email, social messages, Slack, and other outbound communication.
• Publishing: making content available to an audience.
• Deletion: removing data or material.
• Access: accounts, permissions, and roles.

Read for intended consequences, including ordinary phrases. “Let the customer know” may mean sending. “Make the new version available” may mean publishing or deployment. “Clean out the old records” may mean deletion. If the requested action is unclear, record the uncertainty and ask through the coordinator rather than treating ambiguity as low stakes.

A routing rule must not bypass this boundary because another part of the request looks routine. “Rewrite the introduction and publish it” contains both preparation and publication. Capture the full request, flag publication, and send the consequential decision through the appropriate path. Do not quietly remove the publication flag to make the item easier to route.

Three local practice requests

1. A clear preparation task

Demo: introduction revision. “Revise the supplied introduction for clarity. Return a local draft; no external action requested.”

In a practice office, a known rule could propose the content route. Record the desired artifact and the next owner. If the draft contains claims that need checking, include a research dependency. The routing result does not assert that research or editing is already complete.

The useful intake outcome is a bounded assignment: supplied material, a local deliverable, and an owner who knows what to return. There is no reason to add publishing to the task simply because the draft might eventually be published.

2. An uncertain request

Demo: page concern. “Something about this page is wrong.”

The front desk cannot reliably choose between factual review, copy editing, design review, or technical investigation from that sentence alone. Leave it in review and identify the missing information: which page or supplied artifact, what behavior or wording is wrong, and what result is expected.

The CJS Secretary rule is to leave uncertain items in review and ask Optima. Your local equivalent is to ask the coordinator one focused question that narrows the assignment. Do not fabricate a diagnosis to create the appearance of efficient routing.

3. A consequential request

Demo: launch announcement. “Publish the revised page and send an announcement.”

This request touches publishing and sending, and may also involve deployment depending on the release process. In the CJS pattern, it belongs in escalation. Secretary does not send it directly to a worker as an approved execution task.

A useful escalation note states the requested outcome, the affected categories, what preparation is available, and which decision is pending. Urgency can be recorded, but urgency does not grant authority. The authorized decision maker can resolve the request and define any approved execution scope.

Keep review separate from escalation

Review asks, “Where should this request go?” Escalation asks for a decision that the front desk cannot make. Combining them into a single miscellaneous queue hides the difference between uncertainty and authority.

A review item may become routable once its goal or materials are clarified. An escalated item still needs the authorized decision even if its destination is obvious. Everyone may agree that Infrastructure would perform a release; that agreement does not itself approve the release.

CJS's internal Secretary document also describes JEV operating alongside non-escalated items in shadow mode: suggestions are logged beside the rule decision. In that documented mode, a suggestion does not control the route. The relevant lesson here is the separation between observing a recommendation and granting it authority. This part does not require integrating a decision service.

Close the intake loop with a usable handoff

When a request leaves review, record the chosen route and why the next owner can act within scope. Include the artifact or reference, the expected deliverable, unresolved dependencies, and any action limits. If it remains escalated, state who must decide next.

Keep status truthful. CJS's internal reporting guide requires real-state updates, and the Office floor is a staff dashboard. “Waiting for a publication decision” is a useful state. “Launch complete” is inaccurate if only the draft exists. A public teaching exercise should not expose staff dashboard contents or imitate live activity.

The front desk's success is a request another role can understand. It should not complete the specialist's work merely to make the queue shorter. Nor should it invent extra requests from informational events.

Quiz

Q1. What is the difference between review and escalated in the CJS intake pattern?

• They are two names for the same queue.
• Review is for urgent items and escalation is for routine ones.
• Review handles uncertainty about where a request goes. Escalation asks for a decision the front desk cannot make.
• Escalated items can be resolved by the front desk once the destination is obvious.

Q2. A request says "Something about this page is wrong." What should the front desk do?

• Guess the most likely problem and route it to the matching specialist.
• Leave it in review and ask one focused question to find out what is wrong and what result is expected.
• Escalate it, because every unclear request is consequential.
• Close it, because it has no clear outcome.

Q3. How should a practice or demo request be titled?

• With the customer's name, so it is easy to find.
• With an email address, so replies reach the right person.
• With "Test" and the current date.
• With a "Demo:" prefix and no personal data, for example "Demo: inquiry review".

Sources and attribution

CJS's internal Secretary instructions supply the entry paths, routing outcomes, documented threshold, escalation rules, privacy guidance and shadow-mode behaviour. The internal agents README establishes the front-desk and Infrastructure responsibilities, the Office reporting and Office status documents support truthful staff visibility, and the Codex helper guide supports the separation of preparation, review and deployment. These documents are not publicly available. Local templates and examples are Academy teaching adaptations.