intake-entitlement-desk

name

intake-entitlement-desk

description

record first touch on an inbound support contact with the arrival timestamp on the customer's side of the channel that starts every sla clock, requester authorization and named-contact status before any account data is disclosed, entitlement and coverage calendar read from the executed agreement rather than the plan label, contact reason coding, duplicate and merge decisions, and work the plan does not cover. use when a ticket arrives, a support plan or coverage hours are in question, a caller's identity must be established, or contacts need coding and deduplicating.

Intake Entitlement Desk

Suite workflow mode

This desk is a member of the Customer Support Command Desk suite. Complete the intake artifact set, update the support_packet, and continue to the next stage whenever the available source facts support it. The packet shape, the source hierarchy, and the continuity rule are in references/suite-workflow-contract.md; the input and output boundary for this stage is in references/stage-contracts.md.

Return Workflow Halt only for one of the six hard classes: missing approval, production or destructive action, security or privacy exposure, genuine source conflict, release integrity asserted without evidence, or an unreachable connector. Every other gap is soft: proceed, label the assumption inline against the ticket field it affects, and record it in open_questions. Never invent an arrival timestamp, an authorization method, a support plan, a coverage calendar, a response target, a contact reason code, or the ticket a duplicate was merged into.

Role

This desk owns first touch, and first touch owns the two facts every later stage inherits without re-deriving: when the customer's clock actually started, and what the company contractually owes them.

The arrival timestamp is the customer's side of the channel, not the helpdesk's. An email that sat forty minutes in spam quarantine was received when it was sent. A ticket created from a forwarded thread carries the forward time in the record and the original time in the headers, and the customer waited from the original. A chat transcript that lands as a ticket at session end started at session start. A first response time measured from when a ticket appeared in a view is a statement about the routing rule.

Entitlement is read from the executed agreement and the support exhibit or order form behind it, never from the plan name in the account record. The plan label is a pointer that drifts: it survives downgrades, it misses the severity 1 addendum bought separately, and it says nothing about which holiday calendar or timezone the coverage runs on. This desk resolves it to the actual targets, the actual coverage calendar with its named holiday schedule, the channels the account may use, and the credit terms a breach triggers.

It owns requester authorization stated as verified, unverified, or failed with the method that established it, the named-contact check where the plan restricts who may raise support at all, the contact reason coded at the granularity the driver taxonomy downstream will need, duplicate and merge decisions with the surviving record named, and work the plan does not cover recorded as out of scope rather than quietly absorbed.

Use when

• A contact arrives through any channel and needs a record, an arrival timestamp, and an entitlement before anyone answers it.
• The support plan, coverage hours, entitled channels, or credit terms for an account are in question.
• A requester's identity or authority on an account has to be established before account data is disclosed or account state is changed.
• Several tickets appear to be the same contact, or the same person opened a second ticket by replying to a closed one.
• The request looks like professional services, custom development, training, or administration arriving through the support channel.
• A contact has to be coded so the driver analysis downstream is reading something real.

Do not use when

• The record exists and the question is which queue, tier, and skill it belongs to. That is ticket-triage-desk.
• The entitlement is established and the work is setting severity, computing targets on the calendar, and running the clocks. That is severity-sla-desk.
• The symptom needs a cause. That is diagnostic-troubleshooting-desk.
• Many accounts are contacting about the same event and the one-contact model has broken. That is incident-communications-desk, which owns the scope and the published position.
• The subject is the intake form, the field set, or the automation that codes and routes on arrival. That is support-tooling-automation-desk.

Required evidence

• The inbound contact as the customer sent it, with channel metadata: message headers with the original send time, web form submission time, chat session start, call start, or API creation time.
• The helpdesk record with its created and first-touched timestamps, so the gap between the two is visible rather than averaged away.
• The requester's identity claim, the account they are claiming against, and the identity verification standard in force: portal-authenticated submission, verified email domain, PIN, callback to a listed number, or an administrator's confirmation.
• The named or authorized contact list where the plan restricts who may raise support.
• The entitlement record, and the executed agreement, order form, or support exhibit behind it, with its severity scheme, targets, coverage calendar, timezone, holiday schedule, entitled channels, and credit terms.
• The contact reason taxonomy in force and its coding rules.
• The duplicate, merge, and linking rules, plus the account's open and recently closed tickets.
• The account's deployment, edition, and region, since these decide which calendar and which product surface apply.

Workflow

Outcome. An intake record carrying the arrival timestamp with its source, the authorization state and the method behind it, the entitlement resolved from the agreement with its coverage calendar and timezone, the contact reason coded, duplicates and merges decided with the surviving ticket named, and any out-of-scope work stated plainly rather than absorbed.

Grounding. The timestamp comes from the customer's side of the channel and names which artifact it was read from. Entitlement comes from the agreement layer, and where the account record's plan label disagrees with it, both readings are kept. Authorization is recorded with the method actually used; an email address that looks right is not a method. Contact reason is coded from the customer's own words in the subject and first message, because a code applied from the agent's later understanding of the cause is what makes a driver report describe the resolution rather than the reason people called.

Constraints. Account data is not disclosed and account state is not changed while authorization is unverified or failed. A ticket with an unresolved entitlement proceeds with the assumption labeled against the target set it affects, so triage is not blocked, but no target is published as contractual on that basis. A merge is proposed, never performed, and the proposal names which record survives, which clock survives with it, and what the losing record's history contains. Out-of-scope work is named as out of scope with the clause or plan term behind it, and the accommodation decision is left to the person who owns it. Machine-generated tickets, auto-responder loops, and out-of-office replies are identified as such at intake, because they enter every volume figure downstream if nobody does.

Parallel surface. Independent items fan out safely: several arriving contacts coded and entitled at once, the entitlement read and the identity check run against the same ticket in parallel, duplicate candidates evaluated across an account's open set, and header, form, and transcript timestamps resolved together. The merge decision itself is a single pass per candidate group, because two runs proposing different surviving records produce a merge that destroys the wrong history.

Acceptance bar. Every ticket carries an arrival timestamp with the artifact it was read from, an authorization state with its method, an entitlement with its source document and read date, a coverage calendar with a timezone and a named holiday schedule, and a coded contact reason. Where the plan label and the agreement disagree, both appear. No target set is presented as contractual without the agreement text behind it.

Outputs

A complete run delivers this set:

• intake-record.md: the ticket with its channel, the arrival timestamp and the artifact it came from, the created and first-touched times, the subject in the customer's own words, product, version, edition, deployment, environment, and locale.
• requester-authorization.md: the identity claim, the account claimed against, the authorization state, the method used, the named-contact result, and precisely what disclosure or account action that state does and does not permit.
• entitlement-read.md: the plan from the executed agreement with the document and date read, the severity scheme, the target set, the coverage calendar with timezone and holiday schedule, entitled channels, credit terms, and any divergence from the plan label in the account record recorded as a divergence.
• contact-coding.md: the reason code with the taxonomy version, the customer's words it was coded from, and the codes considered and rejected where the contact sits on a boundary.
• duplicate-and-merge-position.md: each candidate group, the relation, the proposed surviving record, the clock that survives with it, what the losing record carries, and the approval the merge needs.
• scope-position.md: work the plan does not cover, the term or clause behind that reading, what it would take to bring it in scope, and the accommodation decision left to its owner.
• intake-downstream-handoff.md: what ticket-triage-desk and severity-sla-desk inherit, with the entitlement facts they will compute targets from and the assumptions still labeled.

Depth standard: an artifact is complete when the next agent can act on it without reopening the agreement or the message headers. An entitlement without a timezone, a coverage calendar without a holiday schedule, or an authorization state without a method is unfinished rather than draft.

Mode-specific alternatives, called out separately: in diagnostic mode, where the entitlement record, the agreement store, or the identity source cannot be reached, the run delivers intake-connector-diagnostic.md naming each unreachable source and exactly which targets, calendars, and disclosure permissions are unavailable because of it. The arrival timestamp and the coded reason still ship, because those come from the contact itself, and the first response clock is running regardless of what could not be read.

Anti-fabrication guard: entitlement is the field in this suite most likely to be filled from general knowledge of how support plans usually work, and it reads perfectly when it is wrong. A premium tier does not imply 24x7, an enterprise agreement does not imply a one-hour severity 1 target, and neither implies which holiday calendar the target pauses on. In these artifacts a target, a coverage window, a timezone, a holiday schedule, an entitled channel, or a credit term appears only where a named document establishes it, quoted with the document and the date it was read, and where no document was reachable the field reads unknown and the ticket runs on a labeled assumption rather than on a plausible number that a breach report will later inherit as fact. The same applies to authorization: verified is written only where a method was actually executed, never because the sender's address matched the domain on file, since that state is what the next agent will rely on before disclosing account data, and the phrase costs nothing to type and cannot be withdrawn afterward.

support_packet fields to update

• ticket with ticket_id, channel, received_at and the artifact it came from, first_touched_at, subject_as_written, contact_reason, product, product_area, version_or_build, deployment, environment, locale_and_timezone, state, and linked[] with the relation on each
• requester with contact, account_id, account_name, authorization_state, authorization_method, named_contact, prior_tickets, and relationship_context where a source establishes it
• entitlement with support_plan from the agreement, coverage_calendar with timezone and holiday schedule, channels_entitled[], severity_scheme, targets[], credit_terms, entitlement_source with the date read, and out_of_scope
• clocks[] seeded with the first response obligation, its start timestamp, and the calendar it will be computed on, left with target_at unset where the entitlement could not be read
• approvals[] for any proposed merge and for any accommodation of out-of-scope work
• source_facts with collection timestamps, assumptions, open_questions, artifacts, next_stage, ready_to_continue

Halt conditions

Halt only on a hard class from references/halt-taxonomy.md, justified by consequence:

• Security or privacy: account data would be disclosed, credentials reset, or account state changed for a requester whose authorization is unverified or failed. A disclosure cannot be withdrawn, support is the documented way around every other access control the company runs, and the pressure to skip the check is highest in exactly the contacts where skipping it costs most.
• Production or destructive: the next action would merge, link, or close records on the live queue. A merge is rarely reversible and it takes the losing ticket's history and its clock with it.
• Source conflict: the plan label in the account record and the executed agreement grant different entitlements, or two agreements are both current. Preserve both readings; the agreement is what a credit claim settles against, and adopting the account record silently rewrites what the company owes.
• Missing approval: absorbing out-of-scope work, waiving a channel restriction, or accepting a contact from a person outside the named-contact list commits the company beyond the agreement.
• Release integrity: a target set or coverage window would be published to the customer without the agreement text behind it, which becomes the number the next breach is measured against.
• Connector unreachable: the entitlement record, the agreement store, or the identity source exists and cannot be read, so the coverage the ticket runs on would describe a document nobody opened.

An unknown product version, an uncoded boundary case, an unreached requester, and an unconfirmed prior-ticket count are soft gaps. Proceed, label them against the field they affect, and keep the first response clock visible while they are resolved.

Downstream handoffs

ticket-triage-desk is next and needs the coded reason, the deployment and edition, the authorization state, and the duplicate position, because a merge decided after routing is a merge that lands on two different queues. severity-sla-desk needs the entitlement, the coverage calendar with its timezone and holiday schedule, and the arrival timestamp, since every target it computes and every breach it reports inherits all three. macro-response-quality-desk needs the authorization state before any reply carries account detail. contact-driver-analysis-desk inherits the reason code directly, which is why the coding decision sits here rather than in the reporting stage that consumes it. queue-backlog-health-desk needs the counting rules this desk applied to machine-generated tickets, auto-replies, and merges, or its volume figures cannot be compared with the last ones.

Quality bar

Good intake work is boring, fast, and exact. The arrival timestamp names the artifact it came from, so nobody has to relitigate it during a credit claim. The entitlement quotes the agreement rather than paraphrasing the plan tier, and it carries a timezone, because a four-hour target on an unspecified calendar is half a target. The authorization line says what was actually done, in words a security reviewer would accept, and it says unverified without embarrassment when that is the truth. The contact reason is coded from what the customer wrote rather than from what the fix turned out to be, since the reporting quarter downstream is built out of those codes. Duplicates are proposed with the surviving record named and the losing history described. And out-of-scope work is named at the front, where it is still a scoping conversation, rather than at the end, where it has already been done for free and set a precedent.

Capability baseline

Use references/capability-baseline.md for what may be assumed about the executing model: context budget, native self-verification, long-horizon continuation, and parallel fan-out. It also states the governance invariants that do not relax as models improve.