Salestouch

SalesTouch Business Operations

Use this Skill as the client-side working method for SalesTouch. The CLI model owns intent interpretation, research planning, synthesis, and the visible answer. The MCP server provides bounded identity, permission, evidence, object, and action contracts; it does not author the management conclusion.

This workflow is fully client-driven. Never call, depend on, or wait for a SalesTouch server-side conversational agent to interpret, plan, write, summarize, or recover a CLI task. The CLI model plus this Skill owns those client-side functions; SalesTouch MCP remains the governed data and action boundary.

Users describe business goals in ordinary language. Do not ask them for API schemas, internal IDs, passwords, access tokens, environment variables, or command-line setup.

Start every task

1. Call salestouch_whoami to verify the signed-in user, fixed organization, roles, manager boundary, granted scopes, and credential freshness.
2. Call salestouch_get_capabilities to learn which domains and exact operations are currently ready, disabled, or require extra authorization. Before constructing a write payload, call it again with includeOperationSchemas: true and the selected operationId in operationIds; use the returned ActionType input schema exactly. Treat this response as authoritative; never promise or invent an operation field solely because it appears in this Skill.
3. Classify the request into one or more distinct domains: commercial execution, non-sales work reports, operational forms, performance management, internal organization research, organization governance, or cross-domain management review. Do not force non-sales work into CRM objects.
4. Read before writing. Search and resolve real objects rather than inventing IDs or labels.
5. Preserve sourceHealth, evidence references, freshness, unknowns, and permission gaps in the final answer.

Choose the workflow

• Customer, opportunity, contact, interaction, or task work: read domain-workflows.md, then use the commercial workflow.
• Daily/weekly non-sales work, collaboration issues, or manager review: read domain-workflows.md, then use the work-report workflow.
• Form design, versioning, recipient preview, distribution, submission, or report generation: read domain-workflows.md, then use the operational-form workflow.
• Position, goal, plan, daily performance, support, review, correction, or learning governance: read domain-workflows.md, then use the performance workflow.
• Internal survey, audience, anonymity, research mission, interview, insight, or report: read domain-workflows.md, then use the organization-research workflow.
• Organization creation/setup, company background, departments, roles, permissions, employee invitations, member relationships, manager reporting scopes, or sales process: read organization-governance.md.
• General-manager summary, weekly operating review, cross-domain risks, or next-week actions: read operating-review.md.
• Any write, task, retry, formal action, or failed/running operation: also read write-and-recovery.md.
• Any analysis or customer/employee-sensitive output: also read evidence-and-safety.md.

Core operating rules

1. The OAuth grant is fixed to one SalesTouch organization. If the user has no organization yet, use the first-party SalesTouch create-organization path offered by the OAuth page and resume the same authorization return path after creation. Never attempt first-organization creation or organization switching through MCP tool arguments.
2. Use salestouch_search_objects for discovery and salestouch_resolve_object for exact identity. If resolution is ambiguous, show candidates or ask a focused question; never guess.
3. Use salestouch_read_object_context or the matching domain read tool before changing an existing object.
4. Never turn partial data into a complete claim. Explain unavailable sources and continue with the best verifiable result.
5. The client model may compare, infer, and recommend, but must label those statements as analysis and retain the supporting evidence references.
6. Do not expose raw private notes, anonymous respondent identity, credentials, internal traces, SQL, or inaccessible object details.
7. Never ask for or accept an employee initial plaintext password. Create employee access through invitation and first-party activation so the employee sets their own credential in SalesTouch.
8. Do not attempt unbounded exports. Respect tool limits and narrow the objective, period, object type, domain set, or manager scope.
9. If the server reports an operation as disabled, report the exact readiness reason and the available read-only path. Do not substitute another write path.

Writes and confirmation

Before any mutation, summarize the intended object, operation, important field changes, evidence basis, and expected effect. Obtain explicit user approval in the current conversation. For formal operations, obtain a separate confirmation after showing the exact high-impact effect; do not infer it from an earlier general instruction.

Every write uses one stable, unique clientRequestId. Reuse the same value when retrying the same intended mutation. Never reuse it for a different mutation. After execution, rely on returned readback or poll salestouch_get_operation_status; do not announce completion from request acceptance alone.

For a formal operation, make the exact tool call after conversational approval. The server will return formal_authorization_required with a SalesTouch browser URL bound to that operation and payload. Ask the user to approve there, then retry the same tool call with the same clientRequestId and byte-equivalent business payload. Never invent or send formalAuthorization, authorizationId, confirmedAt, timestamps, signatures, or proof fields; those are server-owned. Any target or payload change requires a new clientRequestId, a new conversational approval, and a new browser confirmation.

Tool catalog

Identity and governed objects

• salestouch_get_capabilities
• salestouch_whoami
• salestouch_search_objects
• salestouch_resolve_object
• salestouch_read_object_context
• salestouch_get_operation_status

Commercial execution

• salestouch_read_commercial_context
• salestouch_operate_commercial_execution

Non-sales work reports

• salestouch_read_work_report_context
• salestouch_operate_work_report

Operational forms

• salestouch_read_operational_form_context
• salestouch_operate_operational_form

Performance management

• salestouch_read_performance_context
• salestouch_operate_performance_governance

Internal organization research

• salestouch_read_organization_research_context
• salestouch_operate_organization_survey
• salestouch_operate_research_mission

Organization governance

• salestouch_read_organization_governance_context
• salestouch_operate_organization_governance

Cross-domain management

• salestouch_read_operating_context

Completion standard

Finish with the business outcome, actual objects or period covered, operation/readback status, evidence references, important unknowns, and any action still awaiting confirmation or capability readiness. Keep transport, schema, and internal implementation details out of the ordinary user summary unless they explain a real blocker.