Project Management After the Sale: Keep What Sales Promised

Why do sales promises get lost after a deal closes?

Promises get lost because they live in places the delivery team never sees: a WhatsApp chat, a rep's memory, a meeting nobody wrote up. The proposal usually records the price and the headline scope. The small things said to win the deal often stay out of it.

Picture an IT services company in Riyadh selling a software rollout across four branches. In the last meeting, the rep agrees to train staff at each branch and to finish before Ramadan. Neither point reaches the contract. Three weeks later the project manager plans one training session at head office and a go-live the following quarter, and only learns about the promise when the customer complains.

Teamwork, a project management vendor, lists the usual failure points in its guide to this handover:

Scope was over-promised and never recorded, so the favor that closed the deal turns into unpriced work.
Delivery cannot see the price or margin, so it has no signal about what the deal can absorb.
Nobody owns the handover, so it stalls between the two teams.
A date was promised before anyone checked whether the delivery team had room.

What should sales hand over before the project starts?

Sales should hand over four things: the commitments, the money, the people and the timing. Teamwork calls this a handoff ledger. You can keep it as a form on the deal or as a one-page document, as long as the project cannot start with a line empty.

Scope and commitments: everything promised, including what was only said out loud, and what was explicitly left out.
Price and margin: how the fee was calculated and the margin the deal was sold at.
Stakeholders and context: who bought, why they bought, who really decides, and the history with the account.
Capacity and timing: the date the customer expects, and whether anyone checked the delivery team's load before giving it.

How should the handover meeting run?

Keep it short and put sales and the delivery lead in the same room or on the same call. Teamwork suggests 30 minutes, and it is blunt about the alternative: "Forwarding the CRM record is not a handoff." Walk through the record line by line. If the rep says training is included, the delivery lead asks how many sessions, where and for whom, then writes down the answer.

Name one delivery lead who owns the handover from that point on. Before the customer kickoff, confirm with the customer who makes decisions and how they will judge success. A kickoff that opens by reading the commitments back to the customer brings disagreements out while they are still cheap to fix.

If a spoken promise changes what the contract says, or affects the price or the tax on an invoice, check with your legal or tax adviser before you rely on it.

How do you turn a signed deal into milestones and tasks?

Start from the handover record, write the milestones first, then break each one into tasks. TeamGantt defines milestones as checkpoints that mark important events, dates, decisions and deliverables, and it shows them as zero-day events on a timeline. Tasks are the work itself: they can span several days and they track progress.

Good milestones for a service project are moments someone outside the team could verify. TeamGantt's examples include phase start and end dates, key deliverables and client approvals. For the software rollout above, the list might look like this:

Customer data collected and accepted by your team
System configured and approved by the customer's project contact
Staff trained at all four branches
Go-live complete at the last branch
Final sign-off, with the account passed to support

How detailed should the tasks be?

A task should be small enough for one person to finish and clear enough that anyone can tell when it is done. "Prepare training" is vague. "Book the Dammam training room and send the attendee list to the customer" is a task.

Give each task a due date and note what it depends on, especially work waiting on the customer. TeamGantt points to client approvals and outside partners as common bottlenecks, so those deserve their own dates in the plan.

Then trace every line of the handover record to a task or a milestone. If a promise has no task under it, nobody is going to do it, and this is the check that catches the branch training in the example above.

When is a project template worth building?

A template is worth building once you have delivered the same kind of project two or three times. Asana describes a project template as a reusable resource that outlines the steps in a project plan, including milestones, due dates and the timeline, and says it can reduce work at the start of a project.

For a service business, the larger gain is consistency. A new project manager inherits the steps your best people follow, including the easy ones to forget, such as collecting access details or booking the customer's approval. Build the first version from a project that went well, then add whatever was missing from one that went badly. A useful delivery template holds:

The standard milestones in their usual order
Tasks under each milestone, with a role in place of a person's name
Relative dates, such as ten working days after kickoff
Approval points, and who on the customer side gives them
The handover questions specific to this kind of work

Who should own what on a delivery project?

Each task and milestone should have one named person who answers for it. The RACI model is a common way to sort this out. It separates those responsible for doing the work, the person accountable for its correct completion, those consulted for their opinion and those informed of the result. Some project management theories require a single accountable person per task, as Wikipedia's entry on the model notes. That rule suits service work, where a task with two owners tends to wait for each of them.

A small project rarely needs a full chart. Agreeing on a few roles at the start is usually enough:

Delivery lead: answers for dates, scope and the customer relationship during the project
Task owners: do the work and keep its status current
Salesperson: stays reachable to explain what was said, and keeps the commercial conversation
Customer contact: gives the approvals and inputs the plan depends on

How do you track progress without chasing people?

Track progress in one shared place the team updates as it works, and review it on a fixed schedule. A kanban board suits daily work: cards move through columns that represent stages, such as to do, doing and done. A Project Management Institute definition quoted on Wikipedia describes the board as a tool that shows work in progress to help identify bottlenecks and overcommitments.

Milestones suit a manager or customer who wants the overall picture. Run a short weekly review of each project and ask the same questions every time:

Which milestones moved, and which are now at risk?
What is overdue, and who owns it?
What is waiting on the customer, and since when?
Has anything come up that sits outside the agreed scope?

What should you tell the customer about progress?

Send a short update after the weekly review covering what finished, what comes next and what you need from them. A plain message on WhatsApp or email is enough, as long as it goes out on a regular day and comes from the delivery lead.

Report delays as soon as you see them. A customer who hears early has time to adjust their own plans. One who finds out on the due date is likely to call the salesperson, and that call pulls sales back into a project they thought was handed over.

What should you do when the customer asks for something that was never promised?

Log the request, work out what it costs in time and money, and get a decision before anyone starts. Rebel's Guide to Project Management describes scope creep as requirements added beyond what was originally agreed without formal authorization, and it recommends a written change control process. Its full version has eight steps. A small service company can shorten that to four:

Write the request down, with who asked and when
Have one person estimate its effect on schedule, budget and staffing
Approve or reject it with the customer, and record the reason
If approved, update the plan and any price change, and tell the team

Why keep project work next to CRM and support records?

Keeping them together means whoever picks up the customer can see what was sold, what is being delivered and what has gone wrong. When sales sits in a CRM, delivery in a spreadsheet and support in a shared mailbox, each team holds part of the story and the customer ends up repeating the rest. The connection pays off at specific moments:

A project manager checks the original deal and proposal when a customer disputes scope.
A salesperson checks progress before a renewal call, so they do not pitch to a customer with an open problem.
A support agent sees that the customer is mid-rollout and treats the question as part of that work.
A manager spots customers with both a late milestone and open complaints, and calls them first.

How does Repzo handle this?

Project management in Repzo Workstation runs on the same platform as sales and support. Project records link to deals and customers, so a delivery team can launch an implementation project right after a deal closes and still see where it came from. In the sales CRM, a deal can link to accounts, contacts, activities, projects and proposals.

You create a project from scratch or from a reusable template, then break it into milestones and tasks with owners. Milestones have a status flow and can require approvals. You assign roles and users, set assignees, due dates and dependencies, and keep comments and files with the work. Progress shows on kanban boards, lists, timelines and detailed project views.

The help desk handles tickets in the same workspace, with SLA policies and escalations, and Drive organizes project, account and support files in one place. No-code workflows can move records and notify people across modules, and Fox AI, the assistant built into Workstation, can create tasks and update records. Repzo is available in Arabic and English.

Your team still decides what goes into the handover record and who owns it. If your support process depends on linking a specific ticket to a project, ask our sales team to show you how that would work before you commit.

Frequently asked questions

Who should own a project after the deal closes?

One named delivery lead. Sales should stay reachable to explain what was said, but the delivery lead answers for scope and dates from the handover onward. A group email cannot do this job, because nobody on it feels the deadline is theirs.

What is the difference between a milestone and a task?

A milestone is a checkpoint with no duration, such as a client approval or a phase ending. A task is work someone does over time. Completing the tasks under a milestone is what lets you reach it.

How long should a sales to delivery handover take?

The meeting itself can be about 30 minutes if sales filled in the handover record beforehand. Large or unusual deals may need a second session. Hold it before the customer kickoff, so the delivery lead has time to raise questions with the rep first.

Should the salesperson attend the customer kickoff?

Usually yes. The customer trusts the person who sold to them, so having that person introduce the delivery lead and confirm the commitments makes the change of contact easier. After that, day-to-day contact should move to the delivery lead.

Does a small service business need project management software?

Not always. A spreadsheet can work for a few simple projects run by people who sit together. Software starts to make sense when projects overlap, staff work across several of them, or a manager cannot tell what is late without asking each person.

What if we discover mid-project that sales promised something we cannot deliver?

Tell the customer early and bring an alternative. Agree internally who decides, usually the delivery lead with the salesperson and a manager, then record the outcome. If the promise is in the contract, take advice from your legal adviser before you change it.

How to run delivery projects after the sale without losing what sales promised

The short answer

Key takeaways