The customer reads the document, not the database

The name looked right in the application. It did not look right in the customer's quote. Some characters had disappeared and others were broken. The colleague who entered the name had done the expected check, and the document-generation team could show that a file had been produced. We had evidence for two successful activities and an unsuccessful customer result. As CIO, I had to examine the way we had defined completion rather than ask which team could be assigned the failure.

At Nerqali Floor Stores, the quote helps a customer examine a proposed purchase before it becomes an instruction for several other people. Names, material descriptions and room references matter because the document connects a conversation with later work. A defect can therefore be more than a cosmetic inconvenience. It may require the customer to ask for clarification, make the proposal harder to compare or leave colleagues uncertain about the intended wording. The fact that someone inside the company can read the original entry does not settle any of those consequences.

## A file can open and still fail its reader

Our 2022 review examined 240 quotes and found seventy-eight with missing or broken characters in names or descriptions. Assamese and Bengali text made the weakness particularly visible. The data-entry application supported the intended text, but the production and printing paths did not consistently preserve it. We had treated the passage from one stage to another as a technical handoff whose success could be established by the existence of an output file. That was a narrow test for a document meant to be read and accepted by a person.

The immediate suggestion was to ask staff to retype affected fields in Roman letters. I understood the operational attraction. It could make a troublesome quote easier to issue while a larger repair was being considered. But treating that workaround as the service design would move the burden to the customer and introduce another transformation of information. Names are not interchangeable labels merely because our system finds one rendering more convenient. Product wording also needs a considered account, not an improvised substitution made to get past a technical defect.

We approved ₹42 lakh for document-generation changes, appropriate font support and review of representative output. The continuing support expense was ₹8 lakh a year. I wanted those figures visible because multilingual service requires maintenance, not only a launch event. A new product description, a different output route or a revised component could expose another problem. The investment was not justified by pretending that the first successful demonstration would remove the need to examine the service again. It was justified by making a necessary part of the customer experience more reliable and reviewable.

The test had to reach the output the customer would actually see. We followed selected documents through electronic delivery and the printing routes used in showrooms. That exposed why a screenshot from the originating application was inadequate evidence. We also needed a clear way for staff to report what they found. A missing character, an unreadable print and an incorrect description could all appear as a complaint about a quote, but they called for different repairs. Keeping those distinctions made the review useful to the people responsible for acting on it.

## Meaning needs an accountable reviewer

Technical checks can identify many rendering failures. They cannot establish that every plausible-looking sentence means what the commercial team intended. Colleagues competent in the relevant languages therefore worked with commercial staff on representative documents. Their role was not decorative approval at the end of a technology project. They helped define what a useful document needed to preserve and what kind of correction should return to the commercial owner. I did not want the label multilingual to imply that the application had somehow acquired the judgement of a translator or a product specialist.

Sanjay Qervathi, our commercial head, retained responsibility for the customer wording. My team owned the technical production path and evidence about its behaviour. That division required cooperation, but it was clearer than asking IT to certify the entire meaning of the quote. It also prevented the opposite mistake: treating every language complaint as a software defect that commercial colleagues could send away without review. The customer experienced one service. Internally, the service needed several kinds of expertise whose responsibilities were connected rather than blurred.

In the later sample of 260 documents, we found no missing-character defects. Fourteen still required meaning or wording corrections before final acceptance. I regarded both observations as necessary. Omitting the fourteen would have made the technical improvement look like a complete account of document quality. Calling the whole project unsuccessful because some human review remained would have ignored the defect we had actually addressed. The more useful conclusion was narrower: the sampled production path preserved the characters, while the review still found content that needed an accountable person's judgement.

Those samples were not a controlled experiment and did not establish that every future quote would be correct. We retained an exception route and a process for examining changes to the service. That qualification was not a refusal to recognise progress. It kept the claim attached to the evidence. I want project teams to know that a result can be useful without being universal, and that reporting the remaining work will not automatically erase what they have achieved. Otherwise the incentive is to compress several kinds of quality into a single reassuring completion statement.

## Follow the service through its last handoff

My own lesson concerned where leadership attention stops. I had reviewed data entry and document generation as recognisable technology activities. The customer's act of reading sat beyond that boundary, even though it was the purpose of producing the document. A more useful review begins with the decision the person needs to make and works back through information required. The organisation still needs component checks, but it also needs evidence that the components produce a coherent result when joined together in the ordinary service path.

This does not require directors to inspect every quote or executives to become language specialists. It does require someone to ask what the reported success measure leaves out. If a project says that all files were generated, what has been established about their readability? If the characters are present, who has reviewed the meaning where it matters? If a workaround is used, what information changes and who accepts that change? These questions help management identify the appropriate evidence without replacing the specialists who must produce and interpret it.

The same reasoning applies when a service crosses other boundaries: a room plan becomes an instruction, a consultation becomes a retained recording, or a visual image becomes part of a purchasing decision. The useful question is not simply whether information moved. It is what the next person is entitled to understand from what arrived. Our quote project made that question tangible because the failure was visible in a customer's name. I would like to carry that discipline into less obvious cases, before a technically successful handoff becomes a commercially misleading one.