Customer Experience Platform: QUALITY WATCH

#QUALITY WATCH, a customer experience and service-quality platform

QUALITY WATCH is a Polish research and consulting company working on customer experience, service-quality audits and customer intelligence. The site presents services such as mystery shopping, mystery client, mystery caller, mystery e-mail, customer journey mapping and service-quality audits. The company is based in Warsaw and belongs to the Mystery Shopping Providers Association and to the Polish market and public opinion research association, which matters for the website in a very concrete way: membership of a methodological body sets an expectation of precision that the copy and the structure have to live up to.

The reader of this site is not a consumer. It is a board member, the head of a service centre, or the quality manager of a larger organisation, and that reader shaped every technical decision in the project.

This is the point in a case study where a table of result figures usually appears. There is none here, deliberately. This is a consulting site with no transaction volume, and the client’s enquiry numbers belong to the client rather than to a portfolio entry on our site. What can be told honestly is the decision path, and that is the part which transfers.

#The content model was the actual project

Before the project, the offer lived mostly in documents and in the consultants’ heads. The work of diagnosis was therefore less about measuring an existing site and more about forcing an offer into a structure a website can carry.

In joint working sessions the services were sorted along three questions: what is the method, which industries is it used in, and what outcome can the client expect at the end. Those three axes became the backbone of the content model, and every later page maps onto them.

The obvious alternative was rejected. Building a separate page per industry, with its own text, doubles the editorial work and guarantees contradictions: the same method ends up described five ways, and nobody can say which description is current. So method pages describe the procedures, and industry context arrives as enriching sections inside case studies and service pages. A reader can follow the path that matches their problem without the editorial team maintaining the same statement in several places.

Case studies were built as a reusable block catalogue rather than as fixed pages: context, approach, outcome, industry reference. The editorial team assembles examples from those blocks without touching templates. This removes the most common cause of stagnation on consulting websites, which is that a new example stalls on layout work and therefore never gets published. A consultancy site lives on examples, and examples age.

#Confidentiality is a structural requirement, not a disclaimer

The diagnosis surfaced a risk that had not been written into the brief. Parts of the material were covered by confidentiality agreements with the consultancy’s own clients. Case material could not appear in a form that allows anyone to identify which organisation was audited.

That is not solved by a sentence in the footer. It has to sit in the content model, which therefore distinguishes from the start between publishable case studies and anonymised results, with a review path before anything goes live. In practice this means a case study block carries both the substance that convinces a decision maker and the restraint that keeps the client’s client unidentifiable, and someone has to check that balance before publication rather than after.

A second risk came from the industry’s own habits. Service-quality consultancies tend to present their offer as a word cloud in which every term links to every other term. A website that mirrors that network directly produces linking chaos and makes the reader’s mental arithmetic impossible. Keeping the method, industry and outcome axes separate is what prevented that.

#Restraint at the conversion layer is part of the product

Enquiry paths exist on every relevant page, but they are placed so that they appear after a piece of decision support rather than as a wall of sales pressure. In a segment where the seller is itself selling quality assurance, the restraint of the interface is part of what is being sold.

The same reasoning governs the tone of the interface. Exaggeration that a consumer brand gets away with disqualifies a quality consultant in the eyes of its own buyers. So the surface is professional, quiet and easy to scan, and the copy describes procedures rather than promising outcomes.

Decision makers rarely read a service page from top to bottom; they scan for the section matching their current problem. The page structure follows that behaviour: the core service in the first paragraph, the method after it, industry context available on demand, and a contact path at the end of each relevant section instead of a single floating button.

#Technical decisions and what they trade away

The back end is WordPress with a custom theme. Choosing a custom theme over a commercial multipurpose product follows from the shape of the offer: a block system for case studies maps cleanly onto a lean theme, whereas a multipurpose theme solves the same job with layers of options the editorial team never touches but which drag maintenance, security surface and load time behind them.

Styles are written in SASS and compiled to narrow CSS, the layout is marked up semantically in HTML5, and JavaScript is used where interaction earns its cost rather than as a default coating on every movement.

On the delivery side, Redis as an object cache, a CDN in front of the installation and a defined cache policy take the load off the database for the part of traffic that needs no dynamic decision. A consulting site has an advantage over a shop here: the overwhelming majority of its pages change only when the editorial team changes them, so most traffic can be served without PHP and the database being involved at all.

The cache policy was documented, including the question of which content has to become visible immediately after the editorial team publishes it and what delay the cache may impose. That question sounds like housekeeping and decides, in practice, whether an editorial team accepts caching or quietly circumvents it because a new case study stayed invisible for a quarter of an hour.

The REST API carries the internal editorial workflows, and Git holds the code with a process that lets changes into production only after they have been checked on staging. That is also a credibility argument facing inward: a service-quality provider can tell from its own project whether its implementer works with controlled processes.

#Delivery, handover and the training session that mattered

Delivery ran in clearly separated phases. After the analysis came the template structure: layout and element placement came from the client, and from that the views and their responsive behaviour were built. That division speeds up the start of a project but moves the real effort downstream, into the content model and the maintenance chain, and that is where the project time was concentrated.

Pre-launch checks ran against a copy of production rather than an empty install. That holds even for a consulting site with no checkout: only with real content, real image distribution and the real navigation structure can anyone see whether the service pages read well together, whether the enquiry paths appear in the right places and whether the editorial team can work the back end. The content itself was reviewed for data protection before launch, because forms, analytics tools and embeds touch the client’s obligations under the GDPR, and the relevant agreements with the providers in use were checked and completed before the site went live.

Training the editorial team was part of delivery rather than of aftercare. In a joint session, real examples were used to walk through how a new case study is assembled from the blocks, how the anonymisation rules are applied and which review steps come before publication. In many projects that session is the difference between a handover and a handover folder: the folder gets stored, the session gets remembered.

Handover included documentation of the content model, a guide to the case-study blocks, the description of the cache and CDN configuration, and a short procedure for reviewing new content before publication. Ongoing support covers security updates, periodic performance checks and help when new services are folded into the existing structure. New methods do not appear monthly in this segment, but when they do, they have to slot in without a rebuild, and the documentation describes exactly how an additional method is read into the existing method, industry and outcome axes.

#What can be said at the end

What can be stated are states rather than percentages. The site carries the entire service portfolio in a structure a new editor can maintain without being briefed by the implementer. Case studies are assembled from blocks and get published without layout work. Enquiry paths run through the client’s own forms, which follow the client’s data protection requirements. The technical base of caching, CDN and lean templates keeps the site fast when a pitch circulates and many readers from one organisation suddenly look at the same page at once.

The most honest measure of this project is organisational: content maintenance sits entirely with the client’s editorial team. A consulting website that no longer depends on its implementer after launch has already reached the metric that matters most for this type of project.

#Lessons a buyer can take from this

Three things transfer. First, for a service business the content model is the actual project, not the design; the method, industry and outcome axes decide whether a visitor understands the offer within five minutes. Second, case studies belong in a block catalogue rather than in hard-wired pages, because only that keeps a consulting site alive without permanent implementer costs. Third, restraint at the surface is a signal and not a sacrifice: selling quality services while shouting through conversion elements loses more than it gains.

A fourth point is aimed at the buying side. In the first conversation with any implementer, ask how your editorial team will publish a new case study after launch. The answer says more about the quality of the offer than any design presentation, because it separates a content model from a nicely wrapped static site.

This scenario fits you if you run a consulting or service portfolio with several methods and target industries, if your content carries confidential client references and therefore needs anonymisation logic, if your editorial team should publish examples on its own, and if the site has to serve decision makers who scan under time pressure rather than browse. It does not fit if you need a transactional shop with a basket, stock logic and payments, if the services are homogeneous enough that one page would do, or if there is no editorial team and content will be maintained externally anyway. In those cases the right architecture looks different, and it is cheaper to establish that before a quotation than after one.

If you want to put your own portfolio into a structure that carries, describe your services, your audiences and the way your content is maintained. We will answer with an assessment of which architecture fits that situation. Write to us through our English contact page, and the first step will be an honest classification rather than a standard offer.