Describe the job, not the technology.
Start with the recurring work that pulls people away from customers, delivery or decisions. You do not need to choose a model, prompt or workflow before the first conversation.
What should be complete at the end of a normal task?
How often does the work happen, and what does a typical day look like?
Where do approved facts come from, and who is responsible for keeping them current?
Who can approve an exception, a public response or the next stage of work?
Do not put passwords, API keys, card details, raw customer records or restricted documents in a public request.
Agree the rules before work starts.
We turn the brief into a role proposal. You can inspect the expected outcome, proposed inputs and outputs, access limits, approval points and evidence for that version.
The useful result and the limits of the role.
The minimum information or system scope proposed for review. A scope approval does not create a connection.
The decisions and exceptions that must always return to a person.
The version, test context and limitations that support the review.
Start small enough to check.
The first scope is deliberately limited: one to two supervised hours and two to three agreed low-risk actions. It is not automatic production activation or open-ended access.
The output, the working boundary, the role version and the next owner decision. You can refine the scope, pause or decide not to continue.
Give the role current facts and a practical human handoff.
A Concierge Manager is a proposed inbound role for factual requests such as restaurant delivery, retail orders, automotive-parts questions or local-service booking. It starts as a reviewed brief: current facts, a named handoff and actions that must remain human before any channel is connected.
Business name, selected Concierge profile, customer outcome, expected inbound volume and supported languages.
A named catalog or service-data source, plus who owns its freshness and accuracy.
A named person for exceptions, customer requests for a human, unknown facts and final decisions.
Written rules for the minimum data classes, channels and actions that may be reviewed.
It does not invent price, availability, fitment or service terms. Payment/card data, refunds, complaints, emergency requests, unknown facts, final service price or slot, and a request for a person always require human handoff.
Plan, review, improve and pause.
Where commercial access has been separately verified, Generoy is a controlled workspace for a selected Concierge direction, implementation brief, proposed minimum system/data scope, owner decisions and safe tone or handoff settings.
The role brief, selected direction, proposed scope, owner decisions and a short configuration activity history.
A proposed minimum scope for catalog, CRM, order or booking, messaging, telephony/SIP or delivery planning.
OAuth, provider credentials, a phone channel, messaging, CRM, payment, external order or booking submission.
Passwords, tokens, card data, raw conversations, merchant records or connected-system responses.
Know when the role must stop and hand over.
Important actions do not disappear behind an automation label. The owner keeps responsibility for decisions with legal, financial, safety, access or customer-commitment consequences.
The role works inside a documented scope. It stops for a person when the situation needs judgment, a current fact or a commitment.
- Person requestedTransfer immediately.
- Fact is missingDo not guess about price, availability, fitment or policy.
- Money or commitmentPayments, refunds and external commitments need approval.
- High impactMedical, legal, credit and employment decisions stay with people.
