> ## Documentation Index
> Fetch the complete documentation index at: https://docs.ravenna.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Tooling requests

> Turn CRM changes and go-to-market seat requests into tracked work: an intake that separates the four request shapes, self-service answers, and seats handled by access provisioning.

export const Checkbox = ({items = []}) => {
  const [checked, setChecked] = useState(Array(items.length).fill(false));
  const toggle = index => {
    setChecked(prev => {
      const copy = [...prev];
      copy[index] = !copy[index];
      return copy;
    });
  };
  return <div className="custom-checkbox-list">
      {items.map((text, index) => <div key={index} className="custom-checkbox-item flex items-center mb-2">
          <input type="checkbox" checked={checked[index]} onChange={() => toggle(index)} className="mr-2" />
          <span>{text}</span>
        </div>)}
    </div>;
};

The non-deal half of a RevOps desk is a stream of interruptions: a field that needs adding, a report someone cannot find, a seat for a new hire, a data fix. Individually each takes ten minutes. Collectively they are why the ops team never gets to the roadmap.

<Info icon="list-check">
  **Prerequisites:** a RevOps workspace with a channel and an agent. Seat provisioning needs [access provisioning](/guides/how-to/setting-up-access-provisioning) set up.
</Info>

## What good looks like

<Checkbox
  items={[
"The four request shapes are visibly different, so the ten-minute ones do not queue behind the two-week ones",
"\"Where is the report for X\" gets answered without an ops person",
"New-hire seats come through access provisioning rather than a DM to the CRM admin",
"Configuration changes have a change record, because a CRM without one is unmaintainable"
]}
/>

<Steps>
  <Step title="Separate the four shapes at intake">
    These look similar in a channel and are completely different work. Make the distinction a form field, not a judgment call for the person triaging:

    | Shape                    | Example                                           | Typical effort                        |
    | ------------------------ | ------------------------------------------------- | ------------------------------------- |
    | **Answer**               | "Where do I find pipeline by region?"             | Minutes, and the agent should take it |
    | **Data fix**             | "This account is on the wrong owner"              | Minutes to an hour                    |
    | **Configuration change** | "Can we add a field for renewal risk?"            | Days, and it needs a change record    |
    | **Access or seat**       | "New AE starts Monday, needs Salesforce and Gong" | Automatable end to end                |

    Route each shape differently. Configuration changes in particular should not sit in the same working list as data fixes, because they will always lose.

    <Callout icon="link" color="#6B7280">Learn more about [choosing between channels, views, and categories](/guides/best-practices/channels-views-categories)</Callout>
  </Step>

  <Step title="Give the answers to the agent">
    The "where is" and "how do I" questions are the highest-volume shape and the least valuable use of an ops person's time. Index the things people ask about:

    * Where each standard report and dashboard lives
    * What each pipeline stage means, and the exit criteria for each
    * Required fields at each stage, and why
    * How to log an activity, an opportunity, a multi-product deal
    * Which tools reps have by default and how to request the rest

    Write these as separate documents, one topic each. A single "CRM FAQ" page retrieves worse than eight focused ones.

    <Callout icon="link" color="#6B7280">Learn more in [structuring knowledge for AI](/guides/best-practices/knowledge-for-ai)</Callout>
  </Step>

  <Step title="Hand seats to access provisioning">
    New-hire tooling is the request shape that automates most cleanly, and RevOps usually has no idea it is available.

    Put the go-to-market stack in the application catalog: the CRM, the engagement tool, the call recorder, the enablement platform, the data provider, the CPQ tool. Tier them the same way IT tiers everything else, with the sales manager as the first approving round.

    Then the request is a form, the approval is a round, and the grant is automatic. It also means the seats are visible as entitlements, which is what lets you reclaim them when someone leaves.

    <Callout icon="link" color="#6B7280">Learn more in [setting up access provisioning](/guides/how-to/setting-up-access-provisioning)</Callout>
  </Step>

  <Step title="Fold new hires into onboarding">
    Better still, do not wait for the request. The onboarding task template can include the go-to-market bundle for a sales role, so the seats are requested before the start date rather than on day two.

    <Callout icon="link" color="#6B7280">Learn more in [employee onboarding](/guides/playbooks/hr/employee-onboarding)</Callout>
  </Step>

  <Step title="Treat configuration changes as change management">
    A CRM accumulates fields the way a garage accumulates boxes. The desk is where you stop that.

    Require three things on any configuration change request: what problem it solves, who else is affected, and what happens to the existing data. Then attach an approval, one round, the RevOps lead. The approval is not bureaucracy, it is the only thing preventing a fourth field that means "renewal risk".

    Use a task template so the change has visible stages:

    1. Confirm the requirement and the reporting impact
    2. Check whether an existing field already covers it
    3. Build in the sandbox
    4. Migrate or backfill existing data
    5. Update the field documentation in knowledge
    6. Announce the change to the sales team

    Step 5 is what keeps the agent's answers accurate. A configuration change that does not update the documentation makes the desk worse.

    <Callout icon="link" color="#6B7280">Learn more in [task templates](/guides/how-to/task-templates)</Callout>
  </Step>

  <Step title="Split the working lists by shape">
    Four views, matching the four shapes. The important one is **Configuration changes, not resolved, oldest first**, reviewed on a fixed slot each week. Without a dedicated slot, project work never beats a same-day data fix.

    <Callout icon="link" color="#6B7280">Learn more about [views](/documentation/tickets/organize/views)</Callout>
  </Step>

  <Step title="Use the volume as a roadmap">
    Once requests are categorized, the pattern is readable. Twelve requests a month to fix the same field means the field needs a validation rule. Forty questions about one report means the report needs renaming or the answer needs documenting.

    The knowledge gaps report does the same thing for the questions the agent could not answer, ranked by frequency. That is a better prioritized backlog than a planning session produces.

    <Callout icon="link" color="#6B7280">Learn more in [closing knowledge gaps](/guides/how-to/close-knowledge-gaps)</Callout>
  </Step>
</Steps>

## Where teams get this wrong

<AccordionGroup>
  <Accordion title="One undifferentiated list">
    Configuration work never wins against a same-day data fix, so it never happens.
  </Accordion>

  <Accordion title="Seats by DM to the CRM admin">
    It is invisible, it is unauditable, and the seat is never reclaimed.
  </Accordion>

  <Accordion title="Adding a field on request">
    Ask what problem it solves and whether a field already covers it.
  </Accordion>

  <Accordion title="Not updating documentation after a change">
    The agent then confidently describes a CRM that no longer exists.
  </Accordion>
</AccordionGroup>

## Next

<CardGroup cols={2}>
  <Card title="Deal desk" icon="handshake" href="/guides/playbooks/revops/deal-desk" horizontal>
    The approval half of the desk.
  </Card>

  <Card title="Reporting and briefs" icon="chart-column-big" href="/guides/playbooks/reporting-and-briefs" horizontal>
    Turn request volume into a roadmap.
  </Card>
</CardGroup>


## Related topics

- [RevOps and Sales Ops](/guides/playbooks/revops/overview.md)
- [Deal desk](/guides/playbooks/revops/deal-desk.md)
- [Workspaces](/documentation/platform/workspaces/overview.md)
- [Monitor workflows](/documentation/automate/workflows/monitor.md)
- [Playbooks](/guides/playbooks/overview.md)