This is how I would approach a new team. Names and coverage are examples, and timing depends on the team’s readiness.
- Meet the sales leaders in my coverage. I start with the VPs, directors, and managers I will work with. If I’m covering the East Coast, that means the East Coast sales leaders. I introduce myself, learn how they like to work, and then ask to join their team meetings. That puts a face to a name for the reps, lets me explain how I like to work with Sales, and builds familiarity and goodwill early.
- Learn the business intensively. I read recent escalations and approvals and ask what a standard deal looks like. I learn which concessions are easy for the company and which are hard, such as a renewal cap that is easy to give versus monthly billing that the company wants to protect. I compare what actually happens with the current approved policy, and I note where they differ. That institutional knowledge shapes everything after it.
- Meet Legal, Finance, Product, and partner teams. I want to know who owns what, how work normally moves between us, and where the friction is. I ask what should be coming to my desk that isn’t, and what is coming to my desk that belongs somewhere else. I’m also putting a face to a name and building rapport.
- Aim to ship one visible improvement by day 30. The ideal candidate is a pilot of the AI daily brief, with confirmed coverage and the right access. It depends on the team being ready for it, so it is an objective, not a promise.
- Simplify and build playbooks across days 31 to 90. I use the patterns I’ve seen to remove redundant steps. For example: do both a sales manager and a sales VP need to approve the same quote, or is one enough for a given level of risk? Or an approval that is given by email and then given again in the quoting tool, which could become one auditable approval in the quoting tool, with the stakeholders’ agreement.
- Standardize recurring non-standard requests. When the same request keeps arriving, I write a playbook entry: the request type, the recommended talk track, who escalates and who approves, and the approved fallback language.
Example playbook entry: termination for convenience
This is an illustration of the format. Only language approved by the right teams belongs in a live playbook, and none is drafted here.
| Field | Entry |
|---|---|
| Request type | Termination for convenience: the customer wants a right to cancel at any time |
| Typical pushback | As a SaaS provider, we don’t usually offer it on a multi-year term. An unrestricted cancellation right can shrink a committed term to little more than a notice period, which undercuts the value of the commitment. |
| If the customer keeps pushing | Escalate to Revenue Accounting and Legal, as the company’s process requires. |
| Approval | Per the company’s approval matrix. |
| Approved fallback language | Added only once Revenue Accounting and Legal have approved it. Not drafted in this example. |
A playbook like this turns an open-ended negotiation into a short, consistent conversation: Sales knows what to say, who to ask, and what the approved options are.