The service's website says "We connect any accounting system." A sales manager promises the client a report built on their own measures, and then at the first meeting Yernar, who runs delivery, says the service works with only two systems and standard tables. The client has already spent time preparing an export. In the CRM the deal is closed as "product did not fit", although the company created the expectation itself.
This is still the Almaty reporting service for small retail chains from the strategy lesson: a 60,000 ₸ monthly package, 20,000 ₸ variable delivery cost, 40,000 ₸ contribution. The prices, terms and numbers are made up. Product, sales and marketing need a shared process so that the client hears the same offer from the first ad to the finished report, and any mismatch goes straight to the person who can fix it.
One offer from promise to service
Terms from the offer card
Before the pilot
Check system, version and export format
The specialist accepts data and agrees the start
Pilot
7 calendar days at no charge
One sample report on agreed data
After the pilot
Separate agreement to the monthly service
60,000 ₸ a month, paid separately
New integrations and custom reports are outside the pilot. The coordinator updates all touchpoints.
One offer card
An offer card is the list of what people are allowed to promise. It has an owner, a version number and a date of last change. A sales manager can retell the service in the client's language, but any new feature or deadline is first confirmed by whoever owns that part of the product. Otherwise everyone sells their own version of the service.
For our service, the card looks like this:
| Part | What we promise |
|---|---|
| Client | A small retail chain that needs to bring sales and assortment data together |
| Compatibility | Two accounting systems from a confirmed list; version and export format are checked before the pilot |
| Start | The specialist has received an export the client agreed to share and set a start date with them |
| Pilot | Seven calendar days free, one sample report on agreed data |
| Scope | Standard tables; a new integration or a custom report is not part of the pilot |
| After the pilot | The client separately agrees to the 60,000 ₸ monthly service and pays for it |
| Owner | The product owner confirms the terms; a coordinator updates every touchpoint |
The pilot is free here, but it could be paid, and then you say so before the form is submitted. Either way, the card needs the moment the days start counting, the result and the next step. Otherwise "seven days" on the website and "a week once we sort out the data" from Yernar turn into two different services.
Compatibility is confirmed on a real export. The system's name in the lead form is not enough: one system can come in different versions, with different access rights and data structures. Until Yernar has opened the file, the sales manager promises a check of whether a connection is possible, not a finished integration.
What changes with the card
When the terms change, the coordinator lists every place they appear: ads, the landing page, the form, the lead confirmation, the pilot email, the deck, CRM prompts, support reply templates. Each place gets a person who will update it. That way the new version does not stay a file only the people at the meeting know about.
Promises already made are handled differently. A client may have signed up from an old ad, and a new link does not undo what they were told yesterday. The sales manager explains what has changed, works out with the product owner an option the service can deliver, and records the agreement on the deal card.
Product Marketing Alliance places market understanding, positioning, sales enablement and launches under product marketing. In a small team these tasks may be split between different people. The coordinator is there to make sure changes reach every place; what the product can do is still decided by its owner.
When a lead can be passed on
A suitable lead for the service is a company with a task from the card, supported data and a willingness to discuss a pilot. A phone number or email is needed to get in touch, but it answers none of those questions. So the CRM gets the fields without which the next person cannot do their part.
Every lead needs an owner, a next step and a due date. The sales manager sees which promise the person read in the ad or on the page they came from, and what is already known about their task. If the export needs checking, that goes to Yernar, and until he replies the status says so: compatibility not confirmed.
Response time is set by working hours and by what the client expects. If Zhanar's sales team only works during the day, do not promise an evening lead a call within minutes. Say on the page and in the confirmation when they will actually call back, and the queue and overdue steps will show in the CRM.
Reviewing a hundred enquiries
For the reconciliation, take 100 unique new leads whose agreed handling time has already passed. This is a different set from the channel table in the P&L. On the review date, each lead falls into exactly one group:
| Status | Leads | What to do next |
|---|---|---|
| Fit the task and data | 60 | Follow them through to the pilot and payment |
| Need an unsupported system | 20 | Find where the compatibility promise came from |
| Not enough information to assess | 10 | Assign a follow-up and a due date |
| Nobody handled them | 10 | Restore the handover and ownership |
60 + 20 + 10 + 10 = 100. Confirmed fits make up 60% of the whole set. If you count only the 80 leads that could be assessed, you get 75%, but the other twenty can move the picture either way. Write "75% of leads are qualified" in a report and twenty leads nobody knows anything about yet disappear from it.
Repeat enquiries from one company are merged by an ID agreed in advance. Channels are compared over the same assessment window. A fresh lead the sales manager has not reached yet should not land among the bad ones by default. And closed leads keep their reason: unsupported system, different task, timing did not work, price did not work. Each reason calls for its own action.
What a wrong promise costs
Suppose the sales manager and Yernar together spent 30 minutes on each of the twenty companies with an unsupported system. That is ten hours. At an internal rate of 5,000 ₸ an hour, the service tied up 50,000 ₸ worth of time before explaining a limit it could have shown on the website.
That is an estimate of time: neither money nor sales vanished because of it. If salaries are fixed, they are already counted in the fixed costs of the P&L, so there is no need to subtract 50,000 ₸ from profit a second time. Fewer such conversations free up time for suitable clients. Whether that time turns into extra payments depends on what it is spent on.
Look for the cause in the enquiries themselves. The client came from an "any system" ad: fix the ad. The client knew about the limit but still asked for a new integration: the request goes to product as research material. Twenty such requests are not yet a reason to build the integration: first understand the task, the willingness to pay, the support cost and whether it fits the strategy.
A shared meeting ends with an action
Altynai brings the promises and lead sources to the meeting. Zhanar brings statuses and reasons for losing deals. Product confirms that the service can deliver. Together they pick an action: remove a phrase nobody has confirmed, change a form question, name an owner for the queue, or research a new task.
The action has an owner, a due date and a way to check it. Once the ad is fixed, walk the client's path yourself, and later review a comparable group of enquiries. If there are fewer leads but a higher share of fits, the final decision rests on payments and costs. One convenient metric does not replace the whole path.
Payments are reconciled against financial records and the deal ID. The same purchase can show up in the ad account, the CRM and the payment system, so their revenue is never added up. The team's shared result is a delivered, paid service and the contribution after costs, while each stage keeps its own quality and speed metrics.
Exercise: forty bad leads
Take the ten most recent enquiries in your own project. Put next to each one the ad or other source, the landing page, the sales manager's first message and the CRM card. Find where the promise diverges, or confirm that everything says the same thing. Write down who will fix the mismatch and by what criterion a lead can be passed to the next person.
Now Talgat, the owner, looks at the table of a hundred enquiries and says: "Forty are bad, switch the channel off. And the ten nobody handled cost us 600,000 ₸ in revenue." What needs correcting in that conclusion?
"Forty bad" lumps three different groups together. Twenty companies need a system the service does not support, ten lack information, and ten were never handled. Each group needs its own action. How many sales the unhandled ten would have brought is unknown, and they cannot be counted as ten sure payments. If two had paid, first-month revenue would have been 120,000 ₸, delivery 40,000 ₸ and contribution 80,000 ₸ before acquisition and fixed costs. That is a scenario: there is no data on the clients themselves.
The answer to Talgat ends with a list of owners: who fixes the promise, who clarifies the data, who restores the handling. The channel's fate is decided after this review, on comparable payments and costs.