Home · Solutions · Sales & marketing
Solution · Sales & marketingClosed won in the CRM, and the customer, contract and project exist before the kickoff
Won deal to a running project in an hour
When a deal is marked won, robots create the customer, file the contract, open the project plan and the kickoff channel; the deal owner confirms one summary.
Executive summary
Deals close in the CRM, then wait a week for someone to set up the customer, the project and the billing.
The design starts from a decision the company already records: the moment a deal is set to Closed Won.
The customer exists in SAP on the day of signature, so the first invoice goes out on the contract's own terms instead of a month later.
SAP customer master and project accounting; SharePoint contract library; Microsoft Planner
Business problem
Sales-to-delivery
Selling ends at the signature and delivery begins somewhere else. Between the two sits a set of tasks nobody owns as a job: the customer in the ERP, the contract filed where it can be found, a project with a budget and a rate card, a kickoff, a first word to the client. Each is small. Together they take days, and they run on people chasing each other.
Almost every field involved already exists in the CRM. Legal name, registration and VAT numbers, billing address, payment terms, value and the signed document sit on the deal record, because the salesperson needed them to close. Finance retypes them, the project office retypes them again, and retyping is where the mismatches begin: an invoice addressed to the parent company, a project budget that does not match the contract, a purchase order number nobody captured.
The client experiences the gap as silence, two or three weeks in which the only contact is administrative, and that is when a new customer decides whether the buying decision was sound. The CFO carries the rest: work delivered against no project code, an unbillable first month, a contract nobody can produce when someone asks about the notice period.
How it works today
This is the handoff we usually find in services companies, whatever the CRM.
- PersonThe deal owner moves the opportunity to Closed Won and emails finance, the project office and the delivery lead, contract attached
- WaitingThe request queues in a shared mailbox behind everything else that arrived that day, typically two to five working days
- PersonA finance assistant creates the customer in SAP, retyping name, registration and VAT numbers, address and payment terms from the contract
- PersonThe project office opens a project, invents a code, copies the scope from the offer and asks twice for the rate card
- SystemThe signed PDF is saved wherever the deal owner keeps documents: a personal OneDrive folder, sometimes the CRM
- Risk of errorConsultants start before the project code exists and book hours to a placeholder corrected at month end, if anyone notices
- WaitingThe kickoff is arranged by chat once everyone confirms the client contact, two to four weeks after signature, and until then the client hears nothing
Why the current process costs more than it appears
Nobody planned this work; it accumulated.
- Three hours per deal is only the recorded part. The chasing around it and the second and third versions of the handoff email sit in nobody's timesheet.
- Nobody owns the handoff end to end, so it falls to whoever is asked first, and quality depends on which finance assistant picked it up.
- A setup error is paid for all year: wrong payment terms or the wrong legal entity become an argument on every invoice to that client until someone traces it back.
- Delivery starts from the offer rather than the contract, because the offer is what circulates by email. Scope agreed in the last negotiation round arrives late, and the correction is called a change request.
Cost of inaction
Delivery starts before the paperwork catches up, month after month. The handoff still happens, most deals still reach delivery, and the cost stays invisible because it is spread across three teams and never appears in anyone's budget. What does show up is the rest: the first invoice that leaves in the second month, the argument about payment terms with a client whose master data was typed wrongly in March, the change request that exists only because delivery worked from the offer.
The quieter exposure is that growth is expensive. Every additional fifty deals a month adds 150 hours of administration, answered by hiring or by letting the setup queue lengthen. Both cost money, and only one is visible to the board.
A plausible organisation with realistic proportions. The figures are there to be recalculated on your data; they are not a client result.
An IT services company with 600 employees delivering from three centres in Central Europe; Microsoft Dynamics 365 Sales for the pipeline, SAP for finance and project accounting, Microsoft 365 E3.
Around 140 deals reach the won stage each month: new logos, renewals, framework call-offs and change requests, from a two-week piece of work to a twelve-month managed service.
The deal owner emails a handoff to finance, the project office and delivery; customer master, project and rate card are typed by hand from the contract and the offer.
About three hours of administration per won deal across the three teams, plus the waiting between them; engagements are billable days before they are billable in the system.
The won stage starts a robot that validates the deal record, sets the customer up in SAP, files the contract on SharePoint, builds the plan in Microsoft Planner, opens the kickoff channel in Microsoft Teams and sends the welcome email. Credit limits, new legal entities and non-standard terms go to a person.
In the modelled case, standard engagements move from signature to a billable project inside an hour, and 420 hours a month return to selling, invoicing and running projects. The figures are a model, not a measurement.
Proposed solution
The design starts from a decision the company already records: the moment a deal is set to Closed Won. UiPath Integration Service holds an event trigger on the CRM, so that stage change puts one item into an Orchestrator queue with the deal, the account and the signed document. For Microsoft Dynamics 365 Sales and Salesforce the connector is packaged; for Pipedrive we connect through its REST API using Connector Builder.
Before anything is created, the robot checks the record against the rules finance and the project office actually apply: signing entity, registration and VAT numbers, payment terms, value, engagement type, delivery owner. If a field is missing, the deal owner gets one Teams task naming it. The questions are asked once, at the win, by the system that will use the answers.
Then the setup runs in one pass: the counterparty is looked up in SAP and the business partner created or completed, the contract is filed to SharePoint with its metadata, the plan is built in Microsoft Planner from the engagement template, and a Teams channel opens with the handoff checklist. We keep it deterministic on purpose, so there is no AI in the flow and no model to govern.
UiPath Integration Service event triggers on Microsoft Dynamics 365 CRM and Salesforce; UiPath Orchestrator queues, retries and audit; UiPath connectors for Microsoft Teams, Outlook 365 and OneDrive & SharePoint; UiPath Action Center tasks inside Microsoft Teams; Microsoft Planner through Microsoft Graph; Microsoft Teams Approvals app
The field-completeness rules, the customer master mapping and duplicate check against SAP, the contract metadata model, the plan and channel templates per engagement type, the checklist, the approval routing for credit and non-standard terms, the write-back to the CRM
SAP business partner creation and lookups through the UiPath SAP BAPI and SAP OData connectors, with SAP GUI activities only where a field has no interface; Pipedrive through its REST API using Connector Builder
How the automated process works
- AutomationThe CRM event trigger fires when the deal reaches Closed Won; deal, account and signed document enter an Orchestrator queue
- SystemThe robot tests the record against the handoff rules and flags every field that is missing or inconsistent
- PersonAnything missing goes back to the deal owner as one Teams task naming the exact fields, before any object is created
- AutomationThe counterparty is looked up in SAP; the business partner is created, or completed with sales area, terms and billing data where it exists
- AutomationThe contract is filed to SharePoint with its metadata, the Planner plan is created from the engagement template, and a Teams channel opens with the checklist as its first message
- PersonCredit limit, new legal entities and values above the delegated threshold are approved in Teams before the customer is released for invoicing
- AutomationThe welcome email goes out from the account manager's mailbox, and the CRM record is written back with the created objects
Human-in-the-loop model
Automation handles
- Validation of the deal record against the fields finance and delivery need, with one named request back to the deal owner
- Customer master creation and updates in SAP, including the duplicate check against existing counterparties
- Contract filing with metadata, plan and channel creation, the checklist, the welcome message and the write-back to the CRM
People decide
- Credit limit and payment terms outside the standard matrix, approved by finance in Teams
- Whether a new legal entity may be created and released, with the screening the company already requires
- Who delivers, and any commercial terms that differ from the standard contract
Before and after
Systems and integrations
Where a rule suffices we do not use a model. Where judgement is needed, a person decides.
Inputs
- the deal record at the won stage (Microsoft Dynamics 365 Sales, Salesforce or Pipedrive)
- the signed contract attached to the deal
- engagement type and rate card
- the delegation matrix
Automation layer
- UiPath Orchestrator
- UiPath Robots
- UiPath Integration Service
- UiPath Action Center
- UiPath Insights
Target systems
- SAP customer master and project accounting
- SharePoint contract library
- Microsoft Planner
- Microsoft Teams
- the CRM record written back
Human touchpoints: Action Center tasks in Microsoft Teams; Microsoft Teams Approvals for credit and non-standard terms; the engagement channel and its checklist
Technologies used
event trigger on the won stage; reads the deal, account and attached contract
Aone queue item per handoff, rule execution, retries, audit record of every created object
Aduplicate check and business partner creation with sales area, terms and billing data
Acreates the channel, posts the checklist, files the contract, sends the welcome email
Amissing-field requests, credit decisions and new-entity releases
Athe engagement plan from a template, with owners and due dates
Ahandoff cycle time, exception rate and volume by engagement type
AIllustrative economic model
Start by questioning the assumptions.
Three teams contribute the 180 minutes between them; it is not one person's task, and it is an illustration from typical ranges rather than a client measurement. €35 is a fully loaded hourly cost for that mixed group of sales-support, finance and PMO roles in Central Europe. We model capacity released, not posts removed.
Run the numbers on your data
An illustrative estimate from your own inputs. It models released capacity; it is not a promise of savings.
Business benefits
- The customer exists in SAP on the day of signature, so the first invoice goes out on the contract's own terms instead of a month later
- Consultants book time to a real project code from their first hour, which removes the month-end correction of placeholder bookings
- The contract is findable by client, value, term and notice period, rather than sitting in one person's mailbox
- The client hears from the company within the hour of signing, while the buying decision is still fresh
- Sales stops doing back-office work: the deal owner confirms a summary and goes back to selling, and quarter-end peaks are absorbed without borrowing people from finance
The management view
- Signature-to-setup becomes a measured number per engagement type, so the board discusses a figure rather than the last complaint that reached it
- Delegation is applied on every deal: credit limits, non-standard terms and values above threshold reach the right approver with a record of the decision
- The handoff stops depending on two experienced people, and a rise in deal count no longer converts into a rise in back-office headcount
Board-level KPIs
Security and governance
Control is not an add-on.
- The robot works under its own SAP identity, limited to customer master data in the company codes in scope; every field it writes is attributable to a named run in Orchestrator
- No password is written into a workflow. The robot's CRM, SAP and Microsoft 365 identities are drawn at run time from the credential store your environment is configured against, Azure Key Vault or CyberArk in most of our clients
- Contract documents and client-contact data stay inside your Microsoft 365 tenant; the orchestration layer and its logs run in the UiPath Automation Cloud EU region
- Creating a customer and releasing its credit limit stay two steps with two approvers, and every object carries the deal identifier, so a customer record, a contract file and a project trace back to the decision that produced them
Why now
The administrative load follows the number of deals, not their value: a two-week change request carries almost the same setup checklist as a twelve-month contract, and in this model that costs €14,700 a month
Signature-to-kickoff is the part of the customer journey the company controls completely and measures least, and it is exactly when a new client forms an opinion
The integration work that used to justify a project of its own is now configuration: CRM event triggers, SAP BAPI and OData interfaces, Teams channel creation and Planner plans from templates are standard connector operations
Relevant executive roles
Deal owners stop spending the week after a win on administration, and handoff quality no longer depends on who picked up the email
Master data is created once from the contract, the first invoice leaves on the agreed terms, and the days between signature and billing become manageable
Projects arrive with a code, a plan, a channel and the contract attached, so the team starts on the agreed scope, not the last version of the offer
Common questions and objections
They are not extra fields. Each is something finance or delivery asks for by email in the days after, and all come from the contract just signed. The question is asked once, at the win, instead of three times over a week.
The trigger and the field mapping are the only CRM-specific parts; the SAP, SharePoint, Planner and Teams steps do not change. Companies often build this during a migration because it forces the handoff rules to be written down first.
Then the customer master step becomes a check rather than a creation, and the value shifts to the project, the contract file and the kickoff. The flow branches on engagement type, so a renewal runs a shorter path.
When this is not the right solution
- A handful of large deals a month, where one well-run handoff meeting is cheaper and better than any automation
- The won stage in the CRM is set retrospectively or unreliably, so there is no trustworthy event to trigger on; the data hygiene work comes first
- Every engagement is negotiated from scratch with its own commercial model, leaving no standard setup for a template to reproduce
A question for the next management meeting
When a client signs, how many working days pass before that client exists as a customer, a project and a first invoice in our systems, and who in this room owns that number?
Implementation approach
We start with one slice of the process and extend only once it is proven.
We deliver
- A working session with sales, finance and the project office to write down the handoff rules now held as habits
- The field-completeness check on the deal record and the request-back task in Teams
- The customer master mapping to SAP, the duplicate logic and the handling of rejected postings
- The contract library and its metadata model, the Planner and Teams templates per engagement type
- The approval routing for credit and non-standard terms, a pilot on one engagement type, a runbook for sales operations
We need from you
- The last two or three months of won deals with the setup steps each one required
- A process owner in sales operations and a counterpart in finance for the master data rules
- Technical accounts for the CRM, SAP and Microsoft 365, plus the delegation matrix
- The engagement types you want to distinguish, with the project template for each
Stages
Discovery
Handoff rules, engagement types, required fields and the real exception cases
Design
Target flow, customer master mapping, metadata model, templates, approval thresholds
Build
Trigger, rules, SAP integration, SharePoint, Planner and Teams touchpoints
Validation
Replay of recent won deals, exception handling, acceptance by sales operations and finance
Go-live and tuning
Controlled start on one engagement type, then the rest; monitoring and rule tuning
Quick win. Effort is driven by how many engagement types need their own template and how strict the SAP customer master rules are, not by the automation itself.
What happens in your company between the signature and the kickoff?
Send us the last month of won deals with the setup steps each one needed and who performed them. We come back with a written map of the handoff and the fields that must be right at the moment of the win.
Map your won-deal handoffThe neighbouring process usually has the same problem
Enquiries wait for someone's Monday sort while a competitor calls the buyer on Tuesday.
View solution Operations & qualityFrom contract to handover without a missing documentStop moving handover slots on Friday because a document, a fitting or an invoice was nobody's job until Saturday.
View solution Management & planningFrom project hours to the invoiceConsultants log hours late, finance rebuilds the billing in Excel, and invoices leave three weeks after the work.
View solution Sales & marketingCRM data hygiene: duplicates, stale deals, missing fieldsThe pipeline review starts with an argument about the data, not about the deals.
View solution Case studyThe sales assistantThe agent reads the enquiry, builds the quote from SAP prices and availability, enforces the discount policy and prepares a brief before every meeting.
View case study Case studyB2B client onboarding in 24 hoursA new client does not stop being “hot” just because your process has nine steps.
View case studyIndustries we deliver this in most oftenManufacturing & industryServices & IT