Skip to content

Find your next step.

Explore the studio

A remote studio for your digital project

Create the experience. Make it practical to run.

A digital project serves the people visiting it and the team looking after it. Softglimmer brings those perspectives into website, store, application and connected-workflow commissions for Ottawa businesses. From our Ranchi studio, we work remotely with your reviewers to plan the content, design, development and management tasks involved. You receive an agreed scope for the experience you need, together with a clear account of how ordinary work continues after release.

Compare our services
A complete public experience and a practical management routine, with content structure, staff controls and ongoing responsibilities considered during the commission.
  1. 01

    Understand both sides

    Review the external journey and the team’s routine responsibilities.

  2. 02

    Organise what changes

    Identify the content and operating information the business needs to maintain.

  3. 03

    Prepare the receiving team

    Include useful controls, guidance and an agreed route for further work.

An example journey, shaped around your requirements.

Know which changes your team is asking to make.

A request to change a website can mean editing a sentence, creating a new reusable page type, changing a business rule or connecting another system. Those requests can look similar in a feedback message, but they involve different controls, approvals and checks. A useful commission makes that distinction understandable to the team running the result.

The change worksheet below gives Ottawa businesses a practical starting point. Choose an ordinary update your team expects to make and place it in the appropriate row. Replace the sample with your own approved material, name the approver and ask what preview or recovery evidence belongs in the scope. It is a planning aid, not a claim about controls already installed on your system.

We use that information alongside the external user journey when proposing content, design, development or connected services. Routine editing can remain straightforward while changes to structure or behaviour receive the review they need. Our Ranchi team delivers remotely, with the intended editors and operating owners involved before handover.

Classify a proposed change before choosing its control.

Use these sample updates to label your own request. The proposal should identify the permitted control and approver, then specify how the result is previewed and how an unsuccessful change is handled. Recovery arrangements depend on the actual implementation and must be agreed; do not assume every change has an undo button.

A change-classification worksheet for the public experience and its management tools.
Change classSample update to replace with your ownProposed control and approverPreview and recovery evidence
Content fieldRevise an approved service description within the existing page structure, without introducing a new business promise or changing the task.An existing editing field may be suitable. Name the content approver and the editor allowed to publish it; confirm which fields the person can change.Preview the actual page and relevant phone layout. Retain the previous approved value through the agreed method and demonstrate how it can be restored before relying on that procedure.
New template or content typeAdd a reusable project page with a summary, approved images and related-service links, rather than pasting the same layout into several ordinary text fields.Treat this as a structure and development request. A content owner approves the information model; design and technical reviewers agree the template and editor controls.Review representative short, long and incomplete approved material. Keep the accepted structure available until the new one has been reviewed, and agree how affected content would return to it if needed.
Business ruleChange which authorised staff role can approve a request. This alters what people may do, even if the screen needs only a small visible adjustment.Use a scoped configuration or development change, as appropriate to the system. The business process owner approves the rule; technical ownership and release authority are named.Check the affected roles using suitable sample records, including a role that should not receive the action. Record the previous rule and an agreed recovery decision; a text preview alone cannot establish permission behaviour.
Connection to another systemSend an accepted enquiry to a newly agreed receiving system. Adding a destination can affect fields, ownership and handling of unsuccessful exchanges.Request an inspected integration or configuration change. The process owner approves the receiving purpose, and the account owner authorises access to the actual service.Review the mapped information and receiving result using authorised sample material. Agree how to stop or reverse the new arrangement and continue the task if it is not accepted; provider actions may need separate handling.

Make the delivered work easy to recognise.

A tailored proposal sets out the actual items within these six groups.

01

Audience and management brief

The people using the result, their relevant tasks and the people managing it. Record the current arrangement, desired improvement and material needed from the business. Identify decisions or access that must be resolved before implementation is agreed.

02

Page and content structure

The selected pages, reusable information and relationships. Explain what the team supplies, what is prepared during the project and what can be maintained through the agreed controls. Existing addresses and content receive an explicit retention or migration decision.

03

Reviewed creative system

The agreed identity applications, page layouts and interface components, shown with representative content. Include responsive behaviour and states relevant to the task. Specify design files and practical guidance according to the selected engagement.

04

Implemented experience and controls

The commissioned website, store, application or connection. Define the functions and management tasks included, along with relevant roles and records. Content population and transferred material have an agreed extent, so the delivered build can be compared with the proposal.

05

Release and review findings

A record of important journeys and editing tasks checked with reviewers. Resolve findings or state their effect on release readiness. Include the agreed technical checks and any external prerequisites affecting the proposed launch.

06

Usable handover material

A walkthrough of ordinary management work, agreed source materials and ownership information. Document the support route and the boundary for later requests. Identify any platform charges and continuing technical care the business needs to arrange.

Bring one real update, not an unlimited editing wish list.

Ask an intended editor to describe a change they expect to make after launch. Show the current page or tool and the approved replacement material. Use the worksheet to decide whether this is an ordinary field edit or a request affecting structure, rules or another system. More than one row may apply; record that rather than forcing a complex change into a simple label.

Then ask the reviewer to describe the before and after result, who approves it, and what they would inspect before publication. Include the person responsible for recovery when a change affects working information or a connection. These details help us specify useful controls, training and support boundaries without promising that every future alteration can be made through a content editor.

Let the receiving team participate before launch.

Delivery combines remote reviews with material that can be examined between meetings.

  1. 01

    Review the present work

    Discuss how the customer task and management routine operate today. Identify the relevant people, source information and constraints. Compare service options and agree what needs investigation before a development commitment is made.

  2. 02

    Design around representative material

    Arrange the content and prepare the selected visual and interaction direction. Invite the intended editor or operator to review the proposed management task as well as the public experience. Consolidate feedback around the same version.

  3. 03

    Build and practise

    Implement the chosen pages, functions and connections. Review ordinary use and suitable incomplete or unsuccessful paths. Let the receiving person attempt an included update so unclear controls or instructions can be addressed during delivery.

  4. 04

    Release with ownership recorded

    Confirm the agreed content and technical readiness, arrange publication and supply the handover. Identify who controls accounts, ongoing upkeep and future approvals. A later development request can then be considered with its purpose and effect clearly described.

Questions about working together.

Do we need a CMS for every website?

No. We first discuss what needs to change, who will change it and what review is appropriate. A content system can be useful for regular structured publishing, while a simpler maintained website may suit stable information. The proposal describes the chosen editing and maintenance arrangement rather than assuming that every possible control should be built.

Can we ask for a website and staff tool together?

Yes, when the intended work is sufficiently understood. They can have different users, records and acceptance tasks even within one engagement. We review their relationship and any existing tools before specifying a connection or migration. Each included part has stated outputs and inputs; a later addition remains a separate scope decision.

How are Ottawa reviews and delivery organised?

We work remotely from Ranchi, India, with nominated contacts from your business. Reviews use dated invitations and written decisions so participants can contribute at suitable times. America/Toronto and Asia/Kolkata are useful named zones for scheduling; the actual invitation establishes the local time. Meeting availability and any ongoing support are agreed for the project, not implied by a local office.